STARDISOUTPUT(5)  File Formats Manual  STARDISOUTPUT(5) 
NAME
stardisoutput
—
output format of
stardis(1)
results
DESCRIPTION
stardisoutput
describes the output format
of the stardis(1) program.
Any stardis(1) result is
written to standard output, even though some additional informations can be
written in files.
The type of the data that are generated depends on the options
used when stardis(1) is
invoked. When invoked with one of the basic computation options
(p
, P
,
m
, s
or F
),
stardis(1) outputs a single
Monte Carlo result. On the opposite,
stardis(1) ouputs compound
results when invoked with option S
or
R
. Additionally, options g
and G
make
stardis(1) compute and
output a Green function and possibly information on heat paths' ends. Most
of the complex data output is in VTK format.
Note that some special options (v
,
h
or
d
) that does not involve any computation produce
output including information on the
stardis(1) software (their
ouputs will not be described thereafter) or the provided thermal system.
Any physical quantity in output is in the International System of Units (second, metre, kilogram, kelvin) except the coordinates that are in same system as the geometry.
In what follows, some lines end with a backslash
(\
). This is used as a convenience to continue a
description next line. However, this trick cannot be used in actual
description files and actual description lines must be kept singleline.
Text introduced by the sharp character (#
) in
descriptions is a comment and is not part of the description.
The output format is as follows:
⟨output⟩  ::=  ⟨mcestimate⟩ 
  ⟨greenfunction⟩  
  ⟨geometrydump⟩  
  ⟨infraredimage⟩  
  ⟨heatpaths⟩ 
The following sections describe in detail each of these possible outputs.
MONTE CARLO ESTIMATE
When stardis(1) is
used to calculate a single Monte Carlo estimate, either a temperature or a
flux, the estimate is output first to standard output, possibly followed by
some of the heat paths involved in the computation if option
D
was used too. Two different formats are possible:
a raw, numbers only format (the default) or an extended format that mixes
numbers and their descriptions (if option e
is used).
⟨mcestimate⟩  ::=  ⟨probetemp⟩ # Options
P or
p 
  ⟨mediumtemp⟩ # Option
m 

  ⟨meantemp⟩ # Option
s 

  ⟨meanflux⟩ # Option
F 

⟨probetemp⟩  ::=  ⟨probetempraw⟩  ⟨probetempext⟩ 
⟨probetempraw⟩  ::=  ⟨estimate⟩ ⟨failures⟩ 
⟨probetempext⟩  ::=  Temperature
at ⟨position⟩
⟨time⟩ \ 
⟨estimatetempext⟩ ⟨failuresext⟩  
⟨mediumtemp⟩  ::=  ⟨mediumtempraw⟩  ⟨mediumtempext⟩ 
⟨mediumtempraw⟩  ::=  ⟨estimate⟩ ⟨failures⟩ 
⟨mediumtempext⟩  ::=  Temperature
in medium ⟨mediumname⟩
\ 
⟨time⟩ ⟨estimatetempext⟩ ⟨failuresext⟩  
⟨meantemp⟩  ::=  ⟨meantempraw⟩  ⟨meantempext⟩ 
⟨meantempraw⟩  ::=  ⟨estimate⟩ ⟨failures⟩ 
⟨meantempext⟩  ::=  Temperature
at boundary ⟨stlpath⟩
\ 
⟨time⟩ ⟨estimatetempext⟩ ⟨failuresext⟩  
⟨meanflux⟩  ::=  ⟨meanfluxraw⟩  ⟨meanfluxext⟩ 
⟨meanfluxraw⟩  ::=  ⟨estimate⟩ ⟨estimate⟩ ⟨estimate⟩ \ 
⟨estimate⟩ ⟨estimate⟩ ⟨failures⟩  
⟨meanfluxext⟩  ::=  Temperature
at boundary ⟨stlpath⟩
\ 
⟨time⟩ ⟨estimatetempext⟩  
Convective flux
at boundary ⟨stlpath⟩
\ 

⟨time⟩ ⟨estimatefluxext⟩  
Radiative flux
at boundary ⟨stlpath⟩
\ 

⟨time⟩ ⟨estimatefluxext⟩  
Imposed flux at
boundary ⟨stlpath⟩ \ 

⟨time⟩ ⟨estimatefluxext⟩  
Total flux at
boundary ⟨stlpath⟩ \ 

