After direct and regular expression matching the scheme name is now filtered to
remove and group/phase extensions in the name and matched again with the schemes
dictionary.
This significantly simplifies the specification of schemes in multiphase
simulations, instead of the rather messy regular expressions the new method
allows schemes to be specified without the group/phase name extension and the
scheme is then used for all groups/phases. For example in the bubbleColumn
tutorials the schemes can now be specified thus:
divSchemes
{
default none;
div(phi,alpha) Gauss vanLeer;
div(phir,alpha,alpha) Gauss vanLeer;
div(alphaRhoPhi,U) Gauss limitedLinearV 1;
div(phi,U) Gauss limitedLinearV 1;
div(alphaRhoPhi,e) Gauss limitedLinear 1;
div(alphaRhoPhi,K) Gauss limitedLinear 1;
div(alphaRhoPhi,(p|rho)) Gauss limitedLinear 1;
div((((alpha*rho)*nuEff)*dev2(T(grad(U))))) Gauss linear;
}
rather than using complex regular expressions as done previously:
divSchemes
{
default none;
div(phi,alpha.air) Gauss vanLeer;
div(phi,alpha.water) Gauss vanLeer;
div(phir,alpha.water,alpha.air) Gauss vanLeer;
div(phir,alpha.air,alpha.water) Gauss vanLeer;
"div\(alphaRhoPhi.*,U.*\)" Gauss limitedLinearV 1;
"div\(phi.*,U.*\)" Gauss limitedLinearV 1;
"div\(alphaRhoPhi.*,(h|e).*\)" Gauss limitedLinear 1;
"div\(alphaRhoPhi.*,K.*\)" Gauss limitedLinear 1;
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
"div\(\(\(\(alpha.*\*rho.*\)*nuEff.*\)\*dev2\(T\(grad\(U.*\)\)\)\)\)" Gauss linear;
}
Now that thermal transport is implemented as an energy implicit correction on an
explicit temperature gradient formulation it is more efficient if the implicit
correction contains only the implicit terms of the matrix and not the explicit
non-orthogonal or anisotropic correction terms which are cancelled anyway when
the evaluation of the matrix for the current state is subtracted. The new
fvm::laplacianCorrection functions provide a convenient mechanism to efficiently
evaluate only the implicit correction to the laplacian and is now used in all
the thermophysicalTransportModels.
Now that kappa, Cp and Cv fields are cached and Cpv returns either the Cp or Cv
field reference depending on the energy solved and thermal transport is now
fundamentally based on temperature rather energy gradients it is no longer
necessary or useful to provide an abstract function returning alphahe.
This renaming only occurs for single-phase compressible solvers instantiating a
rhoThermo, e.g. for liquids, and usually the rhoThermo:rho is not looked-up by
sub-models or boundary conditions and if needed is better obtained from the
thermo package directly.
The thermodynamic density field is now named "rho" by default and only renamed
"thermo:rho" by solvers that create and maintain a separate continuity density
field which is named "rho". This change significantly simplifies and
standardises the specification of schemes and boundary conditions requiring
density as it is now always named "rho" or "rho.<phase>" unless under some very
unusual circumstances the thermodynamic rather than continuity density is
required for a solver maintaining both.
The advantage of this change is particularly noticeable for multiphase
simulations in which each phase has its own density now named "rho.<phase>"
rather than "thermo:rho.<phase>" as separate phase continuity density fields are
not required so for multiphaseEulerFoam the scheme specification:
"div\(alphaRhoPhi.*,\(p\|thermo:rho.*\)\)" Gauss limitedLinear 1;
is now written:
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
The basic thermophysical properties are now considered fundamental and complex
models like kineticTheoryModel using these names for some other purpose must
disambiguate using typedName to prepend the model name to the field name.
This change standardises, rationalises and simplifies the specification of
fvSchemes and boundary conditions.
thermo:rho will also be renamed rho in a subsequent commit to complete this
rationalisation.
in particular to support setting constant property fields in the constant
directory.
Usage: setFields [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-fileHandler <handler>
override the fileHandler
-hostRoots <((host1 dir1) .. (hostN dirN))>
slave root directories (per host) for distributed running
-latestTime select the latest time
-libs '("lib1.so" ... "libN.so")'
pre-load libraries
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list
-parallel run in parallel
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <time> specify a single time value to select
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
Description
Uniform or non-uniform constant solid thermodynamic properties
Each physical property can specified as either \c uniform in which case the
value entry is read or \c file in which case the field file in read
from the constant directory.
Usage
Example of uniform constant solid properties specification:
\verbatim
thermoType constSolidThermo;
rho
{
type uniform;
value 8940;
}
Cv
{
type uniform;
value 385;
}
kappa
{
type uniform;
value 380;
}
\endverbatim
Example of non-uniform constant solid properties specification:
\verbatim
thermoType constSolidThermo;
rho
{
type file;
}
Cv
{
type file;
}
kappa
{
type file;
}
\endverbatim
where each of the field files are read from the constant directory.
to handle the wall heat-flux generated by the tangential components of the
temperature gradient when the thermal conductivity tensor Kappa does not align
with the boundary. This is an uncommon situation but for cases where it is
important it must be handled correctly; previously this term was ignored.
For efficiency the temperature gradient field is automatically cached so that it
is not evaluated for every patch for which Kappa is not aligned with the
boundary, and the correction is evaluated and applied only for those patches.
The heat-flux correction qCorr is used in the coupled and external heat-flux
boundary conditions coupledTemperature and externalTemperature.
the new fluidThermophysicalTransportModel and solidThermophysicalTransportModel
are derived from thermophysicalTransportModel providing a consistent and unified
interface for heat transport within and between regions. Coupled and external
heat-transfer boundary conditions can now be written independent of the
thermophysical properties or transport modelling of the regions providing
greater flexibility, simpler code and reduces the maintenance overhead.
The previous fluidThermophysicalTransportModel typedef has been renamed
fluidThermoThermophysicalTransportModel as it is instantiated on fluidThermo,
freeing the name fluidThermophysicalTransportModel for the new base-class.
so that derived classes can call the dictionary constructor without reading the
refValue, refGradient or valueFraction entries. This ensures that the
fvPatchField dictionary constructor is called, setting optional entries like
'libs' as required.
Patch fields on cyclic patches which have overridden the cyclic
constraint using a "patchType cyclic;" setting cannot be decomposed.
OpenFOAM does not have processor variants of jumpCyclic,
porousBafflePressure, etc... Using these conditions in a decomposed case
requires the cyclic to be constrained to a single processor.
This change catches this problem in decomposePar and reconstructPar and
raises a fatal error, rather than continuing and silently converting
these overridden boundary conditions to a standard processorCyclic patch
field.
Resolves bug report https://bugs.openfoam.org/view.php?id=3916
The surfaceFilm fvModel has been renamed surfaceFilms, and can now have
a number of independent film models specified.
For example, the hotBoxes tutorial could be modified to have separate
film regions for the boxes and for the floor. In which case, the names
of the separate films would need specifying as shown below.
surfaceFilms
{
type surfaceFilms;
surfaceFilms (boxesFilm floorFilm); // <-- new entry
libs ("libsurfaceFilmModels.so");
}
The old fvModel name, surfaceFilm, has been maintained for backwards
compatibility.
The Lagrangian surface film model now also requires the coupled
surfaceFilms to be specified when there is not just a single
default-named film. For example, in constant/cloudProperties:
subModels
{
surfaceFilmModel thermoSurfaceFilm;
thermoSurfaceFilmCoeffs
{
surfaceFilms (boxesFilm floorFilm); // <-- new entry
interactionType splashBai;
deltaWet 0.0005;
Adry 2630;
Awet 1320;
Cf 0.6;
}
...
}
This change resolves a mass-conservation issue caused by the handling of
absolute and relative fluxes in the construction of the transonic pressure
equation.
to handle isotropic and anisotropic is a consistent, general and extensible
manner, replacing the horrible hacks which were in solidThermo.
This is entirely consistent with thermophysicalTransportModel for fluids and
provides the q() and divq() for the solid energy conservation equations. The
transport model and properties are specified in the optional
thermophysicalTransport dictionary, the default model being isotropic if this
dictionary file is not present, thus providing complete backward-compatibility
for the common isotropic cases.
Anisotropic thermal conductivity is now handled in a much more general manner by
the anisotropic model:
Class
Foam::solidThermophysicalTransportModels::anisotropic
Description
Solid thermophysical transport model for anisotropic thermal conductivity
The anisotropic thermal conductivity field is evaluated from the solid
material anisotropic kappa specified in the physicalProperties dictionary
transformed into the global coordinate system using default
coordinate system and optionally additional coordinate systems specified
per-zone in the thermophysicalProperties dictionary.
Usage
Example of the anisotropic thermal conductivity specification in
thermophysicalProperties with two zone-based coordinate systems in
addition to the default:
\verbatim
model anisotropic;
// Default coordinate system
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type cylindrical;
e3 (1 0 0);
}
}
// Optional zone coordinate systems
zones
{
coil1
{
type cartesian;
origin (0.1 0.2 0.7);
coordinateRotation
{
type cylindrical;
e3 (0.5 0.866 0);
}
}
coil2
{
type cartesian;
origin (0.4 0.5 1);
coordinateRotation
{
type cylindrical;
e3 (0.866 0.5 0);
}
}
}
\endverbatim
This development required substantial rationalisation of solidThermo,
coordinateSystems and updates to the solid solver module, solidDisplacementFoam,
the wallHeatFlux functionObject, thermalBaffle and all coupled thermal boundary
conditions.
to enable writing of the isotropicDamping:forceCoeff isotropicDamping:scale
waveForcing:forceCoeff waveForcing:scale diagnostic fields to check the damping
and forcing distributions.
token: Changed parseError to use cerr rather than FatalIOError so that it can
report errors when reading debug switches from the case controlDict at start-up.
The tolerance used for geometric checking and transformation calculation
between mapped patches can now be set per patch by the user. A
"matchTolerance" setting can be specified in the mapped patches'
dictionaries in the "polyMesh/boundary" file. The default remains 1e-4.
This is exactly the same control as is used for cyclic patches.
The error message that is generated when the geometric check fails has
also been improved to provide better information and more explicit
instruction as to how to resolve the problem.
Lagrangian is now compatible with the meshToMesh topology changer. If a
cloud is being simulated and this topology changer is active, then the
cloud data will be automatically mapped between the specified sequence
of meshes in the same way as the finite volume data. This works both for
serial and parallel simulations.
In addition, mapFieldsPar now also supports mapping of Lagrangian data
when run in parallel.
This is a basic fix to account for changes in the structure of
non-conformal patches. It does not fix the issue that the cloud
functions do not have any mesh change hooks and do not, therefore,
support mesh changes in general. Compatibility with topology change,
mesh mapping and distribution would require substantial additional work.
