For cases where the number of injectors exceeded the number of parcels to
inject, processing the injectors sequentially led to not all injector locations
being active and yielding non-physical spatial distributions.
Previous naming conventions for input variables in the
normal, multiNormal, RosinRammler, and massRosinRammler
distributions were heuristic and did not reflect
the de facto conventions being used in statistics.
BUG: distributionModel: disallow any distribution
where input min is equal to input max
ENH: distributionModel: ensure execution of check() at ctor level
Previously, for basic incompressible and compressible simulations,
the "force" function object has not been using the user-specified "UName"
for the "devRhoReff" computation (affecting the tangential component),
but using the "U" of the latest available step. In contrast,
the user-specified "pName" has always been being used correctly.
This has been causing issues for users when they wish to use a specific
"UMean" field in various force and forceCoeff function object computations.
Introduces a new optional keyword of label type 'log'
to linear-solver dictionaries to enable variable-specific
debug statements. For example, in fvOptions file:
solvers
{
p
{
solver GAMG;
...
log 2;
}
U
{
...
log 0;
}
}
The meanings of values of 'log' are:
log 0; <!-- no output
log 1; <!-- standard output
log 2; <!-- debug output
// values higher than 2 are expected to have no effect
This keyword does not directly affect the operations of various
DebugSwitches and backward compatibility has been ensured in exchange
of code cleanness. The related DebugSwitches are:
DebugSwitches
{
SolverPerformance 0;
GAMG 0;
PCG 0;
PBiCG 0;
smoothSolver 0;
}
- previously reported the WM_PROJECT_VERSION in the top banner
but this makes it overly sensitive to arbitrary user naming.
Change to the current API in the comment banner, include the
WM_PROJECT_VERSION as part of the reported "Build: ..."
string instead.
- previously had a patch-size check, which caused a zero-sized patch
to be "sticky" as uniform Zero regardless of what the original input
stated (eg, "constant 0.5")
This was caused by short-circuiting logic that circumvented reading
on zero-size patches.
- support non-uniform scaling, prescaling and cartesian coordinate
transformations.
Eg, stretch in one direction and then rotate
```
prescale (1.5 1 1);
transform
{
origin (0 0 0);
rotation
{
type axisAngle;
axis (0 0 1);
angle 45;
}
}
```
- support "transformed" versions of blockMesh vertices, topology.
With the additional of transformations etc, a simplistic application
of a single scale parameter is no longer sufficient.
new: blMesh.vertices(true);
old: blMesh.vertices() * blMesh.scaleFactor();
new: blMesh.topology(true);
old: N/A
- add individual edge access for blockDescriptor.
Saves copying and duplicate calculations.
- handle '(block face)' specification for curved faces,
which is ok for external block faces, but likely somewhat
questionable if used for internal block faces.
- Can specify
```
transform
{
origin (1 2 3);
rotation none;
}
```
instead of the longer form
```
transform
{
origin (1 2 3);
e1 (1 0 0);
e3 (0 0 1);
}
```
COMPAT: remove old (pre-1812) Euler and STARCD keywords
- use "angles", remove old compat name "rotation"
as clutter and possible confusion with "coordinate rotation"
STYLE: remove coordinate rotation move constructors
- an unnecessary holdover from older code.
- for v2106 restricted the input conversion of string types to disallow
treating verbatim strings as possible word input.
However, it was too strict in just allowing quoted strings
and should have also permitted '$'-sigil variables as well.
- ensure that errors for bad string -> word input conversion
are raised from within the '>>' read operator. These were
previously triggered during the stripping process, which
made error tracing more difficult.
