- 'unfriend' operators on dimensionSet, since they operate without
requiring access to non-public members.
- add missing invTransform() function for dimensionSet.
- make inv(const dimensionSet&) available as
operator~(const dimensionSet&), which can be used instead
of (dimless/ds).
- writing of dictionary entry with the name of the dimensionedType
suppressed if it is identical to the keyword.
This corresponds to the input requirements.
- deprecate dimensionedType constructors using an Istream in favour of
versions accepting a keyword and a dictionary.
Dictionary entries are almost the exclusive means of read
constructing a dimensionedType. By construct from the dictionary
entry instead of doing a lookup() first, we can detect possible
input errors such as too many tokens as a result of a input syntax
error.
Constructing a dimensionedType from a dictionary entry now has
two forms.
1. dimensionedType(key, dims, dict);
This is the constructor that will normally be used.
It accepts entries with optional leading names and/or
dimensions. If the entry contains dimensions, they are
verified against the expected dimensions and an IOError is
raised if they do not correspond. On conclusion, checks the
token stream for any trailing rubbish.
2. dimensionedType(key, dict);
This constructor is used less frequently.
Similar to the previous description, except that it is initially
dimensionless. If entry contains dimensions, they are used
without further verification. The constructor also includes a
token stream check.
This constructor is useful when the dimensions are entirely
defined from the dictionary input, but also when handling
transition code where the input dimensions are not obvious from
the source.
This constructor can also be handy when obtaining values from
a dictionary without needing to worry about the input dimensions.
For example,
Info<< "rho: " << dimensionedScalar("rho", dict).value() << nl;
This will accept a large range of inputs without hassle.
ENH: consistent handling of dimensionedType for inputs (#1083)
BUG: incorrect Omega dimensions (fixes#2084)
- use forwarding templates for the factory method
- avoid double use of dynamic_cast.
Don't need implicit use in isA<>, can use result directly
STYLE: updated iteration over HashTable of mesh objects
- was using coordinate-system and transform() which is the
local-to-global mapping, whereas it should be invTransform() which
is the global-to-local mapping
- this seems to be the only reliable means of obtaining the values.
Using typeName_() yields the wrong value.
Using the typeName causes initialization issues
(segfault when executing on some systems).
- support name filtering by class based on <Type> or predicates.
Eg,
objects.sortedNames<volScalarField>(namePattern);
vs objects.sortedNames(volScalarField::typeName, namePattern);
These can also be used directly for untyped name matching.
Eg,
objects.sortedNames<void>(namePattern);
Can also use a predicate:
objects.sortedNames(wordRe("vol.*Field"), namePattern);
objects.sortedNames
(
[](const word& clsName){ return clsName.startsWith("vol"); },
namePattern
);
- add IOobjectList::count() methods
- lookupClass<Type>() to use types instead of class variables.
- additional helpers for parallel: allNames(), checkNames()
- provide filterClasses() and filterObjects(), prune_0() method
forwarding to HashTable methods for easier access.
- in parameter form, check if it headerClassName() corresponds to the
specified class name
- in templated form, check if headerClassName() corresponds to the
Type:typeName value.
Specialization for <void> always returns true (ie, no checks)
- replace explicit use of word, wordRe, wordRes, wordHashSet as filters
with a MatchPredicate, since they all satisfy the requirements for
use a predicate. This change reduces code duplication, allows other
matcher types (eg, keyType) as well as lambda functions.
- add special treatment for a 'const char*' parameter
for lookupClass() and the now-deprecated single item lookup() method
to promote these parameters to 'word'.
- naming similar to objectRegistry, with unambiguous resolution.
The lookup() methods have different return types depending on the
calling parameter.
STYLE: use IOobjectListTemplates.C for implementations
- previously included as local definition within IOobjectList.C,
but will be adding more templated methods soon.
- adjust parameters (eg, matchName instead of matcher) to show their
function
ENH: handle objectRegistry::names<void>(...)
- this is equivalent to no Type restriction, and can be used when
filtering names. Eg,
obr.names<void>(wordRe..);
- Start brief descriptions with 'Deprecated(YYYY-MM)' so that it is
readily visible in the short method description. Consistent date
format (YYYY-MM), placed immediately after the \deprecated tag.
commit 3f9c7bf411
commit 3cf177e759
====
ENH: add geometric decomposition constraint (issue #921)
- geometric decomposition constraints may be used to prevent the
decomposition of regions of the mesh.
The geometric constraint is applied according to the face centres,
which define the connectivity between cells.
Specified in decomposeParDict
constraints
{
geometric
{
type geometric;
geometry
{
box1
{
type box;
min (-10 -10 -10);
max (1 1 1);
}
ball1
{
type sphere;
origin (-2 -2 1);
radius 1;
}
}
}
}
ENH: add 'grow' option for geometric decomposition constraint (issue #921)
- the 'grow' option includes an additional check to include cell faces
for any cell that already has two or more of its faces "unblocked".
This could indicate a connection over a corner, but does not distinguish
between connectivity introduced by the constraint and the connectivity
defined by other constraints.
ENH: geometric decomposition constraint using topoSetFaceSource (issue #921)
- replaced use of searchableSurface with a more general and
more efficient topoSetFaceSource instead.
Since searchableSurface is also available as a topoSetFaceSource,
there is no loss in functionality, but using topoSetFaceSource allow
directly looping over the faces without creating of an additional
List of volumeTypes.
This fixes the static-initialisation order problem - fieldTypes.C
referes to labelIOField etc. which are after it in Make/files and
hence the link order.
