Preview information, subject to change at any time !!!
Input Dictionaries
Parsing of scalars/labels
The dictionary reading of scalars and labels (ie, floating and fixed point values) has been relaxed to handle slightly sloppier input.
Consider the following dictionary input:
valueA 2;
valueB - 2;
When getting values from the dictionary:
Info<< "val = " << dict.get<scalar>("valueB") << nl;
This would usually fail, since the entry has two separate tokens.
The reading routines have been adjusted to accept this as valid
(but ugly) input for scalars and labels.
If the first token is -
, it is used to negate the next token, which
must be a valid numerical token.
This modification provides an immediate benefit when using input dictionaries with variable expansion. The original example can now be rewritten with variables and can still be properly read:
valueA 2;
valueB -$valueA;
Since these changes to the reading occur at a low-level, they
automatically apply to composite types such as vector
as well.
Here is a simple example with a bounding box definition:
dim 100;
min (-$dim -$dim -$dim);
max ( $dim $dim $dim);
To achieve the same result in previous versions is considerably less user-friendly:
dim 100;
min #eval{ vector (-$dim, -$dim, -$dim) };
max ( $dim $dim $dim);
Eval
-
The syntactical sugar for the
#eval
dictionary directive is robuster. For example,value1 #eval{ round (${variable} / 20) };
Will now parse correctly through to the final '}' instead of simply stopping at the first right-brace. The brace and brackets within the expression still need to be balanced.
-
generously ignore trailing ';' in expressions. This is a frequent user error.
-
support a field width for
#eval
expressions. For example,entry #eval 10 { vector(rand(), 0, 0) };
Output Headers
As described in the release notes:
- The
arch
information is always output, even for ASCII format - An additional header
meta
information is available. - Collated formats have additional
data.class
anddata.format
entries
Post-processing
The output location of static ensight geometry has changed. The
"geometry" was previously placed under directly in the EnSight case
directory, but is now relocated to a constant
data directory.
For example,
ensight/ensight.case
ensight/data/constant/geometry
ensight/data/000001
ensight/data/000002 ...
Improves handling and avoids potential collisions when adding in additional mesh regions.