- list all regions from constant/regionProperties:
* foamListRegions
- list specific region type from constant/regionProperties:
* foamListRegions fluid
* foamListRegions solid
Within decomposeParDict, it is now possible to specify a different
decomposition method, methods coefficients or number of subdomains
for each region individually.
The top-level numberOfSubdomains remains mandatory, since this
specifies the number of domains for the entire simulation.
The individual regions may use the same number or fewer domains.
Any optional method coefficients can be specified in a general
"coeffs" entry or a method-specific one, eg "metisCoeffs".
For multiLevel, only the method-specific "multiLevelCoeffs" dictionary
is used, and is also mandatory.
----
ENH: shortcut specification for multiLevel.
In addition to the longer dictionary form, it is also possible to
use a shorter notation for multiLevel decomposition when the same
decomposition method applies to each level.
- Instead of relying on #inputMode to effect a global change it is now
possible (and recommended) to a temporary change in the inputMode
for the following entry.
#default : provide default value if entry is not already defined
#overwrite : silently remove a previously existing entry
#warn : warn about duplicate entries
#error : error if any duplicate entries occur
#merge : merge sub-dictionaries when possible (the default mode)
This is generally less cumbersome than the switching the global
inputMode. For example to provide a set of fallback values.
#includeIfPresent "user-files"
...
#default value uniform 10;
vs.
#includeIfPresent "user-files"
#inputMode protect
...
value uniform 10;
#inputMode merge // _Assuming_ we actually had this before
These directives can also be used to suppress the normal dictionary
merge semantics:
#overwrite dict { entry val; ... }
Original commit message:
------------------------
Parallel IO: New collated file format
When an OpenFOAM simulation runs in parallel, the data for decomposed fields and
mesh(es) has historically been stored in multiple files within separate
directories for each processor. Processor directories are named 'processorN',
where N is the processor number.
This commit introduces an alternative "collated" file format where the data for
each decomposed field (and mesh) is collated into a single file, which is
written and read on the master processor. The files are stored in a single
directory named 'processors'.
The new format produces significantly fewer files - one per field, instead of N
per field. For large parallel cases, this avoids the restriction on the number
of open files imposed by the operating system limits.
The file writing can be threaded allowing the simulation to continue running
while the data is being written to file. NFS (Network File System) is not
needed when using the the collated format and additionally, there is an option
to run without NFS with the original uncollated approach, known as
"masterUncollated".
The controls for the file handling are in the OptimisationSwitches of
etc/controlDict:
OptimisationSwitches
{
...
//- Parallel IO file handler
// uncollated (default), collated or masterUncollated
fileHandler uncollated;
//- collated: thread buffer size for queued file writes.
// If set to 0 or not sufficient for the file size threading is not used.
// Default: 2e9
maxThreadFileBufferSize 2e9;
//- masterUncollated: non-blocking buffer size.
// If the file exceeds this buffer size scheduled transfer is used.
// Default: 2e9
maxMasterFileBufferSize 2e9;
}
When using the collated file handling, memory is allocated for the data in the
thread. maxThreadFileBufferSize sets the maximum size of memory in bytes that
is allocated. If the data exceeds this size, the write does not use threading.
When using the masterUncollated file handling, non-blocking MPI communication
requires a sufficiently large memory buffer on the master node.
maxMasterFileBufferSize sets the maximum size in bytes of the buffer. If the
data exceeds this size, the system uses scheduled communication.
The installation defaults for the fileHandler choice, maxThreadFileBufferSize
and maxMasterFileBufferSize (set in etc/controlDict) can be over-ridden within
the case controlDict file, like other parameters. Additionally the fileHandler
can be set by:
- the "-fileHandler" command line argument;
- a FOAM_FILEHANDLER environment variable.
A foamFormatConvert utility allows users to convert files between the collated
and uncollated formats, e.g.
mpirun -np 2 foamFormatConvert -parallel -fileHandler uncollated
An example case demonstrating the file handling methods is provided in:
$FOAM_TUTORIALS/IO/fileHandling
The work was undertaken by Mattijs Janssens, in collaboration with Henry Weller.
- although this has been supported for many years, the tutorials
continued to use "convertToMeters" entry, which is specific to blockMesh.
The "scale" is more consistent with other dictionaries.
ENH:
- ignore "scale 0;" (treat as no scaling) for blockMeshDict,
consistent with use elsewhere.
- Use on/off vs longer compressed/uncompressed.
For consistency, replaced yes/no with on/off.
- Avoid the combination of binary/compressed,
which is disallowed and provokes a warning anyhow
Evolves an electrical potential equation
\f[
\grad \left( \sigma \grad V \right)
\f]
where \f$ V \f$ is electrical potential and \f$\sigma\f$ is the
electrical current
To provide a Joule heating contribution according to:
Differential form of Joule heating - power per unit volume:
\f[
\frac{d(P)}{d(V)} = J \cdot E
\f]
where \f$ J \f$ is the current density and \f$ E \f$ the electric
field.
If no magnetic field is present:
\f[
J = \sigma E
\f]
The electric field given by
\f[
E = \grad V
\f]
Therefore:
\f[
\frac{d(P)}{d(V)} = J \cdot E
= (sigma E) \cdot E
= (sigma \grad V) \cdot \grad V
\f]
Usage
Isotropic (scalar) electrical conductivity
\verbatim
jouleHeatingSourceCoeffs
{
anisotropicElectricalConductivity no;
// Optionally specify the conductivity as a function of
// temperature
// Note: if not supplied, this will be read from the time
// directory
sigma table
(
(273 1e5)
(1000 1e5)
);
}
\endverbatim
Anisotropic (vectorial) electrical conductivity
jouleHeatingSourceCoeffs
{
anisotropicElectricalConductivity yes;
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (1 0 0);
e3 (0 0 1);
}
}
// Optionally specify sigma as a function of temperature
//sigma (31900 63800 127600);
//
//sigma table
//(
// (0 (0 0 0))
// (1000 (127600 127600 127600))
//);
}
Where:
\table
Property | Description | Required | Default
value
T | Name of temperature field | no | T
sigma | Electrical conductivity as a function of
temperature |no|
anisotropicElectricalConductivity | Anisotropic flag | yes |
\endtable
The electrical conductivity can be specified using either:
- If the \c sigma entry is present the electrical conductivity is
specified
as a function of temperature using a Function1 type
- If not present the sigma field will be read from file
- If the anisotropicElectricalConductivity flag is set to 'true',
sigma
should be specified as a vector quantity
For example the actuationDiskSource fvOption may now be specified
disk1
{
type actuationDiskSource;
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
rather than
disk1
{
type actuationDiskSource;
active on;
actuationDiskSourceCoeffs
{
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
}
but this form is supported for backward compatibility.
The standard naming convention for heat flux is "q" and this is used for the
conductive and convective heat fluxes is OpenFOAM. The use of "Qr" for
radiative heat flux is an anomaly which causes confusion, particularly for
boundary conditions in which "Q" is used to denote power in Watts. The name of
the radiative heat flux has now been corrected to "qr" and all models, boundary
conditions and tutorials updated.
The fundamental properties provided by the specie class hierarchy were
mole-based, i.e. provide the properties per mole whereas the fundamental
properties provided by the liquidProperties and solidProperties classes are
mass-based, i.e. per unit mass. This inconsistency made it impossible to
instantiate the thermodynamics packages (rhoThermo, psiThermo) used by the FV
transport solvers on liquidProperties. In order to combine VoF with film and/or
Lagrangian models it is essential that the physical propertied of the three
representations of the liquid are consistent which means that it is necessary to
instantiate the thermodynamics packages on liquidProperties. This requires
either liquidProperties to be rewritten mole-based or the specie classes to be
rewritten mass-based. Given that most of OpenFOAM solvers operate
mass-based (solve for mass-fractions and provide mass-fractions to sub-models it
is more consistent and efficient if the low-level thermodynamics is also
mass-based.
This commit includes all of the changes necessary for all of the thermodynamics
in OpenFOAM to operate mass-based and supports the instantiation of
thermodynamics packages on liquidProperties.
Note that most users, developers and contributors to OpenFOAM will not notice
any difference in the operation of the code except that the confusing
nMoles 1;
entries in the thermophysicalProperties files are no longer needed or used and
have been removed in this commet. The only substantial change to the internals
is that species thermodynamics are now "mixed" with mass rather than mole
fractions. This is more convenient except for defining reaction equilibrium
thermodynamics for which the molar rather than mass composition is usually know.
The consequence of this can be seen in the adiabaticFlameT, equilibriumCO and
equilibriumFlameT utilities in which the species thermodynamics are
pre-multiplied by their molecular mass to effectively convert them to mole-basis
to simplify the definition of the reaction equilibrium thermodynamics, e.g. in
equilibriumCO
// Reactants (mole-based)
thermo FUEL(thermoData.subDict(fuelName)); FUEL *= FUEL.W();
// Oxidant (mole-based)
thermo O2(thermoData.subDict("O2")); O2 *= O2.W();
thermo N2(thermoData.subDict("N2")); N2 *= N2.W();
// Intermediates (mole-based)
thermo H2(thermoData.subDict("H2")); H2 *= H2.W();
// Products (mole-based)
thermo CO2(thermoData.subDict("CO2")); CO2 *= CO2.W();
thermo H2O(thermoData.subDict("H2O")); H2O *= H2O.W();
thermo CO(thermoData.subDict("CO")); CO *= CO.W();
// Product dissociation reactions
thermo CO2BreakUp
(
CO2 == CO + 0.5*O2
);
thermo H2OBreakUp
(
H2O == H2 + 0.5*O2
);
Please report any problems with this substantial but necessary rewrite of the
thermodynamic at https://bugs.openfoam.org
Henry G. Weller
CFD Direct Ltd.
e.g. in tutorials/heatTransfer/buoyantSimpleFoam/externalCoupledCavity/0/T
hot
{
type externalCoupledTemperature;
commsDir "${FOAM_CASE}/comms";
file "data";
initByExternal yes;
log true;
value uniform 307.75; // 34.6 degC
}
Previously both 'file' and 'fileName' were used inconsistently in different
classes and given that there is no confusion or ambiguity introduced by using
the simpler 'file' rather than 'fileName' this change simplifies the use and
maintenance of OpenFOAM.
Bounding thermo.rho in rhoPorousSimpleFoam.
Changing initial time step in externalSolarLoad tutorial.
Commenting out momemtun source term in steamInjection which causes problems
