+<?xml version="1.0" encoding="UTF-8"?>
+
+<project-structure>
+
+
+<!-- 1. Database physical location
+ -->
+ <database>
+ <repository disk="D:/users/rkv/SALOME_SIMER/rep" />
+ </database>
+
+
+<!-- 2. Formats
+ -->
+ <formats>
+
+<!-- 2.1 Project elements identification scheme
+ Studies, Knowledges and Documents are identified by unique user references. The structure of these references is customizable.
+ You customize references through patterns.
+ A reference's pattern is a character string including format directives. These format directives allow you to insert
+ some information into the reference. The following directives are available:
+ - %yy or %yyyy for inserting the entity creation year on 2 or 4 digits
+ - %0000 for inserting a unique index, the number of digits being defined by the number of 0
+ The above index is unique in the scope of cycle defined by the first format directive (year). In other words, this index
+ restarts every new year. As such, for making references unique on this application server, both format directives (cycle
+ and index) must be present in the pattern.
+ Other characters are simply inserted as is in generated references. They can be used for extending the reference uniqueness
+ beyond application servers, by adding a prefix specific to a given server (for example, a company department name).
+ Given that these references may be used as directory or file names of the repository vault, the pattern must not include
+ illicit characters such as '/', '?', '<' etc.
+ -->
+ <references study="DER%yy%0000"/>
+
+<!-- 2.2 Physical files naming scheme
+ The physical data files stored into the repository vault can be named as follows:
+ - By the user-defined title of corresponding documents ("title" name attribute below)
+ - Encoded by a built-in scheme ("encoded" name attribute)
+ - As is, that is, by keeping the name of the imported file ("asis" name attribute - not yet supported)
+ Remarks:
+ - When using the title scheme, as file names may include accent characters, client browsers must be configured for
+ NOT encoding URLs as UTF-8.
+ - Whatever is the naming scheme used, in order to avoid name clashes, file names are anyway suffixed by an index
+ unique in the scope of the owner study.
+ -->
+ <files name="encoded"/>
+
+<!-- 2.3 Document versions format
+ -->
+ <versions pattern="%M.%m[-%s]"/>
+ </formats>
+
+
+<!-- 3. Document types
+
+ Warning: Articles must be ordered in a way that used document types (uses attribute values) must previously be defined.
+ Example: "requirements" type must be defined before "specification" because "specification" uses "requirements".
+ Remarks:
+ - "knowledge" is a reserved word qualifying Knowledge Elements. So, it must not be used as a document type name.
+ - "default" and "built-in" are also reserved words used for defining validation cycles.
+ - In this version, the "uses" attribute is limited to 1 document type only.
+ -->
+ <documents>
+ <article type="requirements"/>
+ <article type="specification" uses="requirements"/>
+ <article type="design" uses="specification"/>
+ <article type="geometry" uses="design"/>
+ <article type="model" uses="geometry"/>
+ <article type="loads" uses="model"/>
+ <article type="script" uses="loads"/>
+ <article type="log" uses="script"/>
+ <article type="results" uses="script"/>
+ <article type="report" uses="results"/>
+ <article type="memorandum"/>
+ <article type="minutes"/>
+ </documents>
+
+
+<!-- 4. Simulation Context types
+
+ Warning: The Simulation Context type "product" is mandatory as it is used by at least one application.
+ -->
+ <contexts>
+
+ <!-- General information -->
+ <article type="customer"/>
+ <article type="product"/>
+ <article type="phase"/> <!-- Phase of the product -->
+ <article type="need"/> <!-- Customer needs -->
+ <article type="purpose"/> <!-- Objective of the study -->
+ <article type="physic"/> <!-- Structure analysis, Thermal-hydraulics, Neutronic... -->
+
+ <!-- Geometry characteristics Examples: -->
+ <article type="object"/> <!-- Car, Plane, Equipment... -->
+ <article type="part"/> <!-- Crankcase, Outer layer... -->
+ <artivle type="geometry"/> <!-- Surface, Volume -->
+
+ <!-- Model characteristics Examples: -->
+ <article type="model"/> <!-- CSG, FEM... -->
+ <article type="element"/> <!-- Bar, Surface, Volume -->
+ <article type="shape"/> <!-- (Surface) Triangle, Quadrangle... (Volume) Tetrahedron, Hexahedron... -->
+ <article type="order"/> <!-- First-order, Second-order... -->
+
+ <!-- Analysis type Examples: -->
+ <article type="analysis"/> <!-- Static, Dynamic... -->
+
+ <!-- Software tools used -->
+ <article type="platform"/>
+ <article type="module"/>
+ <article type="component"/>
+ </contexts>
+
+
+<!-- 5. Knowledge Elements types
+
+ Warning: The Knowledge Elements type "usecase" is reserved for internal use.
+ -->
+ <knowledges>
+ <article type="bestpractice"/>
+ <article type="limitation"/>
+ <article type="inconsistency"/>
+ <article type="metrics"/>
+ <article type="improvement"/>
+ </knowledges>
+
+
+<!-- 6. User activities
+
+ Remarks:
+ - Step names must naturally be unique.
+ - Simulation Contexts must be attached to one classification step only.
+ - Result document types must be results of one step only and be part of contents of the corresponding step.
+ -->
+ <activities>
+ <step name="specification">
+ <classification context="customer,product,phase,need,purpose,physic"/>
+ <flow contents="requirements,specification,minutes" result="specification"/>
+ <storage path="1.Study"/>
+ </step>
+ <scenario>
+ <step name="design">
+ <flow contents="design,memorandum,minutes" result="design"/>
+ <storage path="1.Study"/>
+ </step>
+ <step name="modeling">
+ <classification context="object,part,geometry"/>
+ <flow contents="geometry,memorandum,minutes" result="geometry"/>
+ <storage path="2.Geometry"/>
+ <module name="GEOM"/>
+ </step>
+ <step name="meshing">
+ <classification context="model,element,shape,order"/>
+ <flow contents="model,memorandum,minutes" result="model"/>
+ <storage path="3.Mesh"/>
+ <module name="SMESH"/>
+ </step>
+ <step name="solving">
+ <classification context="loads,script,platform,module,component"/>
+ <flow contents="log,results,minutes" result="results"/>
+ <storage path="5.Result"/>
+ <module name="CASTEM"/>
+ </step>
+ <step name="postprocessing">
+ <flow contents="memorandum,minutes"/>
+ <storage path="6.Report"/>
+ </step>
+ <step name="capitalization">
+ <flow contents="knowledge"/>
+ <storage path="6.Report"/>
+ </step>
+ </scenario>
+ <step name="reporting">
+ <flow contents="report,minutes" result="report"/>
+ <storage path="1.Study"/>
+ </step>
+ </activities>
+
+
+<!-- 6. Document validation cycles
+ Validation cycles define the actors involved in the validation steps of documents. These steps can be
+ "review", "approval" and "acceptance".
+ Remarks:
+ - Each validation cycle is defined by a tag corresponding to the type of an activity result document.
+ - The actors of validation steps can be
+ "manager", referring the responsible of study,
+ "Nx1", referring the manager of the department (see User definition for more information),
+ "Nx2", referring the boss of the department manager,
+ "customer" (most likely involved in the acceptance step).
+ -->
+ <validations>
+ <specification review="Nx1" approval="Nx2"/>
+ <report review="Nx1" approval="Nx2"/>
+ <default review="manager" />
+ </validations>
+
+<!-- 3. Check-in check-out information
+ Defines the way documents involved in the check-in check-out operations must be processed.
+ -->
+ <mappings>
+ <document type="geometry">
+ <source format="step" process="file-download"/> <!-- Geometry created from STEP import -->
+ <source format="py" process="file-download"/> <!-- Geometry created from Python execution -->
+ <source format="xml" process="ocaf-import"/> <!-- Geometry created interactively -->
+ <export format="brep"/> <!-- Result Shape -->
+ </document>
+ <document type="model">
+ <source format="py" process="file-download"/> <!-- Mesh created from Python execution -->
+ <source format="xml" process="ocaf-import"/> <!-- Mesh including input parameters -->
+ <export format="med"/> <!-- Result mesh without input parameters -->
+ </document>
+ <document type="loads">
+ <source format="py" process="file-download"/> <!-- Input data created from Python execution -->
+ <source format="c3m" process="c3m-import"/> <!-- Input data created interactively -->
+ </document>
+ <document type="results">
+ <source format="med" process="med-import"/> <!-- Calculation results source file -->
+ </document>
+ </mappings>
+</project-structure>
\ No newline at end of file