Description
Surface-normal fixed value vector boundary condition
in which the vector field is obtained by scaling the patch normals
by the evaluated scalar Function1 provided.
Usage
\table
Property | Description | Required | Default value
uniformValue | uniform value | yes |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type surfaceNormalUniformFixedValue;
uniformValue constant -0.2; // 0.2 INTO the domain
}
\endverbatim
Note
Sign conventions:
- the value is positive for outward-pointing vectors
Implementation of the Giesekus model for visco-elasticity, derived from the new
generalised form of the Maxwell model which now support additional sources.
Giesekus, H., 1982.
A simple constitutive equation for polymer fluids based on the
concept of deformation-dependent tensional mobility.
J. Non-Newton. Fluid. 11, 69–109.
This implementation is instantiated for incompressible, compressible and VoF
two-phase flow.
With the selection of the Boussinesq equation of state the general buoyancy
solvers buoyantSimpleFoam and buoyantPimpleFoam can be used instead of the
specialised Boussinesq solvers avoiding the need for special implementation of
thermal and pressure boundary conditions and providing support for radiation and
fvOptions which would not have been feasible or practical in the Boussinesq
solvers.
Other incompressible equations of state are also supported; for most gaseous
problems the incompressiblePerfectGas equation of state is likely to be more
accurate than the Boussinesq equation of state.
The buoyantBoussinesq[SP]impleFoam tutorials have been updated and moved to the
corresponding buoyant[SP]impleFoam directories.
In the latest generation of solvers supporting mesh-motion using Uf to correct
phi it is no longer necessary to correct the velocity field boundary conditions
directly following mesh motion so the "velocityFields" input list in
dynamicMeshDict is optional and only provided to support legacy "DyM" solvers
and defaults to an empty list.
The base dynamicFvMesh now reads and stores the dynamicMeshDict and motion
solver receive it as a constructor argument.
Also rationalised the motionSolver diffusivity classes in which storing the
faceDiffusivity field provided no advantage; now it is created and returned on
demand.
This switch should be on for phi-correction within the time loop, where
the correction simply serves to keep the phi-field up to date before the
U-equation is solved. It should be off for initialisation
phi-correction, as the necessary data to update the conditions may not
yet exist.
Resolves bug report https://bugs.openfoam.org/view.php?id=3198
The dense drag models (WenYu, ErgunWenYu and PlessisMasliyah) have been
extended so that they can create their own void-fraction field when one
is not otherwise available.
The duplicated functionality in the drag models has been generalised and
is now utilised by multiple models.
References have been added for all models for which they could be found.
In addition, an additional drag model, SchillerNaumann, has been added.
This is of the same form as sphereDrag, and is designed for the same
scenario; sparsely distributed spherical particles. The SchillerNaumann
form is more widely referenced and should now be considered standard.
The thermo-parcel-specific force instantiation macro has been removed,
as all the force models are now possible to use with all parcel types.
Resolves bug report https://bugs.openfoam.org/view.php?id=3191
The writeEntry form is now defined and used consistently throughout OpenFOAM
making it easier to use and extend, particularly to support binary IO of complex
dictionary entries.
The moving-mesh tracking algorithm needs the cell-centres at the
previous time-step. These were not originally stored by the polyMesh, so
they were being generated on-the-fly. In some tracking-dominated cases
this caused an unacceptable overhead.
The polyMesh now stores the old-time cell-centres on demand. They are
not stored by default (like the old-time points), so if they are needed
then the accessor should be called before any mesh motion. Typically
this will be during construction of whatever functionality requires it.
See Cloud.C for an example.
The logic for storage and update of the old-time points has also been
improved to account for the possibility of the mesh motion coming to an
end.
It is the rigidBody equivalent of the sixDoFRigidBodyState functionObject.
Example of function object specification:
rigidBodyState
{
type rigidBodyState;
libs ("librigidBodyState.so");
angleFormat degrees;
}
Based on patch contributed by SeongMo Yeon
Resolves patch request https://bugs.openfoam.org/view.php?id=3180
This cloud function object will write out a lagrangian field of the
relative velocity between the parcels and the surrounding fluid. It
does not have any additional controls.
Now uses previous valueFraction and refValue values rather than the previous
boundary temperature for relaxation.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3175
The current Courant number limited formulation is preferable for cases running
with VERY small Courant numbers but there are stability issues with it on some
cases for which the previous flux-normalised scheme worked well. Overall the
previous scheme has proved more reliable and fvcDdtPhiCoeff has been reverted to
it pending further research and development in this area which will require
funding:
https://openfoam.org/news/funding-2019/https://openfoam.org/maintenance/
