The previous implementation was dimensionally inconsistent and was
missing a factor of the VbyA field. This change will, in most cases,
reduce the total impingement pressure contribution.
Now with the addition of the optional dependenciesModified() function classes
which depend on other classes which are re-read from file when modified are also
automatically updated via their read() function called by
objectRegistry::readModifiedObjects.
This significantly simplifies the update of the solutionControls and modular
solvers when either the controlDict or fvSolution dictionaries are modified at
run-time.
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 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 libs entry is not provided and the name of the library containing the
functionObject, fvModel or fvConstraint corresponds to the type specified the
corresponding library is automatically loaded, e.g. to apply the
VoFTurbulenceDamping fvModel to an incompressibleVoF simulation the following
will load the libVoFTurbulenceDamping.so library automatically and instantiate
the fvModel:
turbulenceDamping
{
type VoFTurbulenceDamping;
delta 1e-4;
}
This avoids potential hidden run-time errors caused by solvers running with
boundary conditions which are not fully specified. Note that "null-constructor"
here means the constructor from patch and internal field only, no data is
provided.
Constraint and simple BCs such as 'calculated', 'zeroGradient' and others which
do not require user input to fully specify their operation remain on the
null-constructor table for the construction of fields with for example all
'calculated' or all 'zeroGradient' BCs.
A special version of the 'inletOutlet' fvPatchField named 'zeroInletOutlet' has
been added in which the inlet value is hard-coded to zero which allows this BC
to be included on the null-constructor table. This is useful for the 'age'
functionObject to avoid the need to provide the 'age' volScalarField at time 0
unless special inlet or outlet BCs are required. Also for isothermalFilm in
which the 'alpha' field is created automatically from the 'delta' field if it is
not present and can inherit 'zeroInletOutlet' from 'delta' if appropriate. If a
specific 'inletValue' is require or other more complex BCs then the 'alpha'
field file must be provided to specify these BCs as before.
Following this improvement it will now be possible to remove the
null-constructors from all fvPatchFields not added to the null-constructor
table, which is most of them, thus reducing the amount of code and maintenance
overhead and making easier and more obvious to write new fvPatchField types.
