Commit Graph

10 Commits

Author SHA1 Message Date
7f5144312e Renamed turbulenceProperties -> momentumTransport
Following the generalisation of the TurbulenceModels library to support
non-Newtonian laminar flow including visco-elasticity and extensible to other
form of non-Newtonian behaviour the name TurbulenceModels is misleading and does
not properly represent how general the OpenFOAM solvers now are.  The
TurbulenceModels now provides an interface to momentum transport modelling in
general and the plan is to rename it MomentumTransportModels and in preparation
for this the turbulenceProperties dictionary has been renamed momentumTransport
to properly reflect its new more general purpose.

The old turbulenceProperties name is supported for backward-compatibility.
2020-04-10 17:17:37 +01:00
5eaf74c3a4 dictionary scalar lookup: simplified syntax using the type templated lookup function
Replaced
    readScalar(dict.lookup("name"))
with
    dict.lookup<scalar>("name")
2019-11-27 14:56:32 +00:00
bf54ab67e1 Updated OpenFOAM Foundation web-link in headers 2018-07-06 21:42:54 +01:00
e22c65dd8e Standardized the selection of required and optional fields in BCs, fvOptions, functionObjects etc.
In most boundary conditions, fvOptions etc. required and optional fields
to be looked-up from the objectRegistry are selected by setting the
keyword corresponding to the standard field name in the BC etc. to the
appropriate name in the objectRegistry.  Usually a default is provided
with sets the field name to the keyword name, e.g. in the
totalPressureFvPatchScalarField the velocity is selected by setting the
keyword 'U' to the appropriate name which defaults to 'U':

        Property     | Description             | Required    | Default value
        U            | velocity field name     | no          | U
        phi          | flux field name         | no          | phi
        .
        .
        .

However, in some BCs and functionObjects and many fvOptions another
convention is used in which the field name keyword is appended by 'Name'
e.g.

        Property     | Description             | Required    | Default value
        pName        | pressure field name     | no          | p
        UName        | velocity field name     | no          | U

This difference in convention is unnecessary and confusing, hinders code
and dictionary reuse and complicates code maintenance.  In this commit
the appended 'Name' is removed from the field selection keywords
standardizing OpenFOAM on the first convention above.
2016-05-21 20:28:20 +01:00
fe43b80536 GeometricField: Renamed internalField() -> primitiveField() and dimensionedInternalField() -> internalField()
These new names are more consistent and logical because:

primitiveField():
primitiveFieldRef():
    Provides low-level access to the Field<Type> (primitive field)
    without dimension or mesh-consistency checking.  This should only be
    used in the low-level functions where dimensional consistency is
    ensured by careful programming and computational efficiency is
    paramount.

internalField():
internalFieldRef():
    Provides access to the DimensionedField<Type, GeoMesh> of values on
    the internal mesh-type for which the GeometricField is defined and
    supports dimension and checking and mesh-consistency checking.
2016-04-30 21:40:09 +01:00
e1e996746b GeometricField::internalField() -> GeometricField::internalFieldRef()
Non-const access to the internal field now obtained from a specifically
named access function consistent with the new names for non-canst access
to the boundary field boundaryFieldRef() and dimensioned internal field
dimensionedInternalFieldRef().

See also commit a4e2afa4b3
2016-04-30 14:25:21 +01:00
61ba5f0268 Use basicThermo::dictName rather than hard-coding "thermophysicalProperties" 2015-06-24 10:44:57 +01:00
6cddfdda74 fvOptions: Rationalize naming convention for constraints 2015-06-01 09:58:33 +01:00
4c753e1e4c fvOption: Rationalize read to support re-reading
writeData is not yet completely consistent with read.
2015-05-31 17:14:32 +01:00
b8d15ba459 fvOptions: Separate options for all cells, cellSets and inter-region coupling
by introducing rational base-classes rather than using the hideous
'switch' statement.  Further rationalization of the cell-selection
mechanism will be implemented via an appropriate class hierarchy to
replace the remaining 'switch' statement.

Mesh-motion is currently handled very inefficiently for cellSets and not
at all for inter-region coupling.  The former will be improved when the
cell-selection classes are written and the latter by making the
meshToMesh class a MeshObject after it has been corrected for mapFields.
2015-05-31 16:38:01 +01:00