Specialized variants of the power law porosity and k epsilon turbulence models
developed to simulate atmospheric flow over forested and non-forested complex
terrain.
Class
Foam::powerLawLopesdaCosta
Description
Variant of the power law porosity model with spatially varying
drag coefficient
given by:
\f[
S = -\rho C_d \Sigma |U|^{(C_1 - 1)} U
\f]
where
\vartable
\Sigma | Porosity surface area per unit volume
C_d | Model linear coefficient
C_1 | Model exponent coefficient
\endvartable
Reference:
\verbatim
Costa, J. C. P. L. D. (2007).
Atmospheric flow over forested and non-forested complex terrain.
\endverbatim
Class
Foam::RASModels::kEpsilonLopesdaCosta
Description
Variant of the standard k-epsilon turbulence model with additional source
terms to handle the changes in turbulence in porous regions represented by
the powerLawLopesdaCosta porosity model.
Reference:
\verbatim
Costa, J. C. P. L. D. (2007).
Atmospheric flow over forested and non-forested complex terrain.
\endverbatim
The default model coefficients are
\verbatim
kEpsilonLopesdaCostaCoeffs
{
Cmu 0.09;
C1 1.44;
C2 1.92;
sigmak 1.0;
sigmaEps 1.3;
}
\endverbatim
Tutorial case to follow.
In early versions of OpenFOAM the scalar limits were simple macro replacements and the
names were capitalized to indicate this. The scalar limits are now static
constants which is a huge improvement on the use of macros and for consistency
the names have been changed to camel-case to indicate this and improve
readability of the code:
GREAT -> great
ROOTGREAT -> rootGreat
VGREAT -> vGreat
ROOTVGREAT -> rootVGreat
SMALL -> small
ROOTSMALL -> rootSmall
VSMALL -> vSmall
ROOTVSMALL -> rootVSmall
The original capitalized are still currently supported but their use is
deprecated.
The ramp function used to graduate the vertical damping force can now be
applied along a number of paths, rather than just one. The keywords
"origins" and "directions" can be used to define a list of paths.
verticalDamping1
{
type verticalDamping;
origins ((1200 0 0) (1200 100 0) (1200 -100 0));
directions ((1 0 0) (0 1 0) (0 -1 0));
// ...
}
The ramping function will be calculated along each of the paths defined
by the origin-direction pair, and the maximum of the calculated values
will be used.
The "origin" and "direction" keywords can still be used with non-list
values.
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
The onset of vertical damping can now be graduated over a distance. The
user specifies an origin and a direction along which the graduation
occurs, and a ramping function to specify the form of the graduation. An
example specification for the fvOption is:
verticalDamping1
{
type verticalDamping;
selectionMode all;
origin (1200 0 0);
direction (1 0 0);
ramp
{
type halfCosineRamp;
start 0;
duration 600;
}
lambda [0 0 -1 0 0 0 0] 1; // Damping coefficient
timeStart 0;
duration 1e6;
}
If the origin, direction or ramp entries are omitted then the fvOption
functions as before; applying the damping to the entire volume or the
specified cell set.
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
The outletPhaseMeanVelocity and waveVelocity boundary conditions now
support a "ramp" keyword, for which a function can be supplied to
gradually increase the input velocity. The following is an example
specification for an outlet patch:
outlet
{
type outletPhaseMeanVelocity;
Umean 2;
ramp
{
type quarterSineRamp;
start 0;
duration 5;
}
alpha alpha.water;
}
There is also a new velocityRamping function object, which provides a
matching force within the volume of the domain, so that the entire flow
is smoothly accelerated up to the operating condition. An example
specification is as follows:
velocityRamping
{
type velocityRamping;
active on;
selectionMode all;
U U;
velocity (-2 0 0);
ramp
{
type quarterSineRamp;
start 0;
duration 5;
}
}
These additions have been designed to facilitate a smoother startup of
ship simulations by avoiding the slamming transients associated with
initialising a uniform velocity field.
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
This fvOption applies an explicit damping force to components of the
vector field in the direction of gravity. Its intended purpose is to
damp the vertical motions of an interface in the region approaching an
outlet so that no reflections are generated. The level of damping is
specified by a coefficient, lambda, given in units of 1/s.
It can be enabled for a cellZone named "nearOutlet", by adding the
following entry to constant/fvOptions:
verticalDamping1
{
type verticalDamping;
selectionMode cellZone;
cellZone nearOutlet;
lambda [0 0 -1 0 0 0 0] 1;
timeStart 0;
duration 1e6;
}
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
except turbulence and lagrangian which will also be updated shortly.
For example in the nonNewtonianIcoFoam offsetCylinder tutorial the viscosity
model coefficients may be specified in the corresponding "<type>Coeffs"
sub-dictionary:
transportModel CrossPowerLaw;
CrossPowerLawCoeffs
{
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
}
BirdCarreauCoeffs
{
nu0 [0 2 -1 0 0 0 0] 1e-06;
nuInf [0 2 -1 0 0 0 0] 1e-06;
k [0 0 1 0 0 0 0] 0;
n [0 0 0 0 0 0 0] 1;
}
which allows a quick change between models, or using the simpler
transportModel CrossPowerLaw;
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
if quick switching between models is not required.
To support this more convenient parameter specification the inconsistent
specification of seedSampleSet in the streamLine and wallBoundedStreamLine
functionObjects had to be corrected from
// Seeding method.
seedSampleSet uniform; //cloud; //triSurfaceMeshPointSet;
uniformCoeffs
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
to the simpler
// Seeding method.
seedSampleSet
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
which also support the "<type>Coeffs" form
// Seeding method.
seedSampleSet
{
type uniform;
uniformCoeffs
{
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
}
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.
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.
e.g. to avoid excessive unphysical velocities generated during slamming events in
incompressible VoF simulations
Usage
Example usage:
limitU
{
type limitVelocity;
active yes;
limitVelocityCoeffs
{
selectionMode all;
max 100;
}
}
Description
Constrain the field values within a specified region.
For example to set the turbulence properties within a porous region:
\verbatim
porosityTurbulence
{
type scalarFixedValueConstraint;
active yes;
scalarFixedValueConstraintCoeffs
{
selectionMode cellZone;
cellZone porosity;
fieldValues
{
k 30.7;
epsilon 1.5;
}
}
}
\endverbatim
See tutorials/compressible/rhoSimpleFoam/angledDuctExplicitFixedCoeff
constant/fvOptions for an example of this fvOption in action.
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.
Generally fields and objects are selected using the 'field[s]' and
'object[s]' keywords but this was not consistent between all
functionObject, fvOptions etc. and now fixed by applying the following
renaming:
fieldName -> field
fieldNames -> fields
objectName -> object
objectNames -> objects
to have the prefix 'write' rather than 'output'
So outputTime() -> writeTime()
but 'outputTime()' is still supported for backward-compatibility.
Also removed the redundant secondary-writing functionality from Time
which has been superseded by the 'writeRegisteredObject' functionObject.
Rather than requiring each functionObject to handle failed construction
internally (using the active_ flag) the static member function "viable"
is provided which returns true if construction of the functionObject is
likely to be successful. Failed construction is then handled by the
wrapper-class which constructs the functionObject,
e.g. "OutputFilterFunctionObject".
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.
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
When the GeometricBoundaryField template class was originally written it
was a separate class in the Foam namespace rather than a sub-class of
GeometricField as it is now. Without loss of clarity and simplifying
code which access the boundary field of GeometricFields it is better
that GeometricBoundaryField be renamed Boundary for consistency with the
new naming convention for the type of the dimensioned internal field:
Internal, see commit a25a449c9e
This is a very simple text substitution change which can be applied to
any code which compiles with the OpenFOAM-dev libraries.
