Now that BasicThermo::Cp returns a volScalarField reference because Cp is cached
in BasicThermo code calling Cp can hold a reference rather than a copy for
efficiency.
The Clang compiler does not use std::move to transfer the result of the ternary
operator into the phase-fraction field resulting in it not being registered to
the database. To work around this limitation/bug the ternary operator is now
provided with tmp fields the result of which is passed with an IOobject to the
final field constructor to ensure it is registered and the IO options set
correctly.
An enumeration has been added to the arguments of the allocation
coefficient function, eta, to allow specification of how to allocate out
of bounds of the population balance size-groups. There are two options:
- "Clamp" will create an out-of-bounds allocation coefficient of exactly
one. This partitions unity across all size-space.
- "Extrapolate" will create an out-of-bounds allocation coefficient in
proportion to the ratio between the given size and the nearest
size-group size. This does not partition unity outside the range of
the size-groups.
The previous operation is equivalent to "Extrapolate".
It is not yet clear which method is preferable and under what
circumstances. More testing is required. The enumeration has been
created to facilitate this testing.
The specie molecular mass (Wi) and formation enthalpy (hfi) methods now
return dimensioned scalars. This permits their direct inclusion into
dimensioned field expressions. Non-dimensioned methods have been
retained with a "Value" suffix (i.e., WiValue and hfiValue).
All property functions in the low-level templated thermo property
implementations and the high-level virtual interfaces have been made
consistent. All energies and enthalpies are lower case to denote that
they are specific quantities. Molar functions have been removed as these
are no longer used anywhere.
The nearWallDist MeshObject is now deleted on mesh-change rather than updated
which is more efficient for cases with multiple mesh changes, e.g. motion,
stitching and mapping by avoiding unnecessary updates.
As a consequence of this change the wallDist::y() volScalarField reference
should not be cached across mesh changes so the turbulence models now obtain the
y field as required from the new momentumTransportModel::y() function, the
original near-wall distance function is now named momentumTransportModel::yb()
to clarify that it is the wall distance of the boundary cells.
This is consistent with the fluid solvers, and prevents failures
associated with using fields that haven't yet been updated or corrected
following mesh changes
This simple model creates a heat transfer coefficient in proportion with
the corresponding drag model's momentum transfer coefficient. A
user-defined Prandtl number and a harmonic average of the phases'
specific heats are used to specify the constant of proportionality.
This model has no physical basis. It exists primarily for testing
purposes. It has the advantage of being applicable to any interface,
including those representing segregated configurations.
Example usage:
heatTransfer
{
gas_segregatedWith_liquid
{
type Prandtl;
Pr 0.7;
}
}
The patch-specific mapper interfaces, fvPatchFieldMapper and
pointPatchFieldMapper, have been removed as they did not do anything.
Patch mapping constructors and functions now take a basic fieldMapper
reference.
An fvPatchFieldMapper.H header has been provided to aid backwards
compatability so that existing custom boundary conditions continue to
compile.
Currently in compressibleVoF vDot contains only the compressibility dilatation
effect whereas in multiphaseEuler the effect of sources are also included but
this will be refactored shortly so that the handling of mass sources and
compressibility is consistent between VoF and Euler-Euler solvers.
The previously hard-coded 1e-4 division stabilisation used when linearising vDot
for bounded semi-implicit solution of the phase-fractions is now an optional
user-input with keyword vDotResidualAlpha, e.g. in multiphaseEuler:
solvers
{
"alpha.*"
{
nAlphaCorr 1;
nAlphaSubCycles 2;
vDotResidualAlpha 1e-6;
}
.
.
.
The fact that these names create sources in their associated transport
equations is clear in context, so the name does not need to contain
'Source'.
Having 'Source' in the name is a historic convention that dates back to
when fvModels and fvConstraints were combined in a single fvOptions
interface. In this interface, disambiguation between sources and
constraints was necessary.
The full set of name changes is as follows:
accelerationSource -> acceleration
actuationDiskSource -> actuationDisk
effectivenessHeatExchangerSource -> effectivenessHeatExchanger
explicitPorositySource -> porosityForce
radialActuationDiskSource -> radialActuationDisk
rotorDiskSource -> rotorDisk
sixDoFAccelerationSource -> sixDoFAcceleration
solidEquilibriumEnergySource -> solidThermalEquilibrium
solidificationMeltingSource -> solidificationMelting
volumeFractionSource -> volumeBlockage
interRegionExplicitPorositySource -> interRegionPorosityForce
VoFSolidificationMeltingSource -> VoFSolidificationMelting
The old names are still available for backwards compatibility.
IsothermalSolidPhaseModel does not update energy and density from pressure
whereas IsothermalPhaseModel does to allow compressible fluid phases to change
volume due to pressure changes.
for thermophysical transport within stationary solid phases. This provides a
consistent interface to heat transport within solids for single and now
multiphase solvers so that for example the wallHeatFlux functionObject can now
be used with multiphaseEuler, see tutorials/multiphaseEuler/boilingBed.
Also this development supports anisotropic thermal conductivity within the
stationary solid regions which was not possible previously.
The tutorials/multiphaseEuler/bed and tutorials/multiphaseEuler/boilingBed
tutorial cases have been updated for phaseSolidThermophysicalTransportModel by
changing the thermo type in physicalProperties.solid to heSolidThermo. This
change will need to be made to all multiphaseEuler cases involving stationary
phases.
The interface for fvModels has been modified to improve its application
to "proxy" equations. That is, equations that are not straightforward
statements of conservation laws in OpenFOAM's usual convention.
A standard conservation law typically takes the following form:
fvMatrix<scalar> psiEqn
(
fvm::ddt(alpha, rho, psi)
+ <fluxes>
==
<sources>
);
A proxy equation, on the other hand, may be a derivation or
rearrangement of a law like this, and may be linearised in terms of a
different variable.
The pressure equation is the most common example of a proxy equation. It
represents a statement of the conservation of volume or mass, but it is
a rearrangement of the original continuity equation, and it has been
linearised in terms of a different variable; the pressure. Another
example is that in the pre-predictor of a VoF solver the
phase-continuity equation is constructed, but it is linearised in terms
of volume fraction rather than density.
In these situations, fvModels sources are now applied by calling:
fvModels().sourceProxy(<conserved-fields ...>, <equation-field>)
Where <conserved-fields ...> are (alpha, rho, psi), (rho, psi), just
(psi), or are omitted entirely (for volume continuity), and the
<equation-field> is the field associated with the proxy equation. This
produces a source term identical in value to the following call:
fvModels().source(<conserved-fields ...>)
It is only the linearisation in terms of <equation-field> that differs
between these two calls.
This change permits much greater flexibility in the handling of mass and
volume sources than the previous name-based system did. All the relevant
fields are available, dimensions can be used in the logic to determine
what sources are being constructed, and sources relating to a given
conservation law all share the same function.
This commit adds the functionality for injection-type sources in the
compressibleVoF solver. A following commit will add a volume source
model for use in incompressible solvers.
This change makes multiphaseEuler more consistent with other modules and
makes its sub-libraries less inter-dependent. Some left-over references
to multiphaseEulerFoam have also been removed.
The previous implementation was dimensionally inconsistent and was
missing a factor of the VbyA field. This change will, in most cases,
reduce the total impingement pressure contribution.
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.
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.
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.
