requiring all parts of the moving phase solution algorithm to loop and operate
on the moving phases only making the code easier to understand and maintain.
The central coefficient part of the virtual-mass phase acceleration matrix is
now included in the phase velocity transport central coefficient + drag matrix
so that the all the phase contributions to each phase momentum equation are
handled implicitly and consistently without lagging contribution from the other
phases in either the pressure equation or phase momentum correctors.
This improves the conditioning of the pressure equation and convergence rate of
bubbly-flow cases.
Population balance size-group fraction 'f<index>.<phase>' fields are now
read from an 'fDefault.<phase>' field if they are not provided
explicitly. This is the same process as is applied to species fractions
or fvDOM rays. The sum-of-fs field 'f.<phase>' is no longer required.
The value of a fraction field and its boundary conditions must now be
specified in the corresponding field file. Value entries are no longer
given in the size group dictionaries in the constant/phaseProperties
file, and an error message will be generated if a value entry is found.
The fraction fields are now numbered programatically, rather than being
named. So, the size-group dictionaries do not require a name any more.
All of the above is also true for any 'kappa<index>.<phase>' fields that
are constructed and solved for as part of a fractal shape model.
The following is an example of a specification of a population balance
with two phases in it:
populationBalances (bubbles);
air1
{
type pureIsothermalPhaseModel;
diameterModel velocityGroup;
velocityGroupCoeffs
{
populationBalance bubbles;
shapeModel spherical;
sizeGroups
(
{ dSph 1e-3; } // Size-group #0: Fraction field f0.air1
{ dSph 2e-3; } // ...
{ dSph 3e-3; }
{ dSph 4e-3; }
{ dSph 5e-3; }
);
}
residualAlpha 1e-6;
}
air2
{
type pureIsothermalPhaseModel;
diameterModel velocityGroup;
velocityGroupCoeffs
{
populationBalance bubbles;
shapeModel spherical;
sizeGroups
(
{ dSph 6e-3; } // Size-group #5: Fraction field f5.air2
{ dSph 7e-3; } // ...
{ dSph 8e-3; }
{ dSph 9e-3; }
{ dSph 10e-3; }
{ dSph 11e-3; }
{ dSph 12e-3; }
);
}
residualAlpha 1e-6;
}
Previously a fraction field was constructed automatically using the
boundary condition types from the sum-of-fs field, and the value of both
the internal and boundary field was then overridden by the value setting
provided for the size-group. This procedure doesn't generalise to
boundary conditions other than basic types that store no additional
data, like zeroGradient and fixedValue. More complex boundary conditions
such as inletOutlet and uniformFixedValue are incompatible with this
approach.
This is arguably less convenient than the previous specification, where
the sizes and fractions appeared together in a table-like list in the
sizeGroups entry. In the event that a substantial proportion of the
size-groups have a non-zero initial fraction, writing out all the field
files manually is extremely tedious. To mitigate this somewhat, a
packaged function has been added to initialise the fields given a file
containing a size distribution (see the pipeBend tutorial for an example
of its usage). This function has the same limitations as the previous
code in that it requires all boundary conditions to be default
constructable.
Ultimately, the "correct" fix for the issue of how to set the boundary
conditions conveniently is to create customised inlet-outlet boundary
conditions that determine their field's position within the population
balance and evaluate a distribution to determine the appropriate inlet
value. This work is pending funding.
Non-alphanumeic characters in the name of the coded object are now *all*
replaced by underscores. This means functions with complex names (i.e.,
like those resulting from command line substitutions) can now be
compiled.
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.
