When the parallel switch is set false (the default), the system call is executed
only on the master processor, if true it is executed on all processors.
Patch contributed by Stanislau Stasheuski, Aalto University.
Description
This fvModel applies forcing to the liquid phase-fraction field and all
components of the vector field to relax the fields towards those
calculated from the current wave distribution.
The force coefficient \f$\lambda\f$ should be set based on the desired level
of forcing and the residence time the waves through the forcing zone. For
example, if waves moving at 2 [m/s] are travelling through a forcing zone 8
[m] in length, then the residence time is 4 [s]. If it is deemed necessary
to force for 5 time-scales, then \f$\lambda\f$ should be set to equal 5/(4
[s]) = 1.2 [1/s]. If more aggressive forcing is required adjacent to the
boundaries, which is often the case if wave boundary conditions are
specified at outflow boundaries, the optional \f$\lambdaBoundary\f$
coefficient can be specified higher than the value of \f$\lambda\f$.
Alternatively the forcing force coefficient \f$\lambdaCoeff\f$ can be
specified in which case \f$\lambda\f$ is evaluated by multiplying the
maximum wave speed by \f$\lambdaCoeff\f$ and dividing by the forcing region
length. \f$\lambdaBoundary\f$ is similarly evaluated from
\f$\lambdaBoundaryCoeff\f$ if specified.
Usage
Example usage:
\verbatim
waveForcing1
{
type waveForcing;
libs ("libwaves.so");
liquidPhase water;
// Define the line along which to apply the graduation
origin (600 0 0);
direction (-1 0 0);
// // Or, define multiple lines
// origins ((600 0 0) (600 -300 0) (600 300 0));
// directions ((-1 0 0) (0 1 0) (0 -1 0));
scale
{
type halfCosineRamp;
start 0;
duration 300;
}
lambdaCoeff 2; // Forcing coefficient
// lambdaBoundaryCoeff 10; // Optional boundary forcing coefficient
// Useful when wave BCs are specified at outlets
// Write the forcing fields: forcing:scale, forcing:forceCoeff
writeForceFields true;
}
\endverbatim
These deltas constructs another sub-delta, using the same keyword (i.e.,
'delta') to select the type of the sub-delta as was used to select the
outer delta. For example:
delta vanDriest;
vanDriestCoeffs
{
delta cubeRootVol;
}
The '<Type>Coeffs' sub-dictionary is now not optional. It cannot be
optional, because if it were omitted then the 'delta' entries would
clash. If the coefficients dictionary were omitted and (for example) the
'vanDriest' entry was chosen, then the constructors would get stuck in
an infinite recursion, with each vanDriest delta just constructing
another vanDriest sub-delta.
The functions module now applies time-step restrictions from the
functions that are running, rather than from the sub-solver. The
sub-solver only exists to be constructed so that its data is available
to the functions. It should not affect the solution process in any way.
e.g.
waveForcing1
{
type waveForcing;
libs ("libwaves.so");
liquidPhase water;
// Define the line along which to apply the graduation
origin (600 0 0);
direction (-1 0 0);
// // Or, define multiple lines
// origins ((600 0 0) (600 -300 0) (600 300 0));
// directions ((-1 0 0) (0 1 0) (0 -1 0));
scale
{
type halfCosineRamp;
start 0;
duration 300;
}
lambda 0.5; // Forcing coefficient
// lambdaBoundary 2; // Optional boundary forcing coefficient
// Useful when wave BCs are specified
// without mean flow
// Write the forcing fields: forcing:scale, forcing:forceCoeff
writeForceFields true;
}
will write the fields forcing:scale and forcing:forceCoeff at the start of the
run to visualise and check correctness.
These functions cannot execute on the 'postPatch' hook because at this
point the particle properties have already been altered by the patch
interaction (i.e., the rebound has occurred and the velocity has
reversed). They need to execute in advance of the patch interaction.
There is no 'prePatch' hook, and implementing one is not
straightforward, so these functions have been changed to use the
'preFace' hook and manually check that the face in question is a
boundary face.
Patch contributed by Timo Niemi, VTT.
The volumeFraction cloud function will create and write a vol-field of
the cloud's volume fraction. It requires no additional controls. Example
in constant/cloudProperties:
cloudFunctions
{
volumeFraction1
{
type volumeFraction;
}
}
This replaces voidFraction, which was incorrectly named in that it also
write the volume fraction (not one-minus the volume fraction), and who's
storage of the field was flawed in that it caused registration clashes
with fields stored by certain other Lagrangian models.
A cloud's volume fraction is now generated with parcelCloud::alpha, and
the mass fraction with parcelCloud::Y. This is consistent with the rest
of OpenFOAM.
A new algorithm for calculating a face's area and centre has been
implemented as a static method of the face class, called
face::areaAndCentreStabilised. This method tracks the round off error
associated with the calculation of the centroid and uses this to
determine when and how much to stabilise the result.
This is utilised in the calculation of the centroids of face-face
intersections, which become the face centres on non-conformal
couples. This therefore improves the robustness of non-conformal
couples.
This new algorithm has not replaced the procedure used in the standard
calculation of face centres. The face centres in the polygonal mesh are
expected to be of better quality than those resulting from an
intersection calculation, so the additional expense associated with the
stabilised algorithm is not thought to be necessary.
In order to add convergence control to multi-region cases it is no longer
necessary to provide a residualControl entry in all region, convergence
specification can be provided for any sub-set of the region for which particular
residual levels should be met.
The tutorials/multiRegion/CHT/circuitBoardCooling case now has valid convergence
criteria to demonstrate this change.
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.
