Z-set output formats#

Z-set has two output formats: the default Z7 format, and the Z8 format which take into account remeshing.

Z7 output format#

The file problem.ut describes the contents of the binary output files problem.node, problem.integ, problem.ctnod, and problem.ctele. It contains:

**meshfile gives the name of the file problem.geof used for computation.
after **node the names of the nodal variables and parameters stored in problem.node are given.
after **integ the names of integration (material) variables stored in problem.integ, problem.ctnod, and problem.ctele are given.
**element is not presently used.

Following these four marked up sections, a list of the output timesteps is given. Each line represents the state of the calculation for one map. These lines contain the output number, the cycle number, the sequence number, the increment and corresponding time, in that order.

The file problem.node contains the nodal output variables. These variables consist of the nodal degrees of freedom (such as displacements, temperature, etc), the associated reactions to the nodal DOFs (forces, heat flux), and possibly the problem nodal parameters if the **save_parameter option was given after ***output. The stored variables will be the complete list of variables at each node, regardless if certain parameters do not exist at every node in the problem. For variables which do not exist at a given node, a zero value will be stored.

The problem.node file has the following structure: \(1^{st}\) output \(2^{nd}\) output where \(n_d\) is the number of DOFs given by **node in the problem.ut file, and \(N\) is the number of nodes.

The problem.node file may be written in C with the following code snippet:

for(card=0; card < stored_cards; card++) {
   for(variable=0; variable < nodal_variables_stored; variable++) {
      for(node=0; node < number_of_nodes_in_mesh ; node++) {
         fwrite(&component[node][variable][card],4,1,fp);
      }
   }
}

The file problem.integ contains the integration point values issued from the material behavior laws (see **value_at_integration under ***output). In the event that certain variables do not exist at all integration points in the problem, a zero value will be stored in its place. Thus the number of variables is always the union of the different material variables in the problem.

Each record in the problem.integ file has the following format:

\(v1_{pg1el1},~~v1_{pg2el1}~~~ \dots~~~v1_{pgnel1}\) \(1^{st}\) variable for element 1

\(v2_{pg1el1},~~v2_{pg2el1}~~~ \dots~~~v2_{pgnel1}\) \(2^{nd}\) variable for element 1

\(\dots\)

\(vnv_{pg1el1},~~vnv_{pg2el1}~~~ \dots~~~vnv_{pgnel1}\) variable nv for element 1

\(v1_{pg1el2},~~v1_{pg2el2}~~~ \dots~~~v1_{pgnel2}\) \(1^{st}\) variable for element 2

\(v2_{pg1el2},~~v2_{pg2el2}~~~ \dots~~~v2_{pgnel2}\) \(2^{nd}\) variable for element 2

\(\dots\)

\(vnv_{pg1el2},~~vnv_{pg2el2}~~~ \dots~~~vnv_{pgnel2}\) variable nv for element 2

\(\dots\)

\(v1_{pg1elNE},~~v1_{pg2elNE}~~~ \dots~~~v1_{pgnelNE}\) \(1^{st}\) variable for element NE

\(v2_{pg1elNE},~~v2_{pg2elNE}~~~ \dots~~~v2_{pgnelNE}\) \(2^{nd}\) variable for element NE

\(\dots\)

\(vnv_{pg1elNE},~~vnv_{pg2elNE}~~~ \dots~~~vnv_{pgnelNE}\) variable nv for element NE

where \(NE\) is the number of elements in the structure, and \(nv\) the number of values stored per integration point (listed after **integ in the file problem.ut).

Elements generally do not have the same number of integration points. Due to this, the storage of different element types in a problem will generate element data structures of different sizes within the same record.

The file problem.integ may be generated using the following C code:

for(card=0; card < number_of_outputs; card++) {
   for(ele=0; ele < number_of_elements ; ele++) {
      for(var=0; var< number_of_integ_variables; var++) {
         for(point=0; point < number_of_IP_in_element[ele]; point++) {
            fwrite(&component[point][var][ele][card],4,1,fp);
         }
      }
   }
}

The problem.ctnod file contains the integration point variables (material variables) extrapolated to the nodes and will be generated when the **contour option is selected under ***output. This file uses a storage format similar to problem.node files. The only difference is that the .ctnod file does not store values for orphan nodes (i.e. nodes not attached to an element).

The structure of each record in the problem.ctnod file is the following:

\(v1_1,~~ v1_2, ~~ ...  v1_N\)   variable 1
\(v2_1,~~ v2_2, ~~ ...  v2_N\)   variable 2
…
\(vn_1,~~ vn_2, ~~ ...  vn_N\)   variable n

where \(N\) is the number of (non-orphan) nodes and \(n\) the number of variables indicated by **integ in the problem.ut file. A problem.ctnod may be generated using the following C code:

for(card=0;card < stored_cards; card++){
   for(var=0; var< number_of_integ_variables; var++) {
      for(node=0; node < number_of_nodes_in_mesh; node++) {
         if (! is_orphan_node(node))
            fwrite(&component[node][var][card],4,1,fp);
      }
   }
}

