LIMS File Formats in Nutshell
Introductory Note
This file is applicable to LIMS 4.2 and 5.0. Note that version 4.2 does not support 1D or 3D geometry, though it understands the 3D data format. Thus, it aborts reading of the file with
error if 3D structure is detected. 1D geometry has not been envisioned in LIMS 4.2, so some input error might be expected when trying to read such a file into 4.2.
Binary format description assumes that the proper data structure definitions (dataexch.h) are available to the reader. Thus, their description should be more considered internal LIMS development document. Use of these formats is meant to support faster – and smaller – data storage and exchange for LIMS package. It uses the LIMS internal data formats, which change inevitably from version to version. DMP files should be used for data exchange by other programs.
DMP File Format
This is a human readable, text format. Sequence of data is fixed, empty and comment lines may be inserted and depending on the problem some data may be skipped.
Alternatives
The format comes in two flavors: old one, which is written for isothermal, constant cure and fully 2D data and is the same as that for releases 4.0 and 4.1, and a more complete ‘new’ format allowing 3D mesh and cure and temperature solution. The additional data are advertized by:
- one or more ‘header’ lines, which are actually comments at the beginning of a file:
#!Contains Cure Solution Data #!Contains Temperature Solution Data #!Contains 3D Geometry
- Comment statement at the beginning of each result section, following the time which may be one of the following
#!Contains Cure Solution Data #!Contains Temperature Solution Data
Note that the geometry (2D or 3D) is set once for all in the first write, while cure/temperature solution might be switched on/off during the processing. What is most important is that the isothermal, no cure 2D problem produces the same file as before. Thus it can be handled by the same filters. Note that a reader that uses free formated lines, skips data not known to it and ignores contents of headers can read the new file format and get the same data from it.
The file consists of a geometry section followed by one or more ‘result’ or ‘state’ sections. The geometry section contains nodal table, element table and resin description. The result section contains gate table, thermal boundary condition table (optionally) and nodal result table. The formats in detail are as follows:
Geometry Section
Geometry section consists of nodal coordinates and element data, including connectivity. The last part in this section is the resin description.
Nodal table
Nodal table looks as follows:
Number of nodes : <Number> Index x y z ================================================ Data lines 1 to Number ...
Data Lines are printed using the following format specifier :
" %5d %14lf %14lf %14lf\n"
in traditional C way (fprintf). Index may be either 0-based or 1-based. In any case, the base is determined from the first line in nodal data and must be consistent in element data as well. The index provides some integrity checking and is referred in elements.
Beginning with 4.2 LIMS writes DUMP data with 1-based indices, to be consistent with the IN file and user commands.
Element Table
Element table is next. It is formatted as follows:
Number of elements : <Number> Index NNOD N1 N2 N3 (N4) (N5) (N6) (N7) (N8) h Vf Kxx Kxy Kyy Kzz Kzx Kyz ============================================================================================================================================================================== Data lines 1 to Number .....
Again, the index is zero or one based, but the base must be the same as in the nodal data. The same concerns the nodal indices in the element description. Number of nodes is 2 (bar) 3 (triangle), 4 (quad), or letter T (tetrahedron-4 vertices), B (brick – 8 vertices) or W (wedge – 6 vertices). Missing nodal numbers are replaced by spaces. In two dimensional elements only the first three permeability components are filled in. The formatting is done by the following strings:
" %5d 2 %5d %5d %14lf %14lf %14lg\n" " %5d 4 %5d %5d %5d %5d %14lf %14lf %14lg %14lg %14lg\n" " %5d 3 %5d %5d %5d %14lf %14lf %14lg %14lg %14lg\n" " %5d T %5d %5d %5d %5d %14lf %14lf %14lg %14lg %14lg %14lg %14lg %14lg\n" " %5d B %5d %5d %5d %5d %5d %5d %5d %5d %14lf %14lf %14lg %14lg %14lg %14lg %14lg %14lg\n" " %5d W %5d %5d %5d %5d %5d %5d %14lf %14lf %14lg %14lg %14lg %14lg %14lg %14lg\n"
For the ‘old’ style data, header and data printed are shorter in format, as follows:
NNOD N1 N2 N3 (N4) h Vf Kxx Kxy Kyy ================================================================================================================
and the strings for formating are similarly shortened to:
" %5d 4 %5d %5d %5d %5d %14lf %14lf %14lg %14lg %14lg\n" " %5d 3 %5d %5d %5d %14lf %14lf %14lg %14lg %14lg\n"
Note that in this case only 2D elements are allowed.
Resin Data
The viscosity is described on two lines, as follows:
Resin Viscosity model NEWTON Viscosity : Number
If the newer format is used, it is followed by 1 (or possibly two) lines:
Resin Cure model NONE USED
If the solution for temperature is allowed, the following is printed next:
Resin : k=<Number> Alpha=<Number>
Results Section
The result section may be repeated as often as needed. It contains only the data that may change as the filling progresses, i.e., the gates and temperature boundary conditions, and the nodal results. The section starts with the tame value, formated as:
Results at <time>
possibly followed by the above mentioned warning comments. Here, <time> is the simulated time of the filling. This header is followed by two (no temperature solution) or three tables:
Gate Table
The format of Gate table is:
Number of Current Gates : <number>
Type Node Value Cure Temperature
===========================================================
Data blocks for 1 to number (actually 0 to number-1)...
...
The table can have only 4 types of gates in, pressure, flowrate, mixed or vent, given using the following format strings. The node is 0 based index:
"Pressure at %5d p=%15.6lg " "Flow Rate at %5d Q=%15.6lg " "Mixed at %5d Q=%15.6lg+%15.6lg*p" "Vent at %5d p=%15.6lg "
These data are followed, assuming that cure is enabled, by a cure degree at the gate (not vent) formated by
" %10.8f"
and, if temperature is enabled, the pressure value formated as
"%12.8f"
In ‘old’ format, header is somehow shorter:
Type Node Value ==============================
and the cure and temperature values do not appear.
Thermal Boundary Conditions
These are a table without any counter – that is the same as the element count. The header and lines are formated as:
Ttop Tbot BCCtop BCCbot Tpref kpref Alphpref ================================================================================================== Line... ....
The lines, containing top, bottom and preform BCs as well as k and Alpha for the preform material, are formatted using the following string
"%13g %13g %13g %13g %13g %13g %13g\n"
There is one line per element, but it is used only for non-isothermal simulations. It is not present in old format and2D and 3D iso-thermal cases, whether they solve for the cure or not. If one solves for cure only, the table is substituted by a line:
Global Temperature :<Floating Point Value>
Nodal Results
Again table without any counter. The number of nodes is known previously. Index (0 base) is still there guarding the data integrity. The header looks like:
Nodal results Index Pressure Flow Rate Fill Factor Fill Time Cure Tmid Ttop Tbot ================================================================================================================================
The results are formated using
" %5d %14lg %14lg %14lg %14lg"
and the following cure and temperature values using
" %14lg"
resp.
" %14lg %14lg %14lg"
assuming that cure resp. non-isothermal solution was enabled.
Again, a different, shorter header is used for isothermal, fully 2D no cure problems (so that the old readers can recognize it):
Nodal results Index Pressure Flow Rate Fill Factor Fill Time ========================================================================
but the data is printed using the same string (minus cure and temperature).
Drawbacks and Possible Problems
The permeability is a part of geometry, but it might be actually changed during the simulation. In such a case, write a brand new file for the data! Some data might be missing fromthe table, because headers are – unless the old type is being processed – general. This means that there are always Cure and Temperature fields at gates, though no numbers are available
for iso-thermal simulation.
MEMORY “File” Format
The file format has been adjusted to several possible versions. The format does not change with enabling or disabling ANY realism settings, but some data might be invalid or irrelevant if the flags show them to be absent. The format is handled not by the filesystem, but rather via. lcbinpad.dll, so you should be familiar with this dll and slave lims operation before tinkering with it. The description magic is “MEMO 5.0.0” in string descriptor and size of data in the integer number. These are stored in description space, not in the data space. The data chunk is written to the memory file as follows. Note that the data types are standard win32 data types. The program was, however, tested with Intel chips only
| Solve Temperature | int | Boolean flag to show whether the temperature solution was enabled |
| Solve Cure | int | Boolean flag to show whether the cure solution was enabled. Must be true if the thermal solution was |
| Output Time | double | Time at the simulation (seconds) |
| Global Temperature | double | Global temperature. Meaningful only if thermal solution not enabled but cure solution is allowed. |
| Size of Data | int | Length of the file |
| Number of Nodes | int | Counters for entities…. |
| Number of Elements | int | … |
| Number of Gates | int | … |
| Nodes | NODAL_RESULT[] | All of the nodal information in array of structure type. Obviously, temperature or cure values are valid ONLY if the solution for them was enabled |
| Elements | GEOM_ELEM[] | All of the element data. Includes permeability, thermal data and thermal boundary conditions if thermal problem. Again, some values (thermal data, 3D permeability values etc.) may contain ilegal or senseless values |
| Resin Data | RESIN_DATA | All of the data for resin. Pointers to names for viscosity and cure model will be invalid, these strings follow the structure |
| Viscosity Model | char[32] | Name of the viscosity model as a string. Filled with zeroes to 32 byte width |
| Cure Model | char[32] | The same for the cure model |
| Gates | INLET_GATE[] | All the gate information. Cure and temperature data valid ONLY if appropriate solution was enabled. |
BND File Format
This format has been cast into the SAME format as the MEMO file. Again, the machine specific data types are used. However, magic string “BIND 5.0.0” filled by ‘\0’ characters to 16 characters now stands as a header in the file prior to the data, so that the whole file structure looks like:
| Magic | char[16] | The header containing string “BIND 5.0.0” filled up with zeroes |
| Solve Temperature | int | Boolean flag to show whether the temperature solution was enabled |
| Solve Cure | int | Boolean flag to show whether the cure solution was enabled. Must be true if the thermal solution was |
| Output Time | double | Time at the simulation (seconds) |
| Global Temperature | double | Global temperature. Meaningful only if thermal solution not enabled but cure solution is allowed. |
| Size of Data | int | Length of the file |
| Number of Nodes | int | Counters for entities…. |
| Number of Elements | int | … |
| Number of Gates | int | … |
| Nodes | NODAL_RESULT[] | All of the nodal information in array of structure type. Obviously, temperature or cure values are valid ONLY if the solution for them was enabled |
| Elements | GEOM_ELEM[] | All of the element data. Includes permeability, thermal data and thermal boundary conditions if thermal problem. Again, some values (thermal data, 3D permeability values etc.) may contain ilegal or senseless values |
| Resin Data | RESIN_DATA | All of the data for resin. Pointers to names for viscosity and cure model will be invalid, these strings follow the structure |
| Viscosity Model | char[32] | Name of the viscosity model as a string. Filled with zeroes to 32 byte width |
| Cure Model | char[32] | The same for the cure model |
| Gates | INLET_GATE[] | All the gate information. Cure and temperature data valid ONLY if appropriate solution was enabled. |
GnuMesh (gmsh) File Format
The input-output system now cooperates with open source freeware GMSH pre- and post-processor, reading and writing the ASCII version 2 mesh (.msh) files.
For output one selects the format by
SETOUTTYPE “GMSH”
or
SETOUTTYPE “MSH”
Then write the file using WRITE command. Note that there is a different, output only “MESH” format, a legacy one, that does not support much of the LIMS capabilities but
uses the “MESH” identifier. The output file contains both the results (time, pressure and fill factor) and the preform data (thickness, fiber volume fraction and permeability). The latter is, however, written as a tensor value, and GMSH currently (2.50) displays only the effective value (VonMises) contours for such a tensor. This file format should be appendable, the result sets are labeled with time value.
For input, the LIMS part is again
SETINTYPE “GMSH”
and reading the mesh using READ. SETINTYPE “AUTO” should work, too, and the file selector on Windows contains the proper filter (“msh”).
This will read only the nodes and elements from the file, and the elements it does not understand (such as one node elements or higher order ones) will be skipped. Orphan nodes, if any, are left intact, and will cause trouble. Note that GMSH tends to generate one-nodal elements for construction points and similar distractions and these nodes may not be connected to any element. LimsUI can actually clean these automatically – just save the file from LIMS command line as DUMP file and load it into LimsUI.
The material data are initialized to a default value (Thickness 0.01, Vf=0.5, Kxx=Kyy=1E-11, Kzz=1e-12, Viscosity=0.2). This can be overridden from current directory, from file “MSH_default.txt” if the file is present. This file can contain new default values as well as viscosity and it allows different material assignment to “physical” zones in GMSH mesh. The file format is as follows:
Each line in file starts with zone number, followed by dimension (1, 2 or 3) and proper material coefficients depending on the dimension:
- 1D: cross-section Vf Kxx
- 2D: thickness Vf Kxx Kxy Kyy
- 3D: 1.0 Vf Kxx Kxy Kyy Kzz Kzx Kyz
These are followed by boolean (0 or 1) describing whether CS is given (otherwise element CS is assumed which makes sense only for isotropic/in-plane isotropic materials) and then by number of number triplets (vectors) (1 2 or 3) giving CS x, y and z axis.
Physical “zone” -1 is actually followed by just a viscosity value and is treated as viscosity. Zone 0 is default material. It is used in several cases:
- When the mesh refers to zone data that is unavailable.
- When the zone data is available but its dimension is lower than the element dimension.
Note that if one creates default material with dimensions lower than 3, it may be impossible to load 3D elements at all unless their particular physical zone data are 3D.
Effective use of the zones (beyond new defaults) is difficult and requires good grasp of GMSH, which the author does not pretend to have. GMSH generates the numbers internally and you will have to deal with its scripts to get it.
Notes on IN File Format
- In format is read as it is. Gates are coerced to LIMS 4.2 system; i.e., vents are gates and cure and temperature gates are required for every inlet gate, but do not go as independent gates. Thus the number of gates in LIMS system does not necessarily correspond to that in the IN file.
- Resin and cure models previously supported are read. Resin information is mostly ignored; only temperature and cure dependent newtonian behavior is accepted.
- “SENSOR” blocks are still ignored. Temperature solution parameters are ignored as well, as the algorithm has changed.
- Material properties, both permeability and thermal (including boundary conditions), are coerced to be an “element” property, rather than independent structure.
Notes on Output Only File Formats
TECPLOT Files
Content
If cure solution is enabled, TECPLOT files include result “Cure” that gives a cure value at individual points. If temperature solution is enabled, TECPLOT files include results “Tmid”, “Ttop” and “Tbot” that give the temperature at midplane, top and bottom surface.
Geometry
If the geometry is purely 2D, nothing changes. If it is fully 3D, i.e., it does not contain ANY 2D elements, than the mesh is written as a solid consisting of 8 node brick elements. If the mesh contains both types of elements, it is written as a surface. Solid elements are ‘skinned’ with 4, 5 or 6 sides. Additionally, two extra files are written, with extensions .t2d and .t3d. These contain only two-dimensional part of structure (as 2D quads) and three-dimensional part of structure, respectively. Those can be combined within TECPLOT. Bar elements (1D) are not written into any TECPLOT file. In most cases it does not matter, as the nodes of these elements are lying on 2D or 3D mesh as well.
PATRAN Files
Currently PATRAN filter aborts if there are 3D elements within the mesh. Whenever cure is enabled, “*.cur” result file is written containing the results for cure. If the temperature is being solved for, files “*.tbc”, “*.tto” and “*.tbo” containing results for midplane, top and bottom. No options here…
HISTORY and MESH Files
This is a final release of this LIMS 3.x compatibility format (to be discontinued). The format can not handle 3D geometry, so if it is present, writing fails.
If temperature or at least cure solution is enabled, it mimics LIMS 3.x behavior with 3 temperature and cure nodes. If temperature solution is enabled, this means that 3 temperature values per node are top-, mid- and bottom temperature. Cure is considered constant through the thickness, so the single value is repeated three times to comply with the old format.
If the problem is solved as an iso-thermal, cure only, there are again 3 nodes through the thickness. All the temperature values are the same (global temperature), and cure is repeated 3 times a node as described above.
Region File Format
This file format is used to store region data, which means symbolic names used for groups of elements and nodes. It does not have any default extension. File written by REGSAVE
or GUI consists of 1 or more repetitions of the following block:
Name
Type
Count
<data 5 numbers per line>
Command REGLOAD can read more free format: There can be any number of empty lines and any leading whitespace, data does not have to be 5 per line. Name is the first white-space delimited word on the first nonempty line in block. Type is determined from the first character of the first word on the next nonempty line (E, N or G) and count is the first word (must be number) on the third one.
Recent Comments