- Cleanup/centralize handling of -decomposeParDict by relocating
common code into argList. Ensures that all processes receive
identical information about the -decomposeParDict opton.
- Only use alternative decomposeParDict for simpleFoam/motorBike
tutorial so that this will be included in the test loop for snappy.
- Added Mattijs' fix for surfaceRedistributePar.
changed flag which caused infinite while loop. Background info:
- findCellZoneTopo tries to find for all named surface intersections
which side of the face is in the faceZone
- i.e. it tries to make the cellZone consistent with the faceZone
(to fix small problems)
- this had some logic to assign the neighbour cellZone to the owner cellZone
- which didn't check for the neighbour being the same value as the owner
- but still set a 'changed' flag which caused the loop to never end.
All of the access methods for autoPtr include validity checks and will
fail if the underlying point is NULL. In some cases, however, we'd
like to retain the automatic deletion mechanism, but still address a
nullptr. This is mostly for cases in which a file-stream should be
allocated, but only on the master process. For these cases we'd still
like to pass through and reference the underlying pointer (eg, to
obtain the correct method call) without tripping the pointer check
mechanism. If we attempt to use the ptr() method, the autoPtr memory
management is bypassed and we risk memory leaks.
Instead provide an alternative mechanism to obtain the raw underlying
pointers/references. Use rawPtr() and rawRef() for these potentially
useful, but also potentially dangerous, operations.
- Normally use '()' to deference. This has extra safety and issues a
fatal error if the underlying pointer is not valid.
However, in some cases we are happy with getting a null reference.
The refOrNull() method returns the reference without any checking.
Usage example:
autoPtr<OFstream> osPtr;
if (Pstream::master())
{
osPtr.reset(new OFstream(...));
}
writeViaMaster(osPtr.refOrNull());
- The writeViaMaster() call takes an OFstream reference,
but this is only used directly on the master.
The slaves will pass things through to the master.
- bugfix (empty patches), and added detection of steady-state
scheme.
Caveat: when called via execFlowFunctionObjects will always produce a
zero field, since the oldTime field is not available for this mode.
Extrapolate internal field to walls for post-processing.
Uses as new syntax for handling the naming of multiple fields.
The input fields are selected via a wordReList.
For example,
fields (U "(T|k|epsilon|omega)");
The names of the resulting output fields use placeholder tokens for
flexibility. For example,
result zeroGradient(@@);
The '@@' placeholder is replaced by the name of the input field.
Eg,
fields (U T);
result zeroGradient(@@);
-> zeroGradient(U), zeroGradient(T)
Or,
fields (U T);
result @@nearWall;
-> UnearWall, TnearWall
NOTE:
The function object will skip over fields that only have
processor, empty, zeroGradient patches. The operation does not
make much sense for these, and it avoids inadvertently
re-processing fields twice.
- implemented using magSqr() instead of sqr().
For scalar fields they are the same, but can be useful
if this function object is extended for more field types.
This was going wrong in a fair few cases where you would get regions which
were delimited by a combination of intersections with unnamed surfaces (wall)
and named surfaces (faceZone surface) but not with either of these sets
individually. This would cause there to be unvisited cells (zone = -2)
next to a visited cells but separated by a named surface only (and not an
unnamed surface). Fixed by using direct surface intersection in the removal
part. Related to #66.
- previously just detected the presence of "processor" in the case
path name. Restrict to checking the final portion.
Does not solve all problems, but solves ones like this:
test-new-processor-generation/....
- The only reasonable means of mirroring the data layout.
The '{}' delimiters mark the extent of the binary writes.
The primitives 'label' and 'scalar' are directly supported and correspond
to known byte widths.
Using "List<scalar>" was a bad choice, since this triggers unpleasant
tokenizing behaviour. Instead use 'scalars' as a provisional placeholder
to indicates a list of scalar values. However, there is currently no
support for actually handling lists of scalars, for several reasons:
* The information is not available at compile-time.
The cloud or parcel must be queried. And it must be guaranteed
that this value is consistent for the entire cloud.
* Binary output of lists is currently not great for determining the
the encoded width:
- A zero-size list is a single '0'.
- The leading size is a non-constant number of digits.
- There are prefix/suffix newlines need to be tagged and
skipped.
The special '*' (glob) token indicates that the remaining content
has a dynamic variable length and nothing reasonable can be known
about their sizes. This is exemplified by the collision records.
