... | ... | @@ -18,6 +18,101 @@ |
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
|
----
|
|
|
|
|
|
[code-patterns]: /coding/patterns/patterns
|
|
|
[upgrade-guide]: /upgrade/upgrade
|
... | ... | |