⟨time⟩ ⟨estimatefluxext⟩  
⟨failuresext⟩  
⟨estimate⟩  ::=  ⟨expectedvalue⟩ ⟨standarderror⟩ 
⟨estimatetempext⟩  ::=  ⟨expectedvalue⟩ K
+/ ⟨standarderror⟩ 
⟨estimatefluxext⟩  ::=  ⟨expectedvalue⟩ W
+/ ⟨standarderror⟩ 
⟨expectedvalue⟩  ::=  real 
⟨standarderror⟩  ::=  real 
⟨failures⟩  ::=  ⟨errorcount⟩ ⟨successcount⟩ 
⟨errorcount⟩  ::=  integer 
⟨successcount⟩  ::=  integer 
⟨position⟩  ::=  [real, real, real] 
⟨time⟩  ::=  at
t= real 
  with t in
[real, real] 

⟨mediumname⟩  ::=  string 
⟨stlpath⟩  ::=  path 
GREEN FUNCTION
The Green function is generated, either in binary or ascii format,
when a greencompatible
stardis(1) simulation option
is used in conjuction with option G
for a binary
output, or option g
for an ascii output. For every
successful heat path sampled carrying out the simulation, the solver records
all the elements of the path history relevant to link the various imposed
temperature, flux and volumic power values to the simulation result. The
output is made of tables containing the different media and boundaries and
their imposed temperature, flux and volumic power values, followed by the
heat paths' history. Also, option G
make it
possible to output heat paths' end information on an ascii, csv formated
file.
⟨greenfunction⟩  ::=  ⟨greenascii⟩ #
Option g 
  ⟨greenbinary⟩
[⟨paths⟩] #
Option G 
The Monte Carlo estimate and standard deviation for a given set of settings can be computed as the mean and standard deviation of the samples of the Green function computed using these settings. Each sample can be computed as follows:
 get the temperature of the ending boundary, medium or Trad
 add the temperature gain of each power term
 add the temperature gain of each flux term
ASCII format
Beyond the file format described below,
stardis(1) could write
comments (characters behind the hash mark (#
)) or
blank lines (lines without any characters or composed only of spaces and
tabs). These are not part of the file format and should be ignored.
The ASCII file format of a Green function is as follows:
⟨greenascii⟩  ::=  BEGIN
GREEN 
⟨timerange⟩  
⟨#solids⟩ ⟨#fluids⟩ \  
⟨#dirichletboundaries⟩ \  
⟨#robinboundaries⟩ \  
⟨#neumannboundaries⟩ \  
⟨#successes⟩ ⟨#failures⟩  
⟨solid⟩  
...  
⟨fluid⟩  
...  
⟨dirichletboundary⟩  
...  
⟨robinboundary⟩  
...  
⟨neumannboundary⟩  
...  
⟨radtemp⟩  
⟨samples⟩  
⟨timerad⟩  ::=  real real 
⟨#solids⟩  ::=  integer 
⟨#fluids⟩  ::=  integer 
⟨#dirichletboundaries⟩  ::=  integer 
⟨#robinboundaries⟩  ::=  integer 
⟨#neumannboundaries⟩  ::=  integer 
⟨#successes⟩  ::=  integer 
⟨#failures⟩  ::=  integer 
⟨solid⟩  ::=  ⟨greenid⟩ ⟨name⟩ ⟨lambda⟩ ⟨rho⟩ ⟨cp⟩ \ 
⟨power⟩ ⟨initialtemp⟩ ⟨imposedtemp⟩  
⟨fluid⟩  ::=  ⟨greenid⟩ ⟨name⟩ ⟨rho⟩ ⟨cp⟩ \ 
⟨initialtemp⟩ ⟨imposedtemp⟩  
⟨lambda⟩  ::=  real # Conductivity > 0 [W/m/K] 
⟨rho⟩  ::=  real # Volumic mass > 0 [kg/m^3] 
⟨cp⟩  ::=  real # Capacity > 0 [J/K/kg] 
⟨power⟩  ::=  real # Volumic power [W/m^3] 
⟨initialtemp⟩  ::=  real # Temperature [K] 
⟨imposedtemp⟩  ::=  real # Temperature [K] 
⟨dirichletboundary⟩  ::=  ⟨greenid⟩ ⟨name⟩ ⟨temp⟩ 
⟨robinboundary⟩  ::=  ⟨greenid⟩ ⟨name⟩ ⟨tempref⟩ \ 
⟨emissivity⟩ ⟨specularfraction⟩ ⟨hc⟩ \  
⟨temp⟩  
⟨neumannboundary⟩  ::=  ⟨greenid⟩ ⟨name⟩ ⟨flux⟩ 
⟨emissivity⟩  ::=  real # In [0,1] 
⟨specularfraction⟩  ::=  real # In [0,1] 
⟨hc⟩  ::=  real # Convective coefficient [W/m^2/K] 
⟨temp⟩  ::=  real # Temperature [K] 
⟨tempref⟩  ::=  real # Reference temperature [K] 
⟨flux⟩  ::=  real # [W/m^2] 
⟨radtemp⟩  ::=  ⟨greenid⟩ ⟨Trad⟩ ⟨Tradref⟩ 
⟨Trad⟩  ::=  real # Radiative temperature [K] 
⟨Tradref⟩  ::=  real # Reference temperature [K] 
⟨sample⟩  ::=  ⟨endtype⟩ ⟨greenid⟩ \ 
⟨#powerterms⟩ ⟨#fluxterms⟩ \  
⟨powerterm⟩ ... ⟨fluxterm⟩ ...  
⟨endtype⟩  ::=  ⟨enddirichlet⟩ 
  ⟨endrobin⟩  
  ⟨endTrad⟩  
  ⟨endfluid⟩ # Fluid temperature  
  ⟨endsolid⟩ # Solid temperature  
