The functionality necessary to write in a different unit set has been
removed. This was excessivelty complex, never used in practice, and of
little practical usage. Output numeric data, in general, is not designed
to be conveniently user-readable, so it is not important what unit
system it is written in.
This can be used identically to a standard Function1. In addition, it
also permits specification of the dimensions. This allows the dimensions
to be checked. It also permits unit conversions. For example:
<name>
{
type table;
// Dimensions
xDimensions [CAD]; // Optional. Argument dimensions/units.
// Here, this specifies coordinates are in
// crank angle degrees (available if using
// engine time).
dimensions [mm]; // Optional. Value dimensions/units.
// Here, values are in mm.
// Tablulated data
values
(
(0 0)
(60 12) // <-- i.e., 12 mm at 60 degrees
(180 20)
(240 8)
(360 0)
);
outOfBounds repeat;
}
This replaces TimeFunction1, as it allows per-function control over
whether the function is considered to be one of real-time or user-time.
Description
Generates the weight for step-wise interpolation and integration
The step transitions are at the end of each interval.
The value returned by the Table::value function returns the value set for the
start of each interval within that interval and transitions abruptly to the next
interval value at the start of the next interval.
DecomposePar and reconstructPar now interleave the processing of
multiple regions. This means that with the -allRegions option, the
earlier times are completed in their entirety before later times are
considered. It also lets regions to access each other during
decomposition and reconstruction, which will be important for
non-conformal region interfaces.
To aid interpretation of the log, region prefixing is now used by both
utilities in the same way as is done by foamMultiRun.
DecomposePar has been overhauled so that it matches reconstructPar much
more closely, both in terms of output and of iteration sequence. All
meshes and addressing are loaded simultaneously and each field is
considered in turn. Previously, all the fields were loaded, and each
process and addressing set was considered in turn. This new strategy
optimises memory usage for cases with lots of fields.
The old fluid-specific rhoThermo has been split into a non-fluid
specific part which is still called rhoThermo, and a fluid-specific part
called rhoFluidThermo. The rhoThermo interface has been added to the
solidThermo model. This permits models and solvers that access the
density to operate on both solid and fluid thermophysical models.
The he*Thermo classes have been renamed to match their corresponding
basic thermo classes. E.g., rhoThermo now corresponds to RhoThermo,
rather than heRhoThermo.
Mixture classes (e.g., pureMixtrure, coefficientMulticomponentMixture),
now have no fvMesh or volScalarField dependence. They operate on
primitive values only. All the fvMesh-dependent functionality has been
moved into the base thermodynamic classes. The 'composition()' access
function has been removed from multi-component thermo models. Functions
that were once provided by composition base classes such as
basicSpecieMixture and basicCombustionMixture are now implemented
directly in the relevant multi-component thermo base class.
This simplifies the IOerror constructors and allows for the location to
be conveniently cached for errors that can't be triggered until after
the IO operation.
This prevents a crash when decomposing a time-series of topologically
varying meshes. This is not a common or advisable use case, but it is
natural to support it given the combinations of controls that are
available when performing decomposition.
at Function1s of time.
Underlying this new functionObject is a generalisation of the handling of the
maximum time-step in the modular solvers to allow complex user-specification of
the maximum time-step used in a simulation, not just the time-dependency
provided by fluidMaxDeltaT but functions of anything in the simulation by
creating a specialised functionObject in which the maxDeltaT function is
defined.
The chemical and combustion time-scale functionObjects adjustTimeStepToChemistry
and adjustTimeStepToCombustion have been updated and simplified using the above
mechanism.
The deltaTFactor used in the automatic time-step adjustment to smoothly increase
the time-step when permitted can now be specified in the system/controlDict but
defaults to 1.2 as used previously. For example in the
tutorials/incompressibleVoF/damBreak/damBreak case the rate at which the
time-step is increased after the slamming event can be reduced to 10% per
time-step by setting
.
.
.
maxDeltaT 1;
deltaTFactor 1.1;
Alternatively the case can be set to continue with the smallest time-step
without further adjustment by setting deltaTFactor to 1.
which calls the fvModel::write function which defaults to doing nothing but can
be overridden in derived fvModels to write useful state information at the end
of the write-times.
Description
Calculates and applies the random OU (Ornstein-Uhlenbeck) process force to
the momentum equation for direct numerical simulation of boxes of isotropic
turbulence.
The energy spectrum is calculated and written at write-times which is
particularly useful to test and compare LES SGS models.
Note
This random OU process force uses a FFT to generate the force field which
is not currently parallelised. Also the mesh the FFT is applied to must
be isotropic and have a power of 2 cells in each direction.
Usage
Example usage:
\verbatim
OUForce
{
type OUForce;
libs ("librandomProcesses.so");
sigma 0.090295;
alpha 0.81532;
kUpper 10;
kLower 7;
}
\endverbatim
The tutorials/incompressibleFluid/boxTurb16 tutorial case is an updated version
of the original tutorials/legacy/incompressible/dnsFoam/boxTurb16 case,
demonstrating the use of the OUForce fvModel with the incompressibleFluid solver
module to replicate the behaviour of the legacy dnsFoam solver application.
for the multiphaseEuler solver module, replacing the more specific
uniformFixedMultiphaseHeatFluxFvPatchScalarField as it provide equivalent
functionality if the heat-flux q is specified.
multiphaseExternalTemperatureFvPatchScalarField is derived from the refactored
and generalised externalTemperatureFvPatchScalarField, overriding the
getKappa member function to provide the multiphase equivalents of kappa and
other heat transfer properties. All controls for
multiphaseExternalTemperatureFvPatchScalarField are the same as for
externalTemperatureFvPatchScalarField:
Class
Foam::externalTemperatureFvPatchScalarField
Description
This boundary condition applies a heat flux condition to temperature
on an external wall. Heat flux can be specified in the following ways:
- Fixed power: requires \c Q
- Fixed heat flux: requires \c q
- Fixed heat transfer coefficient: requires \c h and \c Ta
where:
\vartable
Q | Power Function1 of time [W]
q | Heat flux Function1 of time [W/m^2]
h | Heat transfer coefficient Function1 of time [W/m^2/K]
Ta | Ambient temperature Function1 of time [K]
\endvartable
Only one of \c Q or \c q may be specified, if \c h and \c Ta are also
specified the corresponding heat-flux is added.
If the heat transfer coefficient \c h is specified an optional thin thermal
layer resistances can also be specified through thicknessLayers and
kappaLayers entries.
The patch thermal conductivity \c kappa is obtained from the region
thermophysicalTransportModel so that this boundary condition can be applied
directly to either fluid or solid regions.
Usage
\table
Property | Description | Required | Default value
Q | Power [W] | no |
q | Heat flux [W/m^2] | no |
h | Heat transfer coefficient [W/m^2/K] | no |
Ta | Ambient temperature [K] | if h is given |
thicknessLayers | Layer thicknesses [m] | no |
kappaLayers | Layer thermal conductivities [W/m/K] | no |
relaxation | Relaxation for the wall temperature | no | 1
emissivity | Surface emissivity for radiative flux to ambient | no | 0
qr | Name of the radiative field | no | none
qrRelaxation | Relaxation factor for radiative field | no | 1
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type externalTemperature;
Ta constant 300.0;
h uniform 10.0;
thicknessLayers (0.1 0.2 0.3 0.4);
kappaLayers (1 2 3 4);
value $internalField;
}
\endverbatim
See also
Foam::mixedFvPatchScalarField
Foam::Function1
The mappedValueFvPatchField boundary condition is special in that it can
construct its own mapping information if none is provided by the
underlying patch. This means different fields can be mapped between the
same patches with different mapping strategies. It is quite flexible,
and is often used for recyling properties between boundaries in order to
fully develop their profiles. It provides the ability to set the mean
and similar in order to facilitate this sort of usage.
It is not intended to be used in situations in which patches are
physically connected; region interfaces and similar. These connections
are required to be defined in the underlying patches themselves, as they
relate more fundamentally to the configuration of the mesh rather than
just the boundary conditions of specific fields.
Boundary conditions that map across physical connections (e.g.,
coupledTemperature, mappedFilmPressure, ...) are therefore required to
apply to a mapped patch. The mapping in these situations is a property
of the mesh, not of the boundary condition. If these conditions are
applied to a non-mapped patch then they will fail.
This change formalises the above logic and removes a now unnecessary
base class which was previously being used to share
mappedValueFvPatchField's mapping construction behaviour with other
boundary conditions.
The mappedValueAndPatchInternalValue condition has also been removed, as
this was only previously used in film, and has been replaced by simpler
and more usable options.
If the code string is delimited by '#{...#}' multiple lines and multiple code
statements can be used to generate the entry using 'os << ...;'. This is
equivalent to #codeStream but with a more compact syntax, e.g.
maxAngle 30;
nAngles 7;
Us #calc
const vector U($<vector>testCalc2!U);
const int nAngles = $nAngles;
const scalar angleStep = ($<scalar>maxAngle)/(nAngles - 1);
List<vector> Us(nAngles);
for(int i=0; i<nAngles; i++)
{
const scalar angle = degToRad(i*angleStep);
Us[i] = transform(Ry(angle), U);
}
os << Us;
Note the 'os << Us;' statement which writes the data to the dictionary entry in
the same manner as #codeStream, this provides flexibility on how the data is
created and written.
This allows #FOAM_CASE for example to be used in #calc variable lookup, e.g. in
test/dictionary/testCalc:
// assuming the testCalc2 file is local
magU #calc "mag($<vector>testCalc2!U)";
// finding the testCalc2 file using $FOAM_CASE
k #calc "1.5*magSqr(0.05*$<vector>{${FOAM_CASE}/testCalc2!U})";
