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.
so that the specification of time-step and write-interval are in user-time,
consistent with the controlDict.
Class
Foam::functionObjects::setTimeStepFunctionObject
Description
Updates the time step as a Function1 of time.
If the case is running with userTime specified in controlDict then the
time-step values returned by the Function1 are assumed to be in user-time
rather than real-time.
Class
Foam::functionObjects::setWriteIntervalFunctionObject
Description
Updates the writeInterval as a Function1 of time.
If the case is running with userTime specified in controlDict then the write
interval values returned by the Function1 are assumed to be in user-time
rather than real-time.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3904
Function objects now write to the following path when applied to a
non-default region of a multi-region case:
postProcessing/<regionName>/<functionName>/<time>/
Previously the order of <regionName> and <functionName> was not
consistent between the various function objects.
Resolves bug report https://bugs.openfoam.org/view.php?id=3907
Renamed classes:
turbulentTemperatureCoupledBaffleMixedFvPatchScalarField ->
coupledTemperatureFvPatchScalarField
externalWallHeatFluxTemperatureFvPatchScalarField ->
externalTemperatureFvPatchScalarField
Radiation heat-flux support in turbulentTemperatureRadCoupledMixed transferred
to coupledTemperatureFvPatchScalarField and turbulentTemperatureRadCoupledMixed removed.
Renamed boundary condition type names in T field files:
compressible::turbulentTemperatureCoupledBaffleMixed -> coupledTemperature
compressible::turbulentTemperatureRadCoupledMixed -> coupledTemperature
compressible::externalWallHeatFluxTemperature -> externalTemperature
Backward-compatibility is provided for all three of the above BC specifications
so existing cases will run as before but we recommend migrating to the new
simpler names.
so that it can now be used with either the isothermalFluid or fluid solver
modules, thus supporting non-uniform fluid properties, compressibility and
thermal effect. This development makes the special potentialFreeSurfaceFoam
solver redundant as both the isothermalFluid and fluid solver modules are more
general and has been removed and replaced with a user redirection script.
The tutorials/multiphase/potentialFreeSurfaceFoam cases have been updated to run
with the isothermalFluid solver module:
tutorials/multiphase/potentialFreeSurfaceFoam/oscillatingBox
tutorials/multiphase/potentialFreeSurfaceFoam/movingOscillatingBox
which demonstrate how to upgrade potentialFreeSurfaceFoam cases to
isothermalFluid.
