- this adds support for various STL operations including
* sorting, filling, find min/max element etc.
* for-range iteration
STYLE: use constexpr for VectorSpace rank
- having whitespace in fileName can be somewhat fragile since it means
that the fileName components do not necessarily correspond to a
'Foam::word'. But in many cases it will work provided that spaces
are not present in the final portion of the simulation directory
itself.
InfoSwitches
{
// Allow space character in fileName (use with caution)
allowSpaceInFileName 0;
}
- now use doClean=true as default for fileName::validate(). Was false.
Unlike fileName::clean() this requires no internal string rewrite
since the characters are being copied. Also handle any path
separator transformations (ie, backslash => forward slash) at the
same time. This makes it resemble the std::filesystem a bit more.
- operators are still incomplete, as are dimensioned fields,
field-fields etc.
- split complexFields into separate complexField, complexVectorField files
- add construction from and conversion to std::complex, which allows
easier wrapping of functions
- add Foam:: functions for complex versions of sin, cos, ...
- was historically defined as (1 1), but it is more consistent with
the concept of one to have a real component only.
Now defined as (1 0): 1+0i
STYLE: remove obscure '!' operator for complex conjugate
- either use the member function or the '~' operator
- These are not defined in the C++ standard for cmath, so allow for
compilation without them. Will need to provide replacements in the
future or rework.
- new regExpCxx wrapper for C++11 regex support with drop-in
compatibility with existing code.
- regExpPosix (was regExp), for future phase out in favour of regExpCxx.
- The regExp header will continue to be used for defining an
appropriate typedef corresponding to the preferred implementation.
- PtrDynList support for move append list:
can be used to concatenate pointer lists into a single one
- include resize in PtrDynList squeezeNull as being a natural
combination
- support sorting operations for pointer lists (PtrListOps)
- remove writeGeometry() in favour of write() and make it pure virtual
so that all writers must explicitly deal with it.
- establish proxy extension at construction time and treated as an
invariant thereafter. This avoids potentially surprising changes in
behaviour when writing.
- this is a simple container for fields with i-j-k addressing.
It does not support field operations directly, but is primarily
intended to be used when assembling field information with i-j-k
logic. After assembly, the field can be transferred to a regular
field for normal operations. Eg,
IjkField<scalar> assemble({15, 16, 200});
// .. fill in i-j-k fields
Field<scalar> final(std::move(assemble));
assemble.clear(); // be pedantic
...
- While a rectilinear mesh can be created with blockMesh, not every mesh
created with blockMesh will satisfy the requirements for being a
rectilinear mesh.
This alternative to blockMesh uses a single block that is aligned
with the xy-z directions and specifications of the control points,
mesh divisions and expansion ratios. For example,
x
{
points ( -13.28 -0.10 6.0 19.19 );
nCells ( 10 12 10 );
ratios ( 0.2 1 5 );
}
y { ... }
z { ... }
With only one block, the boundary patch definition is simple and the
canonical face number is used directly. For example,
inlet
{
type patch;
faces ( 0 );
}
outlet
{
type patch;
faces ( 1 );
}
sides
{
type patch;
faces ( 2 3 );
}
...
- After a mesh is defined, it is trivial to retrieve mesh-related
information such as cell-volume, cell-centres for any i-j-k location
without an actual polyMesh.
STYLE: remove -noFunctionObjects from blockMesh
- no time loop, so function objects cannot be triggered anyhow.
- PtrList::release() method.
Similar to autoPtr and unique_ptr and clearer in purpose than
using set(i,nullptr)
- Construct from List of pointers, taking ownership.
Useful when upgrading code. Eg,
List<polyPatch*> oldList = ...;
PtrList<polyPatch> newList(oldList);
...
BUG: incorrect resizing method names (PtrDynList) in previously unused code
- The writers have changed from being a generic state-less set of
routines to more properly conforming to the normal notion of a writer.
These changes allow us to combine output fields (eg, in a single
VTK/vtp file for each timestep).
Parallel data reduction and any associated bookkeeping is now part
of the surface writers.
This improves their re-usability and avoids unnecessary
and premature data reduction at the sampling stage.
It is now possible to have different output formats on a per-surface
basis.
- A new feature of the surface sampling is the ability to "store" the
sampled surfaces and fields onto a registry for reuse by other
function objects.
Additionally, the "store" can be triggered at the execution phase
as well
- previously just removed duplicate literals, but now remove any
duplicates.
- Replace previous wordHashSet implementation with a linear search
instead. The lists are normally fairly small and mostly just have
unique entries anyhow. This reduces the overall overhead.
- can now safely use labelList::null() instead of emptyLabelList for
return values. No special treatment required for lists.
Possible replacements:
if (notNull(list) && list.size()) -> if (list.size())
if (isNull(list) || list.empty()) -> if (list.empty())
The receiver may still wish to handle differently to distinguish
between a null list and an empty list, but no additional special
protection is required when obtaining sizes, traversing, outputting
etc.
- previously had a single pointer/value zeros (8 bytes), this meant
that the reinterpret cast to a List would yield a reference that
could be unsafe under certain conditions.
Eg,
const labelList& myList = labelList::null();
Info<< myList.size() << nl; // OK since size is the first parameter
SubList<label>(myList, 0); // Unsafe
The SubList usage is unsafe since it passes in pointer and size into
the underlying UList. However, the pointer from the labelList::null()
will be whatever happens to be around in memory immediately after the
NullObject singleton. This is mostly not a problem if the List size
is always checked, but does mean that the data pointer is rather
dubious.
- Increase the size of the nullObject singleton to 32 bytes of zeros
to ensure that most reinterpret casting will not result in objects
that reference arbitrary memory.
The 32-byte data size is rather arbitrary, but covers most basic
containers.
