- previously introduced `getOrDefault` as a dictionary _get_ method,
now complete the transition and use it everywhere instead of
`lookupOrDefault`. This avoids mixed usage of the two methods that
are identical in behaviour, makes for shorter names, and promotes
the distinction between "lookup" access (ie, return a token stream,
locate and return an entry) and "get" access (ie, the above with
conversion to concrete types such as scalar, label etc).
- for some special cases we wish to mark command-line arguments as
being optional, in order to do our own treatment. For example,
when an arbitrary number of arguments should be allowed.
Now tag this situation with argList::noMandatoryArgs().
The argList::argsMandatory() query can then be used in any further
logic, including the standard default argument checking.
- with the new default check, can consolidate the special-purpose
"setRootCaseNonMandatoryArgs.H"
into the regular
"setRootCase.H"
- revert to a simple "setRootCase.H" and move all the listing related
bits to a "setRootCaseLists.H" file. This leaves the information
available for solvers, or whoever else wishes, without being
introduced everywhere.
- add include guards and scoping to the listing files and rename to
something less generic.
listOptions.H -> setRootCaseListOptions.H
listOutput.H -> setRootCaseListOutput.H
- relocate some standard functionality to TimePaths to allow a lighter
means of managing time directories without using the entire Time
mechanism.
- optional enableLibs for Time construction (default is on)
and a corresponding argList::noLibs() and "-no-libs" option
STYLE:
- mark Time::outputTime() as deprecated MAY-2016
- use pre-increment for runTime, although there is no difference in
behaviour or performance.
To unsure fvOptions are instantiated for post-processing createFvOptions.H must
be included in createFields.H rather than in the solver directly.
Resolves bug-report https://bugs.openfoam.org/view.php?id=2733
BUG: porousSimpleFoam: moved createFvOptions.H into createFields.H for -postProcess option
Resolves bug-report https://bugs.openfoam.org/view.php?id=2733
BUG: solvers: Moved fvOption construction into createFields.H for post-processing
This ensures that the fvOptions are constructed for the -postProcessing option
so that functionObjects which process fvOption data operate correctly in this
mode.
- controlled by the the 'printExecutionFormat' InfoSwitch in
etc/controlDict
// Style for "ExecutionTime = " output
// - 0 = seconds (with trailing 's')
// - 1 = day-hh:mm:ss
ExecutionTime = 112135.2 s ClockTime = 113017 s
ExecutionTime = 1-07:08:55.20 ClockTime = 1-07:23:37
- Callable via the new Time::printExecutionTime() method,
which also helps to reduce clutter in the applications.
Eg,
runTime.printExecutionTime(Info);
vs
Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s"
<< " ClockTime = " << runTime.elapsedClockTime() << " s"
<< nl << endl;
--
ENH: return elapsedClockTime() and clockTimeIncrement as double
- previously returned as time_t, which is less portable.
- in many cases can just use lookupOrDefault("key", bool) instead of
lookupOrDefault<bool> or lookupOrDefault<Switch> since reading a
bool from an Istream uses the Switch(Istream&) anyhow
STYLE: relocated Switch string names into file-local scope
The boundary conditions of HbyA are now constrained by the new "constrainHbyA"
function which applies the velocity boundary values for patches for which the
velocity cannot be modified by assignment and pressure extrapolation is
not specified via the new
"fixedFluxExtrapolatedPressureFvPatchScalarField".
The new function "constrainPressure" sets the pressure gradient
appropriately for "fixedFluxPressureFvPatchScalarField" and
"fixedFluxExtrapolatedPressureFvPatchScalarField" boundary conditions to
ensure the evaluated flux corresponds to the known velocity values at
the boundary.
The "fixedFluxPressureFvPatchScalarField" boundary condition operates
exactly as before, ensuring the correct flux at fixed-flux boundaries by
compensating for the body forces (gravity in particular) with the
pressure gradient.
The new "fixedFluxExtrapolatedPressureFvPatchScalarField" boundary
condition may be used for cases with or without body-forces to set the
pressure gradient to compensate not only for the body-force but also the
extrapolated "HbyA" which provides a second-order boundary condition for
pressure. This is useful for a range a problems including impinging
flow, extrapolated inlet conditions with body-forces or for highly
viscous flows, pressure-induced separation etc. To test this boundary
condition at walls in the motorBike tutorial case set
lowerWall
{
type fixedFluxExtrapolatedPressure;
}
motorBikeGroup
{
type fixedFluxExtrapolatedPressure;
}
Currently the new extrapolated pressure boundary condition is supported
for all incompressible and sub-sonic compressible solvers except those
providing implicit and tensorial porosity support. The approach will be
extended to cover these solvers and options in the future.
Note: the extrapolated pressure boundary condition is experimental and
requires further testing to assess the range of applicability,
stability, accuracy etc.
Henry G. Weller
CFD Direct Ltd.
fvOptions are transferred to the database on construction using
fv::options::New which returns a reference. The same function can be
use for construction and lookup so that fvOptions are now entirely
demand-driven.
The abstract base-classes for fvOptions now reside in the finiteVolume
library simplifying compilation and linkage. The concrete
implementations of fvOptions are still in the single monolithic
fvOptions library but in the future this will be separated into smaller
libraries based on application area which may be linked at run-time in
the same manner as functionObjects.
fvOptions does not have the appropriate structure to support MRF as it
is based on option selection by user-specified fields whereas MRF MUST
be applied to all velocity fields in the particular solver. A
consequence of the particular design choices in fvOptions made it
difficult to support MRF for multiphase and it is easier to support
frame-related and field related options separately.
Currently the MRF functionality provided supports only rotations but
the structure will be generalized to support other frame motions
including linear acceleration, SRF rotation and 6DoF which will be
run-time selectable.
This formulation provides C-grid like pressure-flux staggering on an
unstructured mesh which is hugely beneficial for Euler-Euler multiphase
equations as it allows for all forces to be treated in a consistent
manner on the cell-faces which provides better balance, stability and
accuracy. However, to achieve face-force consistency the momentum
transport terms must be interpolated to the faces reducing accuracy of
this part of the system but this is offset by the increase in accuracy
of the force-balance.
Currently it is not clear if this face-based momentum equation
formulation is preferable for all Euler-Euler simulations so I have
included it on a switch to allow evaluation and comparison with the
previous cell-based formulation. To try the new algorithm simply switch
it on, e.g.:
PIMPLE
{
nOuterCorrectors 3;
nCorrectors 1;
nNonOrthogonalCorrectors 0;
faceMomentum yes;
}
It is proving particularly good for bubbly flows, eliminating the
staggering patterns often seen in the air velocity field with the
previous algorithm, removing other spurious numerical artifacts in the
velocity fields and improving stability and allowing larger time-steps
For particle-gas flows the advantage is noticeable but not nearly as
pronounced as in the bubbly flow cases.
Please test the new algorithm on your cases and provide feedback.
Henry G. Weller
CFD Direct
Improves stability and convergence of systems in which drag dominates
e.g. small particles in high-speed gas flow.
Additionally a new ddtPhiCorr strategy is included in which correction
is applied only where the phases are nearly pure. This reduces
staggering patters near the free-surface of bubble-column simulations.
