GitLab

Preview information, subject to change at any time !!!

• Deprecation and Removal
  • Deprecated Models
• Rename
• Configuration / Environment
• Input Dictionaries
  • Parsing of scalars/labels
  • Eval
• Output Headers
• Post-processing

Deprecation and Removal

Deprecated Models

Rename

Configuration / Environment

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 and data.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.

---