File and Directory Formats
Simulation Directory (.sim)
Here are details on the .sim simulation directory (the .sim extension is entirely optional). The directory contains inputs and results on the mesh nodes and elements, over a certain number of simulation steps. It is structured as follows:
simulation.sim
|-- inputs
| |-- job.sh
| |-- simulation.cfg
| |-- simulation.msh
| `-- simulation.tess
|-- results
| |-- elts
| | |-- ori
| | | |-- ori.step0
| | | |-- ori.step1
| | | `-- ...
| | `-- ...
| `-- nodes
| |-- coo
| | |-- coo.step0
| | |-- coo.step1
| | `-- ...
| `-- ...
`-- [restart]
where
inputsis an input file directory containing the Neper tessellation file (simulation.tess, if found in the input directory), the mesh file (simulation.msh), the FEPX configuration file (simulation.cfg), and all script files (*.sh, likely including a job submission file).resultsis the result directory.results/nodesis the node result directory.results/eltsis the element result directory.results/*/<res>is a directory for result<res>of an entity (nodes or elements). The directory contains one file per simulation step, named<res>.step<nb>, wherenbis the step number, ranging from 0 (for the initial state) to the total number of steps.restartis the restart directory. It is present only ifrestart onwas used.
Results can have integer values, real values, vectorial values or tensorial values. In the result files, values for the different entities (nodes or elements) are written on successive lines, with components written on successive columns (space delimited). The components are written as follows:
vector, \(v\): \(v_1\), \(v_2\), \(v_3\);
symmetrical tensor, \(t\): \(t_{11}\), \(t_{22}\), \(t_{33}\), \(t_{23}\), \(t_{31}\), \(t_{12}\) (Voigt notation);
skew-symmetrical tensor, \(t\): \(t_{12}\), \(t_{13}\), \(t_{23}\);
non-symmetrical tensor, \(t\): \(t_{11}\), \(t_{12}\), \(t_{13}\), \(t_{21}\), \(t_{22}\), \(t_{23}\), \(t_{31}\), \(t_{32}\), \(t_{33}\).
The directory also contains a hidden file, .sim, containing information on the simulation and the content of the simulation directory. This file is only for internal use and is formatted as follows:
***sim
**format
<format>
**input
*tess
<tess_file>
*tesr
<tesr_file>
*msh
<msh_file>
*ori
<ori_file>
*bcs
<bcs_file>
*phase
<phase_file>
*config
<config_file>
**general
<cell_nb> <node_nb> <elt_nb> <elset_nb> <part_nb>
*orides
<orientation_descriptor>
**entity <entity> \
*member |
<member_nb> |
<member1> <member2> ... | section repeated for each entity
*result |
<result_nb> |
<result1> <result2> ... /
**orispace
*rodrigues <space_file>
**step
<step_nb>
***end
Mesh File (simulation.msh)
Here are details on the native .msh (adapted from Gmsh’s msh format version 2.2). Developers should note that read and write functions are available as neut_msh_fscanf and neut_msh_fprintf, defined in directories neut/neut_msh/neut_msh_fscanf and neut/neut_msh/neut_msh_fprintf.
$MeshFormat
2.2 <file_type> <data_size>
$EndMeshFormat
$MeshVersion
<mesh_version>
$EndMeshVersion
$Domain
<domain>
$EndDomain
$Topology
<reconstruct_topology>
$EndTopology
$Nodes
<number_of_nodes>
<node_id> <node_x> <node_y> <node_z>
...
$EndNodes
$Elements
<number_of_elements>
<elt_id> <elt_type> <number_of_tags> <tag1> ... <elt_id_node1> ...
...
$EndElements
$Periodicity
<number_of_periodicities>
<secondary_node_id> <primary_node_id> <per_vect_x> <per_vect_y> <per_vect_z>
...
$EndPeriodicity
$NSets
<number_of_nsets>
<nset1_label>
<nset_node_nb>
<nset_node1>
<nset_node2>
...
<nset2_label>
...
$EndNSets
$Fasets
<number_of_fasets>
<faset1_label>
<faset_elt_nb>
<faset_elt_id> <faset_elt_id_node1> ...
...
<faset2_label>
...
$EndFasets
$NodePartitions
<number_of_nodes>
<node_id> <node_partition>
...
$EndNodePartitions
$PhysicalNames
<number_of_physical_names>
<physical_dimension> <physical_id> <physical_name>
...
$EndPhysicalNames
$ElsetOrientations
<number_of_elsets> <orientation_descriptor>
<elset_id> <ori_des1> ...
...
$EndOrientations
$ElsetCrySym
<crysym>
$EndElsetCrySym
$ElementOrientations
<number_of_elements> <orientation_descriptor>
<element_id> ori_des1> ...
...
$EndElementOrientations
$Groups
<group_entity>
<number_of_group_entities>
<entity_id group>
...
$EndGroups
where
$MeshFormatdenotes the beginning of a mesh format field.<file_type>is equal to0for an ASCII file and1for a binary file.<data_size>is an integer equal to the size of the floating point numbers used in the file (=sizeof (double)).$EndMeshFormatdenotes the end of a mesh format field.$MeshVersiondenotes the beginning of a mesh version field.<mesh_version>is the mesh file version (currently2.2.3).$EndMeshVersiondenotes the end of a mesh version field.$Domaindenotes the beginning of an optional domain field.<domain>is the domain.$EndDomaindenotes the end of an optional domain field.$Topologydenotes the beginning of an optional topology field.<reconstruct_topology>is a boolean indicating whether the topology is to be reconstructed upon parsing or not (use0to solve parsing issues).$EndTopologydenotes the end of an optional topology field.$Nodesdenotes the beginning of a node field.<number_of_nodes>is the number of nodes.<node_id>is the identifier of a node and ranges from1to<number_of_nodes>.<node_x>,<node_y>and<node_z>are the three coordinates of a node (real numbers).$EndNodesdenotes the end of a node field.$Elementsdenotes the beginning of an element field.<number_of_elements>is the number of elements.<elt_type>is an integer specifying the type of elements:15for a 0D element,1for a 1st-order 1D element (2 nodes),8for a 2nd-order 1D element (3 nodes),2for a 1st-order triangular element (3 nodes),3for a 1st-order quadrangular element (4 nodes),9for a 2nd-order triangular element (6 nodes),16for a 2nd-order quadrangular element (8 nodes),10for a 2nd-order quadrangular element (9 nodes),4for a 1st-order tetrahedral element (4 nodes),5for a 1st-order hexahedral element (8 nodes),11for a 2nd-order tetrahedral element (10 nodes),17for a 2nd-order hexahedral element (20 nodes),6for a 1st-order prismatic element (6 nodes),18for a 2nd-order prismatic element (15 nodes).<number_of_tags>is the number of tags, and<tag#>are the tags. In the general case, the number of tags is equal to 3, the first and second tags are the elset and the third tag is the element partition. The mesh partition is non-zero only for the higher-dimension elements of a mesh which was previously partitioned.<elt_id_node#>are the nodes associated to an element. The number of nodes depends on the element type (<elt_type>).$EndElementsdenotes the end of an element field.$Periodicitydenotes the beginning of a periodicity field.<number_of_periodicities>is the number of periodicities.<primary_node_id>is the identifier of the primary node.<secondary_node_id>is the identifier of the secondary node.<per_vect_x><per_vect_y><per_vect_z>are the scaled components of the vector going from the primary node to the secondary node (-1, 0 or 1).$EndPeriodicitydenotes the end of a periodicity field.$NSetsdenotes the beginning of an nset field.<number_of_nsets>is the number of nsets.<nset#_label>are the labels of the nsets.<nset_node_nb>is the number of nodes of an nset.<nset_node_id#>are the identifiers of the nodes of an nset.$EndNSetsdenotes the end of an nset field.$Fasetsdenotes the beginning of a faset field.<number_of_fasets>is the number of fasets.<faset#_label>are the labels of the fasets.<faset_elt_nb>is the number of elements of a faset.<faset_elt_id>are the identifiers of the elements of a faset (3D elements adjacent to the boundary).<faset_elt_id_node#>are the nodes of an element of a faset.$EndFasetsdenotes the end of a faset field.$NodePartitionsdenotes the beginning of a node partition field.<nodeid_partition>is the partition of node<id>(ranging from 1 to the total number of partitions).$EndNodePartitionsdenotes the end of a node partition field.$PhysicalNamesdenotes the beginning of a physical name field.<number_of_physical_names>is the number of physical names. There are as many names as physical entities, and the physical entities correspond to all tessellation vertices, edges, faces and polyhedra (i.e., mesh 0D, 1D, 2D and 3D elsets).<physical_dimension>is the dimension of a physical entity and can be equal to 0, 1, 2 or 3.<physical_id>is the id of a physical entity. It ranges from 1 to the number of 0D elsets (tessellation vertices) for the 0D entities, 1 to the number of 1D elsets (tessellation edges) for the 1D entities, 1 to the number of 2D elsets (tessellation faces) for the 2D entities and 1 to the number of 3D elsets (tessellation polyhedra) for the 3D entities.<physical_name>is the name of a physical entity, under the form<verid>for 0D elsets (tessellation vertices),<edgeid>for 1D elsets (tessellation edges),<faceid>for 2D elsets (tessellation faces) and<polyid>for 3D elsets (tessellation polyhedra), where<id>ranges from 1 to the number of elsets.$EndPhysicalNamesdenotes the end of a physical name field.$ElsetOrientationsdenotes the beginning of an elset orientation field.$EndElsetOrientationsdenotes the end of an elset orientation field.<number_of_elsets>is the number of elsets.<orientation_descriptor>is the orientation descriptor.<elset_id>is the elset id.<ori_des1>, … is the orientation, following<orientation_descriptor>.$EndElsetOrientationsdenotes the end of an elset orientation field.$ElsetCrySymdenotes the beginning of an elset crystal symmetry field.<crysym>is the crystal symmetry (triclinic,cubicorhexagonal).$EndElsetCrySymdenotes the end of an elset crystal symmetry field.$ElementOrientationsdenotes the beginning of an element orientation field.<number_of_elements>is the number of elements.<element_id>is the element id.$EndElementOrientationsdenotes the end of an element orientation field.$Groupsdenotes the beginning of a group field.<group_entity>is the entity for which groups are defined, which must beelset.<number_of_group_entities>is the number of group entities (number of elsets).<entity_id>is the id of an entity.<group>is the group of the entity.$EndGroupsdenotes the end of a group field.
Orientation File (simulation.ori)
The embedded orientation assignments within the simulation.msh may be overridden via an external simulation.ori file. This file contains formatting identical to the associated fields in the mesh file and is defined as:
For per-grain (or Elset) orientations:
$ElsetOrientations
<number_of_ori_entities> <orientation_descriptor>:<orientation_convention>
<entity_id> <ori_des1> ...
...
$EndElsetOrientations
For per-element orientations:
$ElementOrientations
<number_of_ori_entities> <orientation_descriptor>:<orientation_convention>
<entity_id> <ori_des1> ...
...
$EndElementOrientations
where <number_of_ori_entities> is the number of unique orientations defined in the section, <orientation_descriptor> is the parameterization for the orientations (see options below), <orientation_convention> describes the basis transformation route for the orientations provided, <entity_id> is a unique 1-indexed identification number, and <ori_des*> are the components of the unique orientation. Available options for <orientation_convention> are: active or passive. Following the usual terminology, an active orientation assumes that which describes a basis transformation from the sample basis to the crystal basis (sample-to-crystal), while a passive orientation convention assumes that which describes a basis transformation from the crystal basis to the sample basis (“crystal-to-sample”).
The following <orientation_descriptor> types are available (associated per-line formats are also described):
For
rodrigues, each orientation is described by \(r_1, r_2, r_3\), where \({\bf r} = {\bf t} \tan{ (\omega / 2)}\) (see:axis-anglefor definitions of \({\bf t}\) and \(\omega\)). The per-line format is:<entity_id> <r_1> <r_2> <r_3>
For
euler-bunge, each orientation is described by \(\phi_1, \theta, \phi_2\), where \(\phi_1\) is the rotation about the \(z\) axis, \(\theta\) is the rotation about the \(z^{\prime}\) axis, and \(\phi_2\) is the rotation about the \(z^{\prime \prime}\) axis, all in degrees). The per-line format is:<entity_id> <phi_1> <Phi> <phi_2>
For
euler-kocks, each orientation is described by \(\Psi, \Theta, \phi\), where \(\Psi\) is the rotation about the \(z\) axis, \(\Theta\) is the rotation about the \(y^{\prime}\) axis, and \(\phi\) is the rotation about the \(z^{\prime \prime}\) axis, all in degrees). The per-line format is:<entity_id> <Psi> <Theta> <phi>
For
axis-angle, each orientation is described by \(t_1, t_2, t_3, \omega\), where \(\bf{t}\) is the normalized axis of rotation and \(\omega\) is the angle of rotation about said axis, in degrees. The per-line format is:<entity_id> <t_1> <t_2> <t_3> <omega>
For
quaternion, each orientation is described by \(q_0, q_1, q_2, q_3\), where \(q_0 = \cos{(\omega / 2)}\) and \(q_i = t_i \sin{(\omega / 2)}\) for \(i = 1, 2, 3\) (see:axis-anglefor definitions of \({\bf t}\) and \(\omega\)). The per-line format is:<entity_id> <q_0> <q_1> <q_2> <q_3>
Phase File (simulation.phase)
The embedded grain/phase assignments within the simulation.msh may be overridden via an external simulation.phase file. This file contains formatting identical to the associated fields in the mesh file and is defined as:
$Groups
<group_entity>
<number_of_group_entities>
<entity_id> <group>
...
$EndGroups
where <group_entity> defines the phase assignment method and must always be defined as elset, <number_of_group_entities> is the number of grain/phase pairs defined in the field, <entity_id> is a unique 1-indexed identification number, and <group> is an 1-indexed value that defines the phase for a given grain.
Optional Inputs File (simulation.opt)
The hardening parameter assignments for g_0 and g_s0 within the simulation.cfg may be overridden via an external simulation.opt file. This file contains formatting identical to the associated fields in the configuration file and is defined as:
For per-grain (or Elset) values:
$Elset<variable>
<number_of_elsets> <maximum_num_values>
<entity_id> <value_1> ...
...
$EndElset<variable>
For per-element values:
$Element<variable>
<number_of_elements> <maximum_num_values>
<entity_id> <value_1> ...
...
$EndElement<variable>
where <variable> is Crss for g_0, which can be defined per slip system, and CrssSat for g_s0 a scalar value. Additionally, <entity_id> is a unique 1-indexed identification number for the specified entities.
Restart Files (rst<N>.*)
If the print restart command is present in the simulation.cfg file, a set of additional restart files will be generated from the simulation. These files are written at the end of each prescribed step and contain necessary information to restart a given simulation ([LEGACY] Restarting a Simulation with Appended Load Steps for information on how to restart a simulation). Two types of restart files are generated, a control file, rst<N>.control, and per-core field files, rst<N>.field.core* (where <N> indicates which simulation the files describe, 0 indexing). Both file types are unformatted (or binary) files and are generally unmodifiable. The structures of the data stored within both files for the various deformation modes follow.
Uniaxial Restart Control
The rst<N>.control file for uniaxial loading modes contains the following data in the given order:
current_step <step>
previous_load_array <load_x> <load_y> <load_z>
step_complete_flag <logical>
previous_timestep_value <time>
current_incr <increment>
current_time <time>
surface_1_loads <load_x> <load_y> <load_z>
...
surface_6_loads <load_x> <load_y> <load_z>
previous_prescribed_load <load>
current_surface_areas <area_surf_1> ... <area_surf_6>
initial_surface_areas <area_surf_1> ... <area_surf_6>
Multiaxial CSR Restart Control
The rst<N>.control file for multiaxial constant strain rate loading modes contains the following data in the given order:
current_step <step>
current_load_array <load_x> <load_y> <load_z>
previous_load_array <load_x> <load_y> <load_z>
step_complete_flag <logical>
previous_timestep_value <time>
current_incr <increment>
current_time <time>
surface_1_loads <load_x> <load_y> <load_z>
...
surface_6_loads <load_x> <load_y> <load_z>
current_surface_areas <area_surf_1> ... <area_surf_6>
initial_surface_areas <area_surf_1> ... <area_surf_6>
current_mesh_lengths <length_x> <length_y> <length_z>
initial_mesh_lengths <length_x> <length_y> <length_z>
current_control_velocity <vel_x> <vel_y> <vel_z>
s_pert_mag <vel>
t_pert_mag <vel>
Multiaxial CLR Restart Control
The rst<N>.control file for multiaxial constant load rate loading modes contains the following data in the given order:
current_step <step>
current_load_array <load_x> <load_y> <load_z>
previous_load_array <load_x> <load_y> <load_z>
first_incr_in_step <logical>
current_incr <increment>
current_time <time>
surface_1_loads <load_x> <load_y> <load_z>
...
surface_6_loads <load_x> <load_y> <load_z>
current_surface_areas <area_surf_1> ... <area_surf_6>
initial_surface_areas <area_surf_1> ... <area_surf_6>
current_mesh_lengths <length_x> <length_y> <length_z>
initial_mesh_lengths <length_x> <length_y> <length_z>
current_control_velocity <vel_x> <vel_y> <vel_z>
previous_control_action <integer>
current_control_action <integer>
initial_load_dwell_velocity <vel_x> <vel_y> <vel_z>
initial_unload_dwell_velocity <vel_x> <vel_y> <vel_z>
Restart Field Data
All loading modes also write field data on a per-core basis to rst<N>.field.core* files. These files contain the necessary field variable information in order to spatially define the total state of the virtual sample at the time of printing. The following field data arrays are written to the files in the given order:
coords <coords>
velocity <velocity>
c0_angs <orientation>
c_angs <orientation>
rstar <rotation>
rstar_n <rotation>
wts <weight>
crss <crss>
crss_n <crss>
gela_kk_bar <strain>
gsig_vec_n <stress>
pela_kk_bar <strain>
psig_vec_n <stress>
e_elas_kk_bar <strain>
sig_vec_n <stress>
eqstrain <strain>
eqplstrain <strain>
gamma <shear>
el_work_n <work>
el_workp_n <work>
el_work_rate_n <work_rate>
el_workp_rate_n <work_rate>