⟨enddirichlet⟩  ::=  T 
⟨endrobin⟩  ::=  H 
⟨endTrad⟩  ::=  R 
⟨endfluid⟩  ::=  F 
⟨endsolid⟩  ::=  S 
⟨#powerterms⟩  ::=  integer 
⟨#fluxterms⟩  ::=  integer 
⟨powerterm⟩  ::=  ⟨greenid⟩ ⟨factor⟩ 
⟨fluxterm⟩  ::=  ⟨greenid⟩ ⟨factor⟩ 
⟨factor⟩  ::=  real 
⟨greenid⟩  ::=  integer 
⟨name⟩  ::=  string 
Binary format
Binary Green outputs are formated according to the various C types from the stardisgreen.h header file. The output begins with a header (of type struct green_file_header) that includes counts, followed by descriptions (of type struct green_description) and samples. Thereafter is the format of binary Green outputs. This output is produced by fwrite calls and does not take care of endianness.
The binary file format of a Green function is as follows:
⟨greenbinary⟩  ::=  GREEN_BIN_FILE: 
⟨file_format_version⟩  
⟨#descriptions⟩  
⟨#solids⟩  
⟨#fluids⟩  
⟨#robinboundaries⟩  
⟨#dirichletboundaries⟩  
⟨#neumannboundaries⟩  
⟨#solidfluidconnects⟩  
⟨#solidsolidconnects⟩  
⟨#successes⟩  
⟨#failures⟩  
⟨Trad⟩  
⟨Tradref⟩  
⟨timerange⟩  
⟨description⟩ ...  
⟨sample⟩ ...  
⟨file_format_version⟩  ::=  unsigned 
⟨#descriptions⟩  ::=  unsigned 
⟨#solids⟩  ::=  unsigned 
⟨#fluids⟩  ::=  unsigned 
⟨#robinboundaries⟩  ::=  unsigned 
⟨#dirichletboundaries⟩  ::=  unsigned 
⟨#neumannboundaries⟩  ::=  unsigned 
⟨#solidfluidconnects⟩  ::=  unsigned 
⟨#solidsolidconnects⟩  ::=  unsigned 
⟨#successes⟩  ::=  size_t 
⟨#failures⟩  ::=  size_t 
⟨Trad⟩  ::=  double # Radiative temperature 
⟨Tradref⟩  ::=  double # Reference radiative temperature 
⟨timerange⟩  ::=  double[2] 
⟨description⟩  ::=  struct green_description 
⟨sample⟩  ::=  ⟨sampleheader⟩ 
⟨powerid⟩ ...  
⟨fluxid⟩ ...  
⟨powerweight⟩ ...  
⟨fluxweight⟩ ...  
⟨sampleheader⟩  ::=  struct green_sample_header 
⟨powerid⟩  ::=  unsigned 
⟨fluxid⟩  ::=  unsigned 
⟨powerweight⟩  ::=  double 
⟨fluxweight⟩  ::=  double 
Binary Green function can be followed by partial information on the sampled paths. The output data are restricted to paths' ends.
⟨paths⟩  ::=  "End",
"End ID", "X", "Y", "Z",
\ 
"Elapsed
Time" 

