- avoid any operations for zero sources
- explicit sources are applied to the entire mesh can be added directly,
without an intermediate DimensionedField
- update some legacy faMatrix/fvMatrix methods that used Istream
instead of dictionary or dimensionSet for their parameters.
Simplify handling of tmps.
- align faMatrix methods with the updated their fvMatrix counterparts
(eg, DimensionedField instead of GeometricField for sources)
- similar to the geometric decomposition constraint,
allows a compositing selection of cells based on topoSet sources
which also include various searchableSurface mechanisms.
This makes for potentially easier placement of sources without
resorting to defining a cellSet.
ENH: support zone group selection for fv::cellSetOption and fa::faceSetOption
- select motion for the entire mesh, or restrict to a subset
of points based on a specified cellSet or cellZone(s).
Can now combine cellSet and cellZone specifications
(uses an 'or' combination).
- move consistent use of keyType and wordRe to allow regex selection,
possibly using zone groups
STYLE: remove duplicate code in solidBodyMotionSolver
- shorter lookup names for more consistency
ENH: accept point1/point2 as alternative to p1/p2 for sources
- better alignment with searchable specification
- refactor so that cylinderAnnulus sources derive directly from
cylinder sources (which handle an annulus as well).
Accept radius or outerRadius as synonyms.
STYLE: noexcept on topoBitSet access methods
DOC: update description for geometricConstraint
- in various situations with mesh regions it is also useful to
filter out or remove the defaultRegion name (ie, "region0").
Can now do that conveniently from the polyMesh itself or as a static
function. Simply use this
const word& regionDir = polyMesh::regionName(regionName);
OR mesh.regionName()
instead of
const word& regionDir =
(
regionName != polyMesh::defaultRegion
? regionName
: word::null
);
Additionally, since the string '/' join operator filters out empty
strings, the following will work correctly:
(polyMesh::regionName(regionName)/polyMesh::meshSubDir)
(mesh.regionName()/polyMesh::meshSubDir)
Reports cloud information for particles passing through a specified cell
zone.
Example usage:
cloudFunctions
{
particleZoneInfo1
{
type particleZoneInfo;
cellZone leftFluid;
// Optional entries
//writer vtk;
}
}
Results are written to file:
- \<case\>/postProcessing/lagrangian/\<cloudName\>/\<functionName\>/\<time\>
\# cellZone : leftFluid
\# time : 1.0000000000e+00
\#
\# origID origProc (x y z) time0 age d0 d mass0 mass
Where
- origID : particle ID
- origProc : processor ID
- (x y z) : Cartesian co-ordinates
- time0 : time particle enters the cellZone
- age : time spent in the cellZone
- d0 : diameter on entry to the cellZone
- d : current diameter
- mass0 : mass on entry to the cellZone
- mass : current mass
If the optional \c writer entry is supplied, cloud data is written in the
specified format.
During the run, output statistics are reported after the cloud solution,
e.g.:
particleZoneInfo:
Cell zone = leftFluid
Contributions = 257
Here, 'Contributions' refers to the number of incremental particle-move
contributions recorded during this time step. At write times, the output
is extended, e.g.:
particleZoneInfo:
Cell zone = leftFluid
Contributions = 822
Number of particles = 199
Written data to "postProcessing/lagrangian/reactingCloud1/
TUT: filter: add an example for the particleZoneInfo function object
- Previously, the multiFieldValue function object was limited to operate on
lists of fieldValue function objects.
- Any function objects that generate results can now be used, e.g.
pressureAverage
{
type multiFieldValue;
libs (fieldFunctionObjects);
operation average;
functions
{
inlet
{
type surfaceFieldValue;
operation areaAverage;
regionType patch;
name inlet;
fields (p);
writeFields no;
writeToFile no;
log no;
resultFields (areaAverage(inlet,p));
}
outlet
{
type surfaceFieldValue;
operation areaAverage;
regionType patch;
name outlet;
fields (p);
writeFields no;
writeToFile no;
log no;
}
average
{
type valueAverage;
functionObject testSample1;
fields (average(p));
writeToFile no;
log no;
}
}
}
TUT: cavity: add an example for the multiFieldValue function object
- now have both compactData(),compactLocalData(), compactRemoteData()
depending on where the compaction information is actually known.
The compactData() performs a consistent union of local and remote
values, which eliminates the danger of mapping to non-existent
locations but does require a double communication to setup.
Typically needed for point maps (for example).
The compactLocalData() and compactRemoteData() work on the
assumption that the source or target values are sufficent for
creating unique compact maps.
Can be used, for example, when compacting cell maps since there is
no possibility of a source cell being represented on different
target processors (ie, each cell is unique and only occurs once).
The existing compact() is equivalent to compactRemoteData()
and is now simply a redirect.
- use bitSet for defining compaction, but the existing compact()
continues to use a boolList (for code compatibility).
BUG: compaction in non-parallel mode didn't compact anything.
STYLE: compact ascii output for procAddressing
- simplify procAddressing read/write
- avoid accessing points in faMeshReconstructor.
Can rely on the patch meshPoints (labelList), which does not need
access to a pointField
- report number of points on decomposed mesh.
Can be useful additional information.
Additional statistics for finite area decomposition
- provide bundled reconstructAllFields for various reconstructors
- remove reconstructPar checks for very old face addressing
(from foam2.0 - ie, older than OpenFOAM itself)
- bundle all reading into fieldsDistributor tools,
where it can be reused by various utilities as required.
- combine decomposition fields as respective fieldsCache
which eliminates most of the clutter from decomposePar
and similfies reuse in the future.
STYLE: remove old wordHashSet selection (deprecated in 2018)
BUG: incorrect face flip handling for faMeshReconstructor
- a latent bug which is not yet triggered since the faMesh faces are
currently only definable on boundary faces (which never flip)
Geometry calculation scheme that performs geometry updates only in regions
where the mesh has changed, identified by comparing current and old points.
Example usage in fvSchemes:
geometry
{
type solidBody;
// Optional entries
// If set to false, update the entire mesh
partialUpdate yes;
// Cache the motion addressing (changed points, faces, cells etc)
cacheMotion yes;
}
The most frequent changes have been as follows.
from:
tmp<scalarField> tuTau(new scalarField(patch().size(), Zero));
scalarField& uTau = tuTau.ref();
to:
auto tuTau = tmp<scalarField>::New(patch().size(), Zero);
auto& uTau = tuTau.ref();
- Other changes involved the addition of - wherever approapriate -:
const
noexcept
auto
Previously, a nutWallFunctionFvPatchScalarField ref should be
created in epsilon, k, and omega wall functions to fetch various
common wall-function coefficients necessary to carry out and complete
local operations inside these wall functions.
However, this arrangement required the use of a nut wall function,
even when unnecessary, when any of non-nut wall functions are being used.
Therefore, some users had been redundantly restrained and
obstructed with rather obscure casting-error messages.
Also, the wall-function coefficients Cmu, kappa and E have been obtained
from the specified nutWallFunction in order to ensure that each patch
possesses the same set of values for these coefficients.
Although the motivation sounds reasonable, it has also been putting redundant
restraints on users and disregarding the specifics of each wall-function.
For example, the variation of epsilon in near-wall regions is usually very
steep and non-monotonic specific - an expert user may therefore want to use
an epsilon-specific coefficient, and this was not allowed by the previous
arrangement.
This commit introduces a new class (i.e. wallFunctionCoefficients) comprising
all common wall-function coefficients and yPlus calculations.
Previously, a number of wall functions were not not writing
their boundary-condition entries in the defacto order
(i.e. from type to value) while writing a field. For example:
<patchName>
{
lowReCorrection 1;
blending stepwise;
n 2;
type epsilonWallFunction; <!-- expected to be the first entry
value uniform 1; <!-- expected to be the last entry
}
Also, various wall functions have been writing out entries that
have not been being used by the wall function. For example:
<patchName>
{
type nutUSpaldingWallFunction;
...
blending stepwise; <!-- no blending treatment in nutUSpaldingWF
...
}
Additionally, various derived wall functions (e.g. atmOmegaWallFunction)
have been failing to write some of the inherited entries even though
these entries have been being used in carrying out wall-function calculations.
Taken these into consideration, wall functions have been reworked to obtain
reliable and consistent way of writing their traits while writing out a field.
- writeLocalEntries uses writeIfDifferent if constructed with getOrDefault.
ENH: simple faMeshSubset (zero-sized meshes only)
ENH: additional access methods for faMesh, primitive geometry mode
- wrapped walking of boundary edgeLabels as list of list
(similar to edgeFaces).
- primitive finiteArea geometry mode with reduced communication:
primarily interesting for decomposition/redistribution (#2436)
ENH: extra vtk debug outputs for checkFaMesh
- report per-processor sizes in the mesh summary
- similar functionality as newMesh etc.
Relocated to finiteVolume since there are no dynamicMesh dependencies.
- use simpler procAddressing (with updated mapDistributeBase).
separated from redistributePar
