Now with the addition of the optional dependenciesModified() function classes
which depend on other classes which are re-read from file when modified are also
automatically updated via their read() function called by
objectRegistry::readModifiedObjects.
This significantly simplifies the update of the solutionControls and modular
solvers when either the controlDict or fvSolution dictionaries are modified at
run-time.
The momentum equation central coefficient and drag matrix is formulated,
inverted and used to eliminate the drag terms from each of the phase momentum
equations which are combined for formulate a drag-implicit pressure equation.
This eliminates the lagged drag terms from the previous formulation which
significantly improves convergence for small particle and Euler-VoF high-drag
cases.
It would also be possible to refactor the virtual-mass terms and include the
central coefficients of the phase acceleration terms in the drag matrix before
inversion to further improve the implicitness of the phase momentum-pressure
coupling for bubbly flows. This work is pending funding.
With the change the boundary temperature is updated only via the evaluate call
rather than derived from the corresponding energy solution. This has proved
more stable and convergent for the wallBoiling cases.
This definition was incorrect, and the correct form is not needed as it
is the same as indirectPrimitivePatch
Resolves bug report https://bugs.openfoam.org/view.php?id=4008
to specify the path name of the output dictionary to which the expanded and/or
changed dictionary is written.
Usage: foamDictionary [OPTIONS] <dictionary file>
options:
-add <value> Add a new entry
-case <dir> specify alternate case directory, default is the cwd
-dict Set, add or merge entry from a dictionary.
-diff <dict> Write differences with respect to the specified dictionary
-entry <name> report/select the named entry
-expand Read the specified dictionary file and expand the macros
etc.
-fileHandler <handler>
override the fileHandler
-hostRoots <((host1 dir1) .. (hostN dirN))>
slave root directories (per host) for distributed running
-includes List the #include/#includeIfPresent files to standard output
-keywords list keywords
-libs '("lib1.so" ... "libN.so")'
pre-load libraries
-merge <value> Merge entry
-noFunctionObjects
do not execute functionObjects
-output <path name>
Path name of the output dictionary
-parallel run in parallel
-remove Remove the entry.
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-set <value> Set entry value, add new entry or apply list of
substitutions
-value Print entry value
-writePrecision <label>
Write with the specified precision
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
manipulates dictionaries
Now if the -case option is specified the dictionary path provided is treated as
relative to the case path, e.g.
foamDictionary -expand -case shockFluid/shockTube system/controlDict
Both argument and value dimensions can be set for inline-constructable
function1-s. For example, this inline table function:
massFlowRate table [CAD] [g/s]
(
(0 0.46)
(0.17 1.9)
(0.31 4.8)
);
Is equivalent to this dictionary specification:
massFlowRate
{
type table;
xDimensions [CAD];
dimensions [g/s];
values
(
(0 0.46)
(0.17 1.9)
(0.31 4.8)
);
}
In the inline form, the argument/x-dimensions come first, and the value
dimensions second. If there only one dimension set provided, then this
is assumed to be the value dimensions.
The functionality necessary to write in a different unit set has been
removed. This was excessivelty complex, never used in practice, and of
little practical usage. Output numeric data, in general, is not designed
to be conveniently user-readable, so it is not important what unit
system it is written in.
This can be used identically to a standard Function1. In addition, it
also permits specification of the dimensions. This allows the dimensions
to be checked. It also permits unit conversions. For example:
<name>
{
type table;
// Dimensions
xDimensions [CAD]; // Optional. Argument dimensions/units.
// Here, this specifies coordinates are in
// crank angle degrees (available if using
// engine time).
dimensions [mm]; // Optional. Value dimensions/units.
// Here, values are in mm.
// Tablulated data
values
(
(0 0)
(60 12) // <-- i.e., 12 mm at 60 degrees
(180 20)
(240 8)
(360 0)
);
outOfBounds repeat;
}
This replaces TimeFunction1, as it allows per-function control over
whether the function is considered to be one of real-time or user-time.
Description
Generates the weight for step-wise interpolation and integration
The step transitions are at the end of each interval.
The value returned by the Table::value function returns the value set for the
start of each interval within that interval and transitions abruptly to the next
interval value at the start of the next interval.
DecomposePar and reconstructPar now interleave the processing of
multiple regions. This means that with the -allRegions option, the
earlier times are completed in their entirety before later times are
considered. It also lets regions to access each other during
decomposition and reconstruction, which will be important for
non-conformal region interfaces.
To aid interpretation of the log, region prefixing is now used by both
utilities in the same way as is done by foamMultiRun.
DecomposePar has been overhauled so that it matches reconstructPar much
more closely, both in terms of output and of iteration sequence. All
meshes and addressing are loaded simultaneously and each field is
considered in turn. Previously, all the fields were loaded, and each
process and addressing set was considered in turn. This new strategy
optimises memory usage for cases with lots of fields.
When the flow is stationary (e.g., at the beginning of a run) the
rDeltaT calculation now requires a maxDeltaT setting in the PIMPLE
sub-section of the fvSolution dictionary. This prevents floating point
errors associated with rDeltaT approaching zero.
The phase velocity mean adjustment was introduced for consistency with phase
flux mean adjustment which is necessary to ensure the mean flux divergence is
preserved. However for systems with very high drag it has proved preferable to
not adjust the velocity of the phases to conserve momentum rather than ensure
consistency with the fluxes.
The old fluid-specific rhoThermo has been split into a non-fluid
specific part which is still called rhoThermo, and a fluid-specific part
called rhoFluidThermo. The rhoThermo interface has been added to the
solidThermo model. This permits models and solvers that access the
density to operate on both solid and fluid thermophysical models.
The he*Thermo classes have been renamed to match their corresponding
basic thermo classes. E.g., rhoThermo now corresponds to RhoThermo,
rather than heRhoThermo.
Mixture classes (e.g., pureMixtrure, coefficientMulticomponentMixture),
now have no fvMesh or volScalarField dependence. They operate on
primitive values only. All the fvMesh-dependent functionality has been
moved into the base thermodynamic classes. The 'composition()' access
function has been removed from multi-component thermo models. Functions
that were once provided by composition base classes such as
basicSpecieMixture and basicCombustionMixture are now implemented
directly in the relevant multi-component thermo base class.
This simplifies the IOerror constructors and allows for the location to
be conveniently cached for errors that can't be triggered until after
the IO operation.