⟨pathend⟩  
...  
⟨pathend⟩  ::=  ⟨endname⟩,
⟨endid⟩,
⟨x⟩,
⟨y⟩,
⟨z⟩, \ 
⟨elapsedtime⟩  
⟨endname⟩  ::=  string # Boundary name or TRAD 
⟨endid⟩  ::=  integer 
⟨x⟩  ::=  real 
⟨y⟩  ::=  real 
⟨z⟩  ::=  real 
⟨elapsedtime⟩  ::=  real # [s] 
GEOMETRY DUMP
A ⟨geometrydump⟩ is generated
when stardis(1) is invoked
with option d
. In this mode,
stardis(1) outputs the
system geometry, as submitted in
stardisinput(5)
description, to standard output in VTK format. The output geometry is
not the
concatenation of the various geometry files used in
stardisinput(5)
description. It is the result of a deduplication process that removes
duplicate and degenerated triangles from the submited geometry. Additionaly,
as permitted by the VTK format, the output geometry is decorated with many
different properties provided to help users understand the description
processing, including possible errors.
If errors are detected, some optional errorrelated data fields are included in the geometry file. Some errors report a bytriangle error status, other errors report a byenclosure error status.
Also, holes in the geometry, if any, are reported in geometry dumps. A hole is defined by its frontier that is a collection of triangles surrounding the hole. Such triangles are detected as having their 2 sides in the same enclosure, but with a different medium on each side.
Media information is provided in two different flavours. First the
medium on front and back sides of triangles can be found through the
Front_medium
and Back_medium
fields. These fields use the special value INT_MAX for
sides with no defined medium, as one can expect on boundary triangles. On
the other hand, medium information provided by the Enclosures_internal_media
field displays the id of the medium created to hold boundary information for
boundary triangles. In either case, media numbering information can be found
in log messages if option V
3
is used in conjunction with the d
dump option.
The VTK layout is as follows:
⟨geometrydump⟩  ::=  # vtk DataFile Version
2.0 
⟨description⟩  
ASCII 

DATASET
POLYDATA 

⟨vertices⟩  
⟨triangles⟩  
CELL_DATA
⟨#triangles⟩ 

⟨frontmedia⟩  
⟨backmedia⟩  
⟨interfaces⟩  
⟨uniqueids⟩  
⟨userids⟩  
[⟨mergeconflicts⟩]  
[⟨propertyconflicts⟩]  
⟨fileids⟩  
⟨boundaries⟩  
[⟨computeregion⟩]  
⟨encloroverlaps⟩  
⟨description⟩  ::=  string # Up to 256 characters 
Geometry
⟨vertices⟩  ::=  POINTS
⟨#vertices⟩
double 
⟨x⟩ ⟨y⟩ ⟨z⟩  
...  
⟨triangles⟩  ::=  POLYGONS
⟨#triangles⟩
⟨#triangles*4⟩ 
3
⟨vertexid⟩
⟨vertexid⟩
⟨vertexid⟩ 

... 
List triangle indices after stardis(1) deduplication:
⟨uniqueids⟩  ::=  SCALARS Unique_ID
unsigned_int 1 
LOOKUP_TABLE
default 

⟨triangleid⟩ # In [0, ⟨#triangles⟩]  
... # Up to ⟨#triangles⟩ 
List triangle indices before deduplication to let the caller indentify his geometry as submitted to stardis(1):
⟨userids⟩  ::=  SCALARS User_ID
unsigned_int 1 
LOOKUP_TABLE
default 

⟨triangleid⟩  
... # Up to ⟨#triangles⟩ 
List the file identifier in which each triangle first appeared:
⟨fileids⟩  ::=  SCALARS
Created_at_sg3d_geometry_add \ 
unsigned_int
1 

LOOKUP_TABLE
default 

