- The logic for switching input-mode was previously completely
encapsulated within the #inputMode directive, but without any
programming equivalent. Furthermore, the encapsulation in inputMode
made the logic less clear in other places.
Exposing the inputMode as an enum with direct access from entry
simplifies things a fair bit.
- eliminate one level of else/if nesting in entryIO.C for clearer logic
- for dictionary function entries, simply use
addNamedToMemberFunctionSelectionTable() and avoid defining a type()
as a static. For most function entries the information is only used
to get a name for the selection table lookup anyhow.
- consolidate word::validated() into word::validate() and also allow
as short form for string::validate<word>(). Also less confusing than
having similarly named methods that essentially do the same thing.
- more consistent const access when iterating over strings
- add valid(char) for keyType and wordRe
- error::throwExceptions(bool) returning the previous state makes it
easier to set and restore states.
- throwing() method to query the current handling (if required).
- the normal error::throwExceptions() and error::dontThrowExceptions()
also return the previous state, to make it easier to restore later.
- resets the output buffer completely - implementing what rewind was
likely meant to have accomplished for many use cases.
STYLE: OSHA1stream reset() for symmetry. Deprecate rewind().
- use allocator class to wrap the stream pointers instead of passing
them into ISstream, OSstream and using a dynamic cast to delete
then. This is especially important if we will have a bidirectional
stream (can't delete twice!).
STYLE:
- file stream constructors with std::string (C++11)
- for rewind, explicit about in|out direction. This is not currently
important, but avoids surprises with any future bidirectional access.
- combined string streams in StringStream.H header.
Similar to <sstream> include that has both input and output string
streams.
- This provides a mechanism for moving mesh patches based on external
input (eg, from an external structures solver). The patch points are
influenced by the position and rotation of the lumped points.
BC: lumpedPointDisplacementPointPatchVectorField
Controlling mechanisms:
- externalCoupler
for coordinating the master/slave
- lumpedPointMovement
manages the patch-points motion, but also for extracting forces/moments
- lumpedPointState
represents the positions/rotations of the controlling points
Utils:
- lumpedPointZones
diagnostic for visualizing the correspondence between controlling
points and patch faces
- lumpedPointMovement
Test that the patch motion is as desired without invoking moveMesh.
With the -slave option, return items from a precalculated table
for the lumpedPointDisplacementPointPatchVectorField BC.
Adds overset discretisation to selected physics:
- diffusion : overLaplacianDyMFoam
- incompressible steady : overSimpleFoam
- incompressible transient : overPimpleDyMFoam
- compressible transient: overRhoPimpleDyMFoam
- two-phase VOF: overInterDyMFoam
The overset method chosen is a parallel, fully implicit implementation
whereby the interpolation (from donor to acceptor) is inserted as an
adapted discretisation on the donor cells, such that the resulting matrix
can be solved using the standard linear solvers.
Above solvers come with a set of tutorials, showing how to create and set-up
simple simulations from scratch.
- the heuristic for matching unresolved intersections is a relatively
simple matching scheme that seems to be more robust than attempting to walk
the geometry or the cuts.
- avoid false positives for self intersection
- adjust for updates in 'develop'
- change surfaceIntersection constructor to take a dictionary of
options.
tolerance | Edge-length tolerance | scalar | 1e-3
allowEdgeHits | Edge-end cuts another edge | bool | true
avoidDuplicates | Reduce the number of duplicate points | bool | true
warnDegenerate | Number of warnings about degenerate edges | label | 0
- the NamedEnum wrapper is somewhate too rigid.
* All enumerated values are contiguous, starting as zero.
* The implicit one-to-one mapping precludes using it for aliases.
* For example, perhaps we want to support alternative lookup names for an
enumeration, or manage an enumeration lookup for a sub-range.
- Remove the unused enums() method since it delivers wholly unreliable
results. It is not guaranteed to cover the full enumeration range,
but only the listed names.
- Remove the unused strings() method.
Duplicated functionality of the words(), but was never used.
- Change access of words() method from static to object.
Better code isolation. Permits the constructor to take over
as the single point of failure for bad input.
- Add values() method
- do not expose internal (HashTable) lookup since it makes it more
difficult to enforce constness and the implementation detail should
not be exposed. However leave toc() and sortedToc() for the interface.
STYLE: relocated NamedEnum under primitives (was containers)
- internal typedef as 'value_type' for some consistency with STL conventions
- The unset() method never auto-vivifies, whereas the set() method
always auto-vivifies. In the case where set() is called with a zero
for its argument - eg, set(index, 0) - this should behave
identically to an unset() and not auto-vivify out-of-range entries.
- provides a summary hash of classes used and their associated object names.
The HashTable representation allows us to leverage various HashTable
methods. This hashed summary view can be useful when querying
particular aspects, but is most useful when reducing the objects in
consideration to a particular subset. For example,
const wordHashSet interestingTypes
{
volScalarField::typeName,
volVectorField::typeName
};
IOobjectList objects(runTime, runTime.timeName());
HashTable<wordHashSet> classes = objects.classes();
classes.retain(interestingTypes);
// Or do just the opposite:
classes.erase(unsupportedTypes);
Can also use the underlying HashTable filter methods
STYLE: use templated internals to avoid findString() when matching subsets
- Generalized means over filtering table entries based on their keys,
values, or both. Either filter (retain), or optionally prune elements
that satisfy the specified predicate.
filterKeys and filterValues:
- Take a unary predicate with the signature
bool operator()(const Key& k);
- filterEntries:
Takes a binary predicate with the signature
bool operator()(const Key& k, const T& v);
==
The predicates can be normal class methods, or provide on-the-fly
using a C++ lambda. For example,
wordRes goodFields = ...;
allFieldNames.filterKeys
(
[&goodFields](const word& k){ return goodFields.match(k); }
);
Note that all classes that can match a string (eg, regExp, keyType,
wordRe, wordRes) or that are derived from a Foam::string (eg, fileName,
word) are provided with a corresponding
bool operator()(const std::string&)
that either performs a regular expression or a literal match.
This allows such objects to be used directly as a unary predicate
when filtering any string hash keys.
Note that HashSet and hashedWordList both have the proper
operator() methods that also allow them to be used as a unary
predicate.
- Similar predicate selection with the following:
* tocKeys, tocValues, tocEntries
* countKeys, countValues, countEntries
except that instead of pruning, there is a simple logic inversion.
- predicates::always and predicates::never returning true and false,
respectively. These simple classes make it easier when writing
templated code.
As well as unary and binary predicate forms, they also contain a
match(std::string) method for compatibility with regex-based classes.
STYLE: write bool and direction as primitive 'int' not as 'label'.
- ensure that the string-related classes have consistently similar
matching methods. Use operator()(const std::string) as an entry
point for the match() method, which makes it easier to use for
filters and predicates. In some cases this will also permit using
a HashSet as a match predicate.
regExp
====
- the set method now returns a bool to signal that the requested
pattern was compiled.
wordRe
====
- have separate constructors with the compilation option (was previously
a default parameter). This leaves the single parameter constructor
explicit, but the two parameter version is now non-explicit, which
makes it easier to use when building lists.
- renamed compile-option from REGEX (to REGEXP) for consistency with
with the <regex.h>, <regex> header names etc.
wordRes
====
- renamed from wordReListMatcher -> wordRes. For reduced typing and
since it behaves as an entity only slightly related to its underlying
list nature.
- Provide old name as typedef and include for code transition.
- pass through some list methods into wordRes
hashedWordList
====
- hashedWordList[const word& name] now returns a -1 if the name is is
not found in the list of indices. That has been a pending change
ever since hashedWordList was generalized out of speciesTable
(Oct-2010).
- add operator()(const word& name) for easy use as a predicate
STYLE: adjust parameter names in stringListOps
- reflect if the parameter is being used as a primary matcher, or the
matcher will be derived from the parameter.
For example,
(const char* re), which first creates a regExp
versus (const regExp& matcher) which is used directly.
- inherit from std::iterator to obtain the full STL typedefs, meaning
that std::distance works and the following is now possible:
labelRange range(100, 1500);
scalarList list(range.begin(), range.end());
--
Note that this does not work (mismatched data-types):
scalarList list = identity(12345);
But this does, since the *iter promotes label to scalar:
labelList ident = identity(12345);
scalarList list(ident.begin(), ident.end());
It is however more than slightly wasteful to create a labelList
just for initializing a scalarList. An alternative could be a
a labelRange for the same purpose.
labelRange ident = labelRange::identity(12345);
scalarList list(ident.begin(), ident.end());
Or this
scalarList list
(
labelRange::null.begin(),
labelRange::identity(12345).end()
);
- provides const/non-const access to the underlying list, but the
iterator access itself is const.
- provide linked-list iterator 'found()' method for symmetry with
hash-table iterators. Use nullptr for more clarity.
- lookup(): with a default value (const access)
For example,
Map<label> something;
value = something.lookup(key, -1);
being equivalent to the following:
Map<label> something;
value = -1; // bad value
if (something.found(key))
{
value = something[key];
}
except that lookup also makes it convenient to handle const references.
Eg,
const labelList& ids = someHash.lookup(key, labelList());
- For consistency, provide a two parameter HashTable '()' operator.
The lookup() method is, however, normally preferable when
const-only access is to be ensured.
- retain(): the counterpart to erase(), it only retains entries
corresponding to the listed keys.
For example,
HashTable<someType> largeCache;
wordHashSet preserve = ...;
largeCache.retain(preserve);
being roughly equivalent to the following two-stage process,
but with reduced overhead and typing, and fewer potential mistakes.
HashTable<someType> largeCache;
wordHashSet preserve = ...;
{
wordHashSet cull(largeCache.toc()); // all keys
cull.erase(preserve); // except those to preserve
largeCache.erase(cull); //
}
The HashSet &= operator and retain() are functionally equivalent,
but retain() also works with dissimilar value types.
- provide key_iterator/const_key_iterator for all hashes,
reuse directly for HashSet as iterator/const_iterator, respectively.
- additional keys() method for HashTable that returns a wrapped to
a pair of begin/end const_iterators with additional size/empty
information that allows these to be used directly by anything else
expecting things with begin/end/size. Unfortunately does not yet
work with std::distance().
Example,
for (auto& k : labelHashTable.keys())
{
...
}
- previously had a mismash of const/non-const attributes on iterators
that were confused with the attributes of the object being accessed.
- use the iterator keys() and object() methods consistently for all
internal access of the HashTable iterators. This makes the intention
clearer, the code easier to maintain, and protects against any
possible changes in the definition of the operators.
- 'operator*': The standard form expected by STL libraries.
However, for the std::map, this dereferences to a <key,value> pair,
whereas OpenFOAM dereferences simply to <value>.
- 'operator()': OpenFOAM treats this like the 'operator*'
- adjusted the values of end() and cend() to reinterpret from nullObject
instead of returning a static iteratorEnd() object.
This means that C++ templates can now correctly deduce and match
the return types from begin() and end() consistently.
So that range-based now works.
Eg,
HashTable<label> table1 = ...;
for (auto i : table1)
{
Info<< i << endl;
}
Since the 'operator*' returns hash table values, this prints all the
values in the table.