The file problem.ctele contains the integration variables at nodes. The file is a duplication of problem.ctnod data. For a given variable, it stores the value at each node within every element across the entire mesh. Element based storage retains the discontinuous fields between elements with different materials. The file will be generated by using the **contour_by_element option under ***output. Output records in the problem.ctele file each have the following format:

\(v1_{no1el1},~~v1_{no2el1}~~~ \dots~~~v1_{nonel1}\)\(1^{st}\) variable for element 1

\(v1_{no1el2},~~v1_{no2el2}~~~ \dots~~~v1_{nonel2}\)\(1^{st}\) variable for element 2

\(\dots\)

\(v1_{no1elNE},~~v1_{no2elNE}~~~ \dots~~~v1_{nonelNE}\)\(1^{st}\) variable for element NE

\(v2_{no1el1},~~v2_{no2el1}~~~ \dots~~~v2_{nonel1}\)\(2^{nd}\) variable for element 1

\(v2_{no1el2},~~v2_{no2el2}~~~ \dots~~~v2_{nonel2}\)\(2^{nd}\) variable for element 2

\(\dots\)

\(v2_{no1elNE},~~v2_{no2elNE}~~~ \dots~~~v2_{nonelNE}\)\(2^{nd}\) variable for element NE

\(\dots\)

\(vnv_{no1el1},~~vnv_{no2el1}~~~ \dots~~~vnv_{nonel1}\)variable nv for element 1

\(vnv_{no1el2},~~vnv_{no2el2}~~~ \dots~~~vnv_{nonel2}\)variable nv for element 2

\(\dots\)

\(vnv_{no1elNE},~~vnv_{no2elNE}~~~ \dots~~~vnv_{nonelNE}\)variable nv for element NE

where \(NE\) is the number of the elements in the structure, and \(nv\) the number of values stored per integration point (as given by the **integ section in the file problem.ut).

Different elements do not have the same number of nodes. The storage for different elements within the problem may therefore have different data structure sizes within the same record.

The file problem.ctele may be generated using the following C code:

for(card=0; card < stored_cards; card++) {
   for(var=0; var < number_of_integ_variables; var++) {
      for(ele=0; ele < number_of_elements; ele++) {
         for(node=0; node < number_of_nodes_of_element[ele]; node++) {
            fwrite(&component[node][ele][var][card],4,1,fp);
         }
      }
   }
}

problem.eigen_info If the calculation is an eigen value problem, the resonant frequencies and associated energies for each mode are stored in the file problem.eigen_info. This file is an ASCII formatted text file.

problem.eigen When an eigen value calculation is run, the resonant vectors or modal displacements are stored in the file problem.eigen. The structure of the binary file is ordered mode number, frequency of the mode, and the energy associated to the mode. Thus we have:

\(U1_1\), \(U1_2\), … \(U1_N\), displacement U1

\(U2_1\), \(U2_2\), … \(U2_N\), displacement U2

[\(U3_1\), \(U3_2\), … \(U3_N\), displacement U3 ]

end of the storage of the first mode.

The file problem.eigen may be generated using the following C code:

for(mode=0; mode < number_of_modes; mode++) {
   fwrite(&mode,4,1,fp);
   fwrite(&mode_frequency[mode],4,1,fp);
   fwrite(&mode_energy[mode],4,1,fp);
   for(dim=0; dim < space_dimension ; dim++) {
      for(node=0; node < number_of_nodes_in_mesh; node++) {
         fwrite(&component[dim][node][mode],4,1,fp);
      }
   }
}

Z8 output format#

Description#

While the default Z7 format uses results.integ, results.node, results.ctnod … result files, the Z8 format uses a tree allowing to read results for which mesh changes from one map to another.

The figure below shows the structure of the file system containing result and mesh files.

Syntax#

The Z8 format can be activated by modifying the default value of the global parameter Solver.OutputFormat to Z8, e.g. by adding in the .inp file the following commands:

****calcul

    ...

 ***global_parameter
    Solver.OutputFormat Z8
    Zmaster.OutputFormat Z8 ...

****return

The Z8 format file structure is organized as follows:

one main directory named result.zres (implying that the .inp file is result.inp, and the execution command “Zrun result”);
some sub-directories respectively named fea.00.01.zres, fea.00.02.zres … created at each remeshing. Each \(i^{th}\) remeshing generates a corresponding fea.00.i.zres sub-directory. Each sub-directory contains:
- an ASCII file named contents.txt that describes the name, the type (scalar, tensor …), and the location (at nodes, at integration points, extrapolated at averaged nodes …) of the physical quantities stored in result files;
- the current mesh file i.e. an ASCII file with a .geof extension;
- a list of sub-directories named m.00001, m.00002 …, corresponding to the list of output maps (computational times for wich user wants results to be written), and containing:
  - an ASCII file named map.txt that describes the current output map (cycle number, sequence number, increment number, time value …);
  - binary files containing the results computed for each physical quantity to be written.

This file system is directly machine-readable using Zmaster. Accordingly, users can visualize computational results for which mesh changes from one map to another.

The figure below shows a crack propagation during a computation implying remeshing.

Z-set output formats

On this page

Z-set output formats#

Z7 output format#

Z8 output format#

Description#

Syntax#