⟨filerank⟩  
... # Up to ⟨#triangles⟩  
⟨#vertices⟩  ::=  integer 
⟨#triangles⟩  ::=  integer 
⟨#triangles*4⟩  ::=  integer 
⟨vertexid⟩  ::=  integer # In [0, ⟨#vertices⟩] 
⟨triangleid⟩  ::=  integer 
⟨x⟩  ::=  real 
⟨y⟩  ::=  real 
⟨z⟩  ::=  real 
⟨filerank⟩  ::=  integer 
Properties
⟨frontmedia⟩  ::=  SCALARS
Front_medium unsigned_int 1 
LOOKUP_TABLE
default 

⟨mediumid⟩  ⟨undefmedium⟩  
... # Up to ⟨#triangles⟩  
⟨backmedia⟩  ::=  SCALARS
Back_medium unsigned_int 1 
LOOKUP_TABLE
default 

⟨mediumid⟩  ⟨undefmedium⟩  
... # Up to ⟨#triangles⟩  
⟨interfacesmedia⟩  ::=  SCALARS
Interface unsigned_int 1 
LOOKUP_TABLE
default 

⟨interfaceid⟩  
... # Up to ⟨#triangles⟩  
⟨boundaries⟩  ::=  SCALARS
Boundaries unsigned_int 1 
LOOKUP_TABLE
default 

⟨boundaryid⟩  
... # Up to ⟨#triangles⟩  
⟨mediumid⟩  ::=  integer 
⟨undefmedium⟩  ::=  INT_MAX 
⟨interfaceid⟩  ::=  integer 
⟨boundaryid⟩  ::=  integer 
Compute region
Define which triangles are members of the surface on which
stardis(1) performs the
calculation (options F
, S
or s
):
⟨computeregion⟩  ::=  SCALARS
Compute_region unsigned_int 1 
LOOKUP_TABLE
default 

⟨regionmembership⟩  
... # Up to ⟨#triangles⟩  
⟨regionmembership⟩  ::=  0
# Not member 
  1
# The front side is member 

  2
# The back side is member 

  3
# Both sides are members 

  INT_MAX # Error: must not be member 
Check description problems
Define which triangles have an invalid media definition when merging partitions:
⟨mergeconflicts⟩  ::=  SCALARS
Merge_conflict int 1 
LOOKUP_TABLE
default 

⟨mergeconflictid⟩  
... # Up to ⟨#triangles⟩  
⟨mergeconflictid⟩  ::=  0
# No conflict 
  1
# Conflict 
Define which triangles have an invalid limit condition or an invalid connection and report what is wrong:
⟨propertyconflicts⟩  ::=  SCALARS
Property_conflict int 1 
⟨propconflictid⟩  
...  
⟨propconflictid⟩  ::=  0
# No conflict 
  1
# Robin btw 2 defined fluids 

  2
# Robin btw 2 undefined fluids 

  3
# Robin on fluid applied to solid 

  4
# Robin btw 2 defined solids 

  5
# Robin btw 2 undefined solids 

  6
# Robin on solid applied to fluid 

  7
# Robin&Neumann btw 2 defined media 

  8
# Robin&Neumann btw 2 undefined media 

  9
# Robin&Neumann applied to fluid 

  10
# Dirichlet btw 2 defined solids 

  11
# Dirichlet btw 2 undefined solids 

  12
# Dirichlet on solid applied to fluid 

  13
# Neumann btw 2 defined media 

  14
# Neumann btw 2 undefined media 

  15
# Neumann applied to fluid 

  16
# Solid/fluid btw 2 solids 

  17
# Solid/fluid btw 2 fluids 

  18
# Solid/fluid used as boundary 

  19
# Solid/fluid btw 2 undefined media 

  20
# No connection btw fluid/fluid 

  21
# No connection btw solid/fluid 

  22
# No boundary around fluid 

  23
# No boundary around solid 

  24
# Invalid part of a compute surface 
Enclosure
⟨encloroverlaps⟩  ::=  ⟨enclinformation⟩ 
  ⟨overlappings⟩  
⟨enclinformation⟩  ::=  [⟨holes⟩] # If any 
⟨enclosures⟩  
⟨enclosures⟩  ::=  FIELD FieldData
2 
⟨enclosuresgeoms⟩  
⟨enclosuresmedia⟩ 
Report which triangles surround a hole:
⟨holes⟩  ::=  SCALARS
Hole_frontiers unsigned_int 1 
LOOKUP_TABLE
default 

