Output File Formats
IGB File
Extension: .igb
CARP simulations usually export data to a binary format called IGB. IGB is a format developed at the University of Montreal and originally used for visualizing regularly spaced data. An IGB file is composed of a 1024-byte long header followed by binary data which is terminated by the ASCII form feed character (^L
/ character 12). For unstructured grids, the individual dimensions are meaningless but \(x * y * z\) should be equal to the number of vertices. The header is composed of strings of the following format, separated by white space: Keyword:value
Note that the header must be padded to 1024 bytes.
The first block of key words in IGB keywords need to be specified. The rest are optional.
Keyword | Type | Description |
---|---|---|
x | int | number of samples in x |
y | int | number of samples in y |
z | int | number of samples in z |
t | int | number of samples in t |
systeme | string | big_endian or little_endian |
type | string | binary data type: byte, char, short, long, |
float, double, int, uint, vec3f, vec4f, | ||
vec3d, vec4d | ||
unites | string | units of data |
facteur | float | scaling factor for data |
zero | float | data zero: true value = |
IGB_data facteur + zero | ||
org_x | float | lower right x coordinate |
org_y | float | lower right y coordinate |
org_z | float | lower right z coordinate |
org_t | float | time of first slice |
inc_x | float | distance between x samples |
inc_y | float | distance between y samples |
inc_z | float | distance between z samples |
inc_t | float | time between samples |
dim_x | float | extent in x |
dim_y | float | extent in y |
dim_z | float | extent in z |
dim_t | float | duration |
unites_x | string | units of measure for spatial x dimension |
unites_y | string | units of measure for spatial y dimension |
unites_z | string | units of measure for spatial z dimension |
unites_t | string | units of measure for time |
comment | string | arbitrary comment |
aut_name | string | author's name |
transparent | hex | value for no data |
Dynamic Points File
Extension: .dynpts
Points may also move in space as functions of time. This is often associated with displacement during contraction, for example. The number of points must remain constant for all time instances, as well as the elements defined by them. Dynamic point files use the IGB format (see IGB file) with data type vec3f.
Vector data file
Extension: .vec and .vpts
To display vector data, an auxiliary set of points must be defined by a file with the .vpts suffix. It follows the same format as the nodes file. A file with the same base name but having the extension .vec defines the vector and scalar data. It has the following format:
Format
data.x
data.y
data.z
[scalar_datum]
data.x
data.y
data.z
[scalar_datum]
\(\ldots\)
data.x
data.y
data.z
[scalar_datum]
The scalar datum, as indicated, is optional. The .vec format can also be used for visualization of fiber orientations stored in .lon files. For this sake, a .vpts file must be generated holding the coordinates of the centers of each element in the mesh. This is conveniently achieved with GlElementCenters and changing the fiber file extension to .vec. For example, for a mesh with \(n\) elements and where \(f_{i,\{x,y,z\}}\) corresponds to the components of the fiber vector \(i\):
Format | Example |
---|---|
\(f_{0,x} \, f_{0,y} f_{0,z}\) | 8.12453e-01 -2.22623e-01 1.25001e00 |
\(f_{1,x} \, f_{1,y} f_{1,z}\) | 5.68533e-01 -1.81807e-01 1.04956e00 |
\(\ldots\) | \(\ldots\) |
\(f_{n-1,x} \, f_{n-1,y} \, f_{n-1,z}\) | 5.70671e-01 -1.67572e-01 1.06615e00 |
Vector data can also be input as an IGB file using the types vec3f, vec4f, vec3d, vec4d where 3 or 4 refers to the number of elements in each datum, and d and f refer to float or double. The first 3 elements define the value of the vector field, and the optional 4-th element is the scalar component as above. This file has the suffix .vec.igb.
Auxiliary Grid
Extensions: .pts_t, .elem_t, .dat_t
This format is used by Meshalyer to display additional data on an auxiliary grid. The grid may contain any of the elements forming the main grid (points, lines, surface elements, volume elements), and the elements may change as a function of time. If scalar data has already been read in, the number of time instances in the auxiliary grid must either be one, or the same as the scalar data. The points file may have only one time instance, which is then assumed constant over all time.
A vertex file is mandatory and has the extension .pts_t. An element file is optional. If present, it has the same base name as the vertex file but with the extension .elem_t. Scalar data may also be optionally defined on the auxiliary grid. The file has the same basename as the vertex file but with the extension .dat_t. The file formats follow:
.pts_t | .elem_t | .dat_t | ||
---|---|---|---|---|
#times | #times | #times | ||
#points_time0 | #elements_time0 | #data_time0 | ||
pt(0,0).x | pt(0,0).y | pt(0,0).z | element(0,0) | data(0,0) |
pt(1,0).x | pt(1,0).y | pt(1,0).z | element(1,0) | data(1,0) |
. | . | . | . | . |
. | . | . | . | . |
. | . | . | . | . |
. | . | . | element(M,0) | . |
. | . | . | #elements_time1 | . |
. | . | . | element(0,1) | . |
. | . | . | element(1,1) | . |
. | . | . | . | . |
pt(N,0).x | pt(N,0).y | pt(N,0).z | . | data(N,0) |
#points_time1 | . | #data_time1 | ||
pt(0,1).x | pt(0,1).y | pt(0,1).z | . | data(0,1) |
pt(1,1).x | pt(1,1).y | pt(1,1).z | . | data(1,1) |
. | . | . | . | . |
. | . | . | element(M,1) | . |
. | . | . | #elements_time2 | . |
. | . | . | element(0,2) | . |
. | . | . | . | . |