This replaces compressibleInterFilmFoam in a more flexible, general and easily
maintainable form. A compressibleInterFilmFoam script is provided to redirect
uses to the replacement functionality:
The compressibleInterFilmFoam solver has solver has been replaced by the more general
compressibleInterFoam solver, which now supports surface films using the new
VoFSurfaceFilm fvOption.
To run with with surface film create a system/fvOptions dictionary
containing the VoFSurfaceFilm specification, e.g.
VoFSurfaceFilm
{
type VoFSurfaceFilm;
phase water;
}
The "full" filtering option in isoSurface now no longer attempts to
remove non-manifold faces. As a result, this filtering level is now
robust, but it may leave small imperfections in the surface. This has
been reinstated as the default filtering level as it has advantageous
properties over "partial" filtering in both smoothness of visualisation
and in the size of the files it generates.
A new "clean" level has been added, which does try and remove
imperfections. This is equivalent to the previous operation of the
"full" option. This is not guaranteed to be robust. In certain
configurations the removal process can propagate and delete an entire
section of the surface.
Usage
\table
Property | Description | Required | Default value
type | Type name: forces | yes |
log | Write force data to standard output | no | no
patches | Patches included in the forces calculation | yes |
p | Pressure field name | no | p
U | Velocity field name | no | U
rho | Density field name (see below) | no | rho
phase | Phase name for phase-fraction | no |
CofR | Centre of rotation (see below) | no |
directForceDensity | Force density supplied directly (see below)|no|no
fD | Name of force density field (see below) | no | fD
\endtable
with the optional 'phase' entry the corresponding phase-fraction is used to
filter the surfaces forces for that phase.
The "full" filtering option has been found not to be sufficiently
robust. It erroneously removes entire contiguous sections of the
iso-surface in a number of situations. Full filtering can still be
enabled by specifying "filtering full;" in the relevant dictionary.
This source choses cells below a certain distance to a patch or a set of
multiple patches:
Example Usage in system/topoSetDict:
actions
(
{
name c0;
type cellSet;
action new;
source patchDistanceToCell;
sourceInfo
{
patch ".*Wall";
distance 0.1;
}
}
);
Example usage in system/setFieldsDict:
defaultFieldValues
(
volScalarFieldValue alpha.water 0
);
regions
(
patchDistanceToCell
{
patches (".*Wall" atmosphere);
distance 0.1;
fieldValues
(
volScalarFieldValue alpha.water 1
);
}
);
interRegionExplicitPorositySource: Removed the unnecessary and inappropriate
bidirectional mapping of data between the regions sharing the porous media. Now
the drag is calculated on the same mesh as the flow and filtered according to
the fraction of the cells containing porosity.
To complete this work a small change will be made to the mesh-mapping functions.
This provides the same behaviour as the assign operator, but with
certain checks removed as they do not apply when the source tmp is an
rvalue and will therefore not be retained after the assignment
operation. It is also consistent with and complimentary to the behaviour
of the move constructor.
This function gives a value of one during a user-specified duration, and
zero at all other times. It is useful for defining the time range in
which an injection or ignition heat source or similar operates.
Example usage, scaling a value:
<name>
{
type scale;
scale squarePulse;
start 0;
duration 1;
value 100;
}
This function has been utilised in a number of tutorial fvOption
configurations to provide a specific window in which the fvOption is
applied. This was previously achieved by "timeStart" and "duration"
controls hard coded into the fvOptions themselves.
This fvOption applies a mass source to the continuity equation and to
all field equations.
Example usage:
massSource
{
type massSource;
selectionMode cellSet;
cellSet massSource;
massFlowRate 1e-4;
fieldValues
{
U (10 0 0);
T 350;
k 0.375;
epsilon 14.855;
}
}
Values should be provided for all solved for fields. Warnings will be
issued if values are not provided for fields for which transport equations
are solved. Warnings will also be issued if values are provided for fields
which are not solved for.
A number of fvOptions that apply to a user-derined field can now
automatically work what primitive type they apply to. These options can
apply to any field type, and in some cases even multiple fields of
differing type. Example usage of the options to which this change
applies are shown below:
codedSource1
{
type codedSource;
name codedSource1;
field h;
...
}
fixedValueConstraint1
{
type fixedValueConstraint;
fieldValues
{
R (1 0 0 1 0 1);
epsilon 150;
}
...
}
phaseLimitStabilization11
{
type phaseLimitStabilization;
field sigma.liquid;
...
}
Previously to apply to a given type, these options had to be selected
with the name of the type prepended to the option name (e.g., "type
symmTensorPhaseLimitStabilization;") and those that operated on multiple
fields were restricted to those fields being of the same type.
A number of other options have had improvements made to their handling
of user specification of fields. Where possible, the option will now
attempt to work out what field the option applies to automatically. The
following options, therefore, no longer require "field" or "fields"
entries:
actuationDiskSource
buoyancyEnergy
buoyancyForce
meanVelocityForce
rotorDiskSource
volumeFractionSource
constantHeatTransfer
function2HeatTransfer
variableHeatTransfer
Non-standard field names can be overridden in the same way as in
boundary conditions; e.g., the velocity name can be overridden with a "U
<UName>;" entry if it does not have the default name, "U". The name of
the energy field is now always determined from the thermodynamics
model and should always be correct. Some options that can be applied to
an individual phase also support a "phase <phaseName>;" entry;
fvOptions field-name handling has been rewritten to increase its
flexibility and to improve warning messages. The flexibility now allows
for options that apply to all fields, or all fields of a given phase,
rather than being limited to a specific list of field names. Messages
warning about options that have not been applied now always print just
once per time-step.
The injection models do not inject parcels into the film they specifically eject
parcels from the film and the name "injection" is very confusing and misleading
hence the logical rename injection -> ejection.
Originally the only supported geometry specification were triangulated surfaces,
hence the name of the directory: constant/triSurface, however now that other
surface specifications are supported and provided it is much more logical that
the directory is named accordingly: constant/geometry. All tutorial and
template cases have been updated.
Note that backward compatibility is provided such that if the constant/geometry
directory does not exist but constant/triSurface does then the geometry files
are read from there.
Mesh-motion with or without topology change or AMI is now supported in
multiphaseEulerFoam for both cell- and face-momentum algorithms.
The new tutorial case mixerVesselAMI2D is provided which is the AMI version of
the 4-phase MRF mixerVessel2D case. It is setup with the cell-momentum
algorithm but also runs fine with the face-momentum algorithm although the
results are noticeably less accurate, particularly when the case is run
single-phase and compared directly with those from pimpleFoam.
Further testing is in progress.
I2D/constant/thermophysicalProperties.water
setTimeStep is now compatible with a 'writeControl adjustableRunTime;'
setting in the systemControlDict. If 'adjustableRunTime' is selected
then the time-step values set by this function object will not be
exactly as specified, but write intervals will be matched exactly.
All function object time adjustment is now done during the execute
methods, so the specific setTimeStep hooks have been removed.
All function objects now re-read as a result of run-time modifications
to the system/controlDict.
Function objects that write log files (via the logFiles class) will now
generate a new postProcessing/<funcName>/<time> directory as a result of
either restart or run-time modification. Log files will therefore never
be overwritten by restart or run-time modification, except for when a
case is restarted at the same time as a previous execution (e.g.,
repeated runs at the start time).
The phase-change functionality in interPhaseChangeFoam has been generalised and
moved into the run-time selectable twoPhaseChange library included into
interFoam providing optional phase-change. The three cavitation models provided
in interPhaseChangeFoam are now included in the twoPhaseChange library and the
two interPhaseChangeFoam cavitation tutorials updated for interFoam.
interPhaseChangeFoam has been replaced by a user redirection script which prints
the following message:
The interPhaseChangeFoam solver has solver has been replaced by the more general
interFoam solver, which now supports phase-change using the new twoPhaseChange
models library.
To run with with phase-change create a constant/phaseChangeProperties dictionary
containing the phase-change model specification, e.g.
phaseChangeModel SchnerrSauer;
pSat 2300; // Saturation pressure
See the following cases for an example converted from interPhaseChangeFoam:
$FOAM_TUTORIALS/multiphase/interFoam/laminar/cavitatingBullet
$FOAM_TUTORIALS/multiphase/interFoam/RAS/propeller
Given that logFiles now writes the log files into postProcessing/<func
name>/<time> it is no longer useful to add '_<time>' to the log file name in the
case that the file already exists without this extension.
A dynamicMotionSolverFvMesh must now use a "motionSolver" or
"motionSolvers" entry to select the underlying motion solver. For
example, in constant/dynamicMeshDict:
dynamicFvMesh dynamicMotionSolverFvMesh;
motionSolverLibs ("librigidBodyMeshMotion.so");
motionSolver rigidBodyMotion;
...
Previously the motion solver could also be specified with the keyword
"solver", but this resulted in a name clash with rigid body solvers
which are frequently specified in the same scope. For this reason, the
"solver" and "solvers" entries have been removed.
End points of topoSet cylinder sources should now be specified as
"point1" and "point2", which is consistent with other parts of the code.
The previous keywords, "p1" and "p2" have been retained for backwards
compatibility but may be removed in future.
These allows for dictionary lookups which fall back to a different,
older keyword. Both lookup and lookup-or-default methods are provided;
lookupBackwardsCompatible and lookupOrDefaultBackwardsCompatible,
respectively.
A list of keywords are provided to these methods. The first is taken to
be the current preferred name of the entry, and subsequent elements are
considered to relate to older syntax. These keywords are tried in turn.
If nothing are found then any errors or messages printed relate to the
first keyword in the list.
This centralises backwards compatability logic and allows for current
backwards compatibility settings to be conveniently searched for.
Setting the 'mixtureDiffusionCoefficients' true the mass diffusion coefficient
functions with respect to the mixture 'Dm' are used directly but if set false
the binary mass diffusion coefficient functions 'D' are evaluated and mixed to
provide the mass diffusion with respect to the mixture, e.g.
Usage
\verbatim
laminar
{
model FickianFourier;
mixtureDiffusionCoefficients yes;
Dm // [m^2/s]
{
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
DT // [kg/m/s] Optional
{
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
}
\endverbatim
or if binary mass diffusion coefficient functions are available they can be
mixed to form the mass diffusion coefficients w.r.t. the mixture:
\verbatim
laminar
{
model FickianFourier;
mixtureDiffusionCoefficients no;
D // [m^2/s]
{
O2-O2 1e-2;
O3-O3 5e-2;
N2-N2 1e-2;
O3-O2 5e-2;
O3-N2 5e-2;
O2-N2 1e-2;
}
DT // [kg/m/s] Optional
{
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
}
\endverbatim
Description
Multi-component Maxwell Stefan generalized Fick's law diffusion coefficients
and Fourier based temperature gradient heat flux model with optional Soret
thermal diffusion of species for laminar flow.
The binary diffusion coefficients are specified as Function2<scalar>s of
pressure and temperature but independent of composition.
The heat flux source is implemented as an implicit energy correction to the
temperature gradient based flux source. At convergence the energy
correction is 0.
References:
\verbatim
Taylor, R., & Krishna, R. (1993).
Multicomponent mass transfer (Vol. 2).
John Wiley & Sons.
Merk, H. J. (1959).
The macroscopic equations for simultaneous heat and mass transfer
in isotropic, continuous and closed systems.
Applied Scientific Research,
Section A, 8(1), 73-99.
\endverbatim
Usage
\verbatim
laminar
{
model MaxwellStefanFourier;
D // [m^2/s]
{
O2_O2 1e-2;
O3_O3 5e-2;
N2_N2 1e-2;
O3_O2 5e-2;
O3_N2 5e-2;
O2_N2 1e-2;
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
DT // [kg/m/s] Optional
{
O2 1e-2;
O3 5e-2;
N2 1e-2;
}
}
\endverbatim
This change allows fvOptions to access and evaluate each other. This
means an option can be written that applies a source value proportional
to that in another option.
For example, you might have an fvOption specifying a mass source term in
the rhoEqn. You could now write a corresponding momentum source fvOption
which takes the velocity associated with that mass source as an input.
It would look up the mass source option to get the mass flow rate and
multiply it by the user supplied velocity to get the momentum source.
This prevents the user having to convert from the primitive variable
(e.g., velocity) to the conserved variable (e.g., momentum) when
specifying source terms.
Lookup is provided by means of a new [](const word&) operator on the
fvOptionList, and evaluation is achieved by adding ()(...) operators to
the fvOptions similar to those already available in the fvOptionList.
Example usage is shown below.
const fv::optionList& fvOptions(fv::options::New(mesh_));
const fv::option& fvOption = fvOptions[sourceName_]; // <-- Lookup
tmp<volScalarField> source(fvOption(field) & field); // <-- Evaluation