⟨holemembership⟩  
... # Up to ⟨#triangles⟩  
⟨holemembership⟩  ::=  0
# Not surrounding a hole 
1
# Surrounding a hole 
List the enclosures to which the triangle belongs and report the validity status of the enclosures:
⟨enclosuresgeoms⟩  ::=  Enclosures
⟨#enclosures⟩ \ 
⟨#triangles⟩
unsigned_char 

⟨enclstatus⟩ ... # Up to ⟨#enclosures⟩  
... # Up to ⟨#triangles⟩  
⟨enclstatus⟩  ::=  0
# Not part of the enclosure 
  1
# Enclosure is valid 

  3
# More than 1 medium 

  5
# Triangles with undef medium 

  7
# More than 1 medium including undef 
List the media that the triangle surrounds for each enclosure and report media description problems:
⟨enclosuresmedia⟩  ::=  Enclosures_internal_media
⟨#enclosures⟩ \ 
⟨#triangles⟩
unsigned_char 

⟨enclmedia⟩ ... # Up to ⟨#enclosures⟩  
... # Up to ⟨#triangles⟩  
⟨enclmedia⟩  ::=  ⟨mediumid⟩ # Medium of the enclosure 
  INT_MAX # Not part of the enclosure  
  INT_MAX1
# Error: in the enclosure 

  INT_MAX2
# Error: medium missing 
Report problems of triangle overlap:
⟨overlappings⟩  ::=  SCALARS
Overlapping_triangles \ 
unsigned_int 1  
LOOKUP_TABLE
default 

⟨overlappingstatus⟩  
... # Up to ⟨#triangles⟩  
⟨overlappingstatus⟩  ::=  0
# Doesn't overlap another triangle 
  1
# Error: overlaps another triangle 
⟨#enclosures⟩  ::=  integer 
INFRARED IMAGE
When invoked with option R
,
stardis(1) calculates an
infrared image of the system and write it to standard output. Depending on
the fmt
suboption, this file can be either in
htrdrimage(5) format or
in VTK format.
⟨infraredimage⟩  ::=  ⟨infraredimageht⟩ # Option
R fmt=HT 
  ⟨infraredimagevtk⟩ # Option
R fmt=VTK 
htrdrimage format
The htrdrimage(5) layout of an infrared image is as follows:
⟨infraredimageht⟩  ::=  ⟨definition⟩ 
⟨pixel⟩  
... # Up to number of pixels  
⟨definition⟩  ::=  ⟨width⟩ ⟨height⟩ 
⟨width⟩  ::=  integer 
⟨height⟩  ::=  integer 
⟨pixel⟩  ::=  ⟨temperature⟩ 0 0 0
0 ⟨time⟩ 
⟨temperature⟩  ::=  ⟨estimate⟩ 
⟨time⟩  ::=  ⟨estimate⟩ # Time per realisation 
⟨estimate⟩  ::=  ⟨expectedvalue⟩ ⟨standarderror⟩ 
⟨expectedvalue⟩  ::=  real 
⟨standarderror⟩  ::=  real 
See htpp(1) to convert images in htrdrimage(5) format into a regular image.
VTK format
An infrared VTK image is an XY plane. By convention, the origin (0,0) pixel is at the topleft corner of the image. The result not only includes the computed temperature image, but also includes a perpixel computation time image as well as a perpixel path error count image and perpixel standard deviation images for both temperature and computation time.
The VTK layout of an infrared image is as follows:
⟨infraredimagevtk⟩  ::=  # vtk DataFile Version
2.0 
⟨description⟩  
DATASET
STRUCTURED_POINTS 

DIMENSIONS
⟨width⟩
⟨height⟩
1 

ORIGIN 0 0
0 

SPACING 1 1
1 

POINT_DATA
⟨#pixels⟩ 

⟨temp⟩  
⟨tempstderr⟩  
⟨time⟩  
⟨timestderr⟩  
⟨failurescount⟩  
⟨temp⟩  ::=  SCALARS
temperature_estimate float 1 
LOOKUP_TABLE
default 

real  
... # Up to ⟨#pixels⟩  
⟨tempstderr⟩  ::=  SCALARS
temperature_std_dev float 1 
LOOKUP_TABLE
default 

real  
... # Up to ⟨#pixels⟩  
⟨time⟩  ::=  SCALARS
computation_time float 1 
LOOKUP_TABLE
default 

