- allows reuse of an int64_t scotch library with label-size 32
and/or label-size 64.
COMP: prefer scotch/metis/kahip libraries with label-size qualifiers
- as noted in #2200, mpirun may insert mpi libraries higher in the
library loader which can cause masking of our ThirdParty libraries
of the same name. With scotch (for example), the operating system
may have an int32 version installed but we have an int64 version
compiled under ThirdParty. Runing in serial is fine, but in parallel
we resolve to the (incorrect) system version due to the adjustments
in mpirun.
- adjust the ThirdParty make scripts to also create corresponding
links (eg, 'ln -s libscotch.so libscotch-int64.so') and prefer
linkage with these qualified libraries.
Eg, -L$(SCOTCH_LIB_DIR) -lscotch$(SCOTCH_LIBNAME_SUFFIX)
this prevent accidental runtime linkage with the system versions.
STYLE: simplify scotch interface code by using local functions
- allows reuse similar to refPtr for wrapping different content.
- additional control for when contents are copied back,
instead of waiting for the adaptor to go out of scope.
Eg,
if (adaptor.active())
{
adaptor.commit();
adaptor.clear();
}
- static ConstPrecisionAdaptor::get method renamed to 'select' as a
better description of its purpose and avoid confusion with
non-static 'get' method.
Was previously only used within GAMGPreconditioner, but even there
it is better just to use the ConstPrecisionAdaptor directly.
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.