real  
... # Up to ⟨#pixels⟩  
⟨timestderr⟩  ::=  SCALARS
computation_time_std_dev float 1 
LOOKUP_TABLE
default 

real  
... # Up to ⟨#pixels⟩  
⟨failurescount⟩  ::=  SCALARS
failures_count \ 
unsigned_long_long
1 

LOOKUP_TABLE
default 

integer  
... # Up to ⟨#pixels⟩  
⟨#pixels⟩  ::=  integer # = ⟨width⟩ * ⟨height⟩ 
⟨width⟩  ::=  integer 
⟨height⟩  ::=  integer 
⟨description⟩  ::=  string # Up to 256 characters 
HEAT PATHS
When the
stardis(1) option
D
is used in conjunction with an option that
computes a result, some of the heat paths (successful paths, erroneous
paths, or both) sampled during the simulation are written to files. Each
path is written in VTK format, one VTK file per path. The path description
can include vertices' time if it makes sense, that is if the computation
time is not
INF.
Due to the branching nature of nonlinear Monte Carlo algorithms,
paths are made of strips. With a Picard order of 1 (option
o
1), there is only a single
strip. With higher orders, the number of strips can be greater than 1. As a
result, the whole path is a tree: past the first strip, each strip can start
from any vertex of one of the previous strips. This tree, when displaying
the Branch_id
field, starts with id 0, then
increments each time a nonlinearity leads to the creation of a new strip
(to fetch a temperature).
The VTK layout of a path is as follows:
⟨heatpath⟩  ::=  # vtk DataFile Version
2.0 
⟨description⟩  
ASCII 

DATASET
POLYDATA 

⟨vertices⟩  
⟨strips⟩  
CELL_DATA
⟨#strips⟩ 

⟨status⟩  
POINT_DATA
⟨#vertices⟩ 

⟨segmenttypes⟩  
⟨weights⟩  
⟨branchids⟩  
[⟨verticestime⟩] # If not steady  
⟨description⟩  ::=  string # Up to 256 characters 
⟨#vertices⟩  ::=  integer 
⟨#strips⟩  ::=  integer 
List the vertices of the main trajectory and its branches:
⟨vertices⟩  ::=  POINTS
⟨#vertices⟩
double 
⟨x⟩ ⟨y⟩ ⟨z⟩  
... # Up to ⟨#vertices⟩  
⟨x⟩  ::=  real 
⟨y⟩  ::=  real 
⟨z⟩  ::=  real 
List the main trajectory and branches of the path:
⟨strips⟩  ::=  LINES
⟨#strips⟩
⟨striplistsize⟩ 
⟨#stripvertices⟩ ⟨vertexid⟩ ...  
... # Up to ⟨#strips⟩  
⟨striplistsize⟩  ::=  integer # vertices per strip + ⟨#strips⟩ 
⟨vertexid⟩  ::=  integer # In [0, ⟨#vertices⟩[ 
Status of the path:
⟨status⟩  ::=  SCALARS
Path_Failure unsigned_char 1 
0 
1
# 0: Success; 1: Failure 

... # Up to ⟨#strips⟩ 
List the type of heat transfert to which each path vertex belongs:
⟨segmenttypes⟩  ::=  SCALARS
Segment_Type unsigned_char 1 
LOOKUP_TABLE
default 

⟨segmenttype⟩  
... # Up to ⟨#vertices⟩  
⟨segmenttype⟩  ::=  0
# Conduction 
  1
# Convection 

  2
# Radiative 
Monte Carlo weight along the path:
⟨weights⟩  ::=  SCALARS Weight
double 1 
LOOKUP_TABLE
default 

real  
... # Up to ⟨#vertices⟩ 
List the identifier of the main path and its branches with respect to the branch depth:
⟨branchids⟩  ::=  SCALARS
Branch_id int 1 
LOOKUP_TABLE
default 

integer # In [0, Picard_order[  
... # Up to ⟨#vertices⟩ 
Rewinded time along the path:
⟨verticestime⟩  ::=  SCALARS Time
double 1 
LOOKUP_TABLE
default 

real # Time [s]  
... # Up to ⟨#vertices⟩ 
SEE ALSO
STANDARDS
The VTK User's Guide, Kitware, Inc, 11, 470482, 2010, Simple Legacy Formats.
April 12, 2024  UNIX 