The "Refresh Times" button now triggers a re-render of the visualisation
as well as scanning for new times and fields. This prevents old
overwritten data from remaining on screen despite everything else having
been updated.
ParaView has been updated to version 5.4.0. The C++ panel has been
deleted and replaced with a panel based on the new(er) XML API. This
reader works for ParaView-4.0.1 and newer. The ParaView 3 reader remains
unchanged.
Update issues have also been fixed. All the time directories are now
scanned for fields and clouds when filling the selection lists. This
stops fields from disappearing when the time is changed. The scan is
only done on startup and when the refresh button is pressed.
The list of available Lagrangian fields also now shows a combined set of
all the clouds. Previously, only fields from the first cloud were shown.
If a field does not apply to all the clouds, ParaView will display it's
name in the dropdown menu with a "(partial)" qualifier.
Some undocumented and incomplete bits of code, which were not being
compiled, have been removed.
Tracking through an inverted region of the mesh happens in a reversed
direction relative to a non-inverted region. Usually, this allows the
tracking to propagate normally, regardless of the sign of the space.
However, in rare cases, it is possible for a straight trajectory to form
a closed loop through both positive and negative regions. This causes
the tracking to loop indefinitely.
To fix this, the displacement through inverted regions has been
artifically increased by a small amount (1% at the moment). This has the
effect that the change in track fraction over the negative part of the
loop no longer exactly cancels the change over the positive part, and
the track therefore terminates.
The KinematicCloud::patchData method has been made consistent on moving
meshes and/or when the time-step is being sub-cycled.
It has also been altered to calculate the normal component of a moving
patch's velocity directly from the point motions. This prevents an
infinite loop occuring due to inconsistency between the velocity used to
calculate a rebound and that used when tracking.
Some minor style improvements to the particle class have also been made.
Currently heat is assumed to be removed by heat-transfer to the wall so the
energy remains unchanged by the phase-change. This approximation can only be
removed if the interface to the transfer models is extended to support transfers
to and from the film AND the primary region.
The particle collector was collecting some particles twice due to a
tolerance extending the tracked path. This has been removed. The new
tracking algorithm does not generate the same sorts of spurious
tolerance-scale motions that the old one did, so this extension of the
tracking path is unnecessary.
Some particles were also not being collected at all as they were hitting
a diagonal of the collection polygon and registering as not having hit
either of the adjacent triangles. The hit criteria has been rewritten. A
hit now occurs when the normals of the triangles created by joining the
intersection point with the polygon edges are all in the same direction
as the overall polygon normal. This calculation is not affected by the
polygon's diagonals.
The issue was raised by, and resolved with support from, Karl Meredith
at FM Global.
This resolves bug-report https://bugs.openfoam.org/view.php?id=2595
When an OpenFOAM simulation runs in parallel, the data for decomposed fields and
mesh(es) has historically been stored in multiple files within separate
directories for each processor. Processor directories are named 'processorN',
where N is the processor number.
This commit introduces an alternative "collated" file format where the data for
each decomposed field (and mesh) is collated into a single file, which is
written and read on the master processor. The files are stored in a single
directory named 'processors'.
The new format produces significantly fewer files - one per field, instead of N
per field. For large parallel cases, this avoids the restriction on the number
of open files imposed by the operating system limits.
The file writing can be threaded allowing the simulation to continue running
while the data is being written to file. NFS (Network File System) is not
needed when using the the collated format and additionally, there is an option
to run without NFS with the original uncollated approach, known as
"masterUncollated".
The controls for the file handling are in the OptimisationSwitches of
etc/controlDict:
OptimisationSwitches
{
...
//- Parallel IO file handler
// uncollated (default), collated or masterUncollated
fileHandler uncollated;
//- collated: thread buffer size for queued file writes.
// If set to 0 or not sufficient for the file size threading is not used.
// Default: 2e9
maxThreadFileBufferSize 2e9;
//- masterUncollated: non-blocking buffer size.
// If the file exceeds this buffer size scheduled transfer is used.
// Default: 2e9
maxMasterFileBufferSize 2e9;
}
When using the collated file handling, memory is allocated for the data in the
thread. maxThreadFileBufferSize sets the maximum size of memory in bytes that
is allocated. If the data exceeds this size, the write does not use threading.
When using the masterUncollated file handling, non-blocking MPI communication
requires a sufficiently large memory buffer on the master node.
maxMasterFileBufferSize sets the maximum size in bytes of the buffer. If the
data exceeds this size, the system uses scheduled communication.
The installation defaults for the fileHandler choice, maxThreadFileBufferSize
and maxMasterFileBufferSize (set in etc/controlDict) can be over-ridden within
the case controlDict file, like other parameters. Additionally the fileHandler
can be set by:
- the "-fileHandler" command line argument;
- a FOAM_FILEHANDLER environment variable.
A foamFormatConvert utility allows users to convert files between the collated
and uncollated formats, e.g.
mpirun -np 2 foamFormatConvert -parallel -fileHandler uncollated
An example case demonstrating the file handling methods is provided in:
$FOAM_TUTORIALS/IO/fileHandling
The work was undertaken by Mattijs Janssens, in collaboration with Henry Weller.
This change changes the point-tetIndices-face interpolation function
method to take barycentric-tetIndices-face arguments instead. This
function is, at present, only used for interpolating Eulerian data to
Lagrangian particles.
This change prevents an inefficiency in cellPointInterpolation whereby
the position of the particle is calculated from it's barycentric
coordinates, before immediately being converted back to barycentric
coordinates to perform the interpolation.
Updated the tetrahedron and triangle classes to use the barycentric
primitives. Removed duplicate code for generating random positions in
tets and tris, and fixed bug in tri random position.
The averaging methods now take the particle barycentric coordinates as
inputs rather than global positions. This change significantly optimises
Dual averaging, which is the most commonly used method. The run time of
the lagrangian/MPPICFoam/Goldschmidt tutorial has been reduced by a
factor of about two.
Fixed reaction source terms in the energy and species fraction equations
by multiplying by the phase fraction.
Resolves bug report https://bugs.openfoam.org/view.php?id=2591
for consistency with reactingTwoPhaseEulerFoam and to ensure correct operation
of models requiring formal boundedness of phase-fractions.
Resolves bug-report https://bugs.openfoam.org/view.php?id=2589
Added a grow time and better allocate the CPU time to either add or grow. This
gives much more information to the user and helps changing the settings
accordingly.
Patch contributed by Francesco Contino
"pos" now returns 1 if the argument is greater than 0, otherwise it returns 0.
This is consistent with the common mathematical definition of the "pos" function:
https://en.wikipedia.org/wiki/Sign_(mathematics)
However the previous implementation in which 1 was also returned for a 0
argument is useful in many situations so the "pos0" has been added which returns
1 if the argument is greater or equal to 0. Additionally the "neg0" has been
added which returns 1 if if the argument is less than or equal to 0.
Temporal variation of Ta is generally more useful than spatial variation but
a run-time switch between the two modes of operation could be implemented in
needed.
Initially the listSwitches functions depended directly on argList functionality
but this has now been factored out so that the listSwitches functions are more
general and require only debug functionality.
Provides better context for the available boundary conditions, fvOptions,
functionObjects etc. and thus returns only those available to and compatible
with the particular application.
e.g.
pimpleFoam -help
Usage: pimpleFoam [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-listFunctionObjects
List functionObjects
-listFvOptions List fvOptions
-listRegisteredSwitches
List switches registered for run-time modification
-listScalarBCs List scalar field boundary conditions (fvPatchField<scalar>)
-listSwitches List switches declared in libraries but not set in
etc/controlDict
-listTurbulenceModels
List turbulenceModels
-listUnsetSwitches
List switches declared in libraries but not set in
etc/controlDict
-listVectorBCs List vector field boundary conditions (fvPatchField<vector>)
-noFunctionObjects
do not execute functionObjects
-parallel run in parallel
-postProcess Execute functionObjects only
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
pimpleFoam listTurbulenceModels
pimpleFoam -listTurbulenceModels
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: dev |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : dev-39c46019e44f
Exec : pimpleFoam -listTurbulenceModels
Date : Jun 10 2017
Time : 21:37:49
Host : "dm"
PID : 675
Case : /home/dm2/henry/OpenFOAM/OpenFOAM-dev
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
SetNaN : Initialising allocated memory to NaN (FOAM_SETNAN).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Turbulence models
3
(
LES
RAS
laminar
)
RAS models
18
(
LRR
LamBremhorstKE
LaunderSharmaKE
LienCubicKE
LienLeschziner
RNGkEpsilon
SSG
ShihQuadraticKE
SpalartAllmaras
kEpsilon
kOmega
kOmegaSST
kOmegaSSTLM
kOmegaSSTSAS
kkLOmega
qZeta
realizableKE
v2f
)
LES models
10
(
DeardorffDiffStress
Smagorinsky
SpalartAllmarasDDES
SpalartAllmarasDES
SpalartAllmarasIDDES
WALE
dynamicKEqn
dynamicLagrangian
kEqn
kOmegaSSTDES
)
Further work will be needed to support the -listTurbulenceModels option in
multiphase solvers.
The calculation of the max and min limits are now only performed if required,
i.e. specified in fvSolution.
Also resolves bug-report https://bugs.openfoam.org/view.php?id=2566
This addition allows for theoretical wave models to be utilised for
initialisation and as boundary conditions. Multiple models can be used
simultaneously, each with differing phases and orientations. If multiple
models are used the shapes and velocities are superimposed.
The wave models are specified in the velocity boundary condition. The
phase fraction boundary condition and the set utility both look up the
velocity condition in order to access the wave model. A velocity
boundary may be specified as follows:
inlet
{
type waveVelocity;
origin (0 0 0);
direction (1 0 0);
speed 2;
waves
(
Airy
{
length 300;
amplitude 2.5;
depth 150;
phase 0;
angle 0;
}
);
scale table ((1200 1) (1800 0));
crossScale constant 1;
}
The alpha boundary only requires the type, unless the name of the
velocity field is non-standard, in which case a "U" entry will also be
needed. The setWaves utility does not require a dictionary file; non-
standard field names can be specified as command-line arguments.
Wave models currently available are Airy (1st order) and Stokes2 (second
order). If a depth is specified, and it is not too large, then shallow
terms will be included, otherwise the models assume that the liquid is
deep.
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
This function object reports the height of the interface above a set of
locations. It writes the height above the location, above the boundary,
and the point on the interface. It uses an integral approach, so if
there are multiple interfaces above or below a location, this method
will compute an average.
It can be enabled with the following entry in the system/controlDict:
functions
{
interfaceHeight1
{
type interfaceHeight;
libs ("libfieldFunctionObjects.so");
alpha alpha.water;
locations ((0 0 0) (10 0 0) (20 0 0));
}
}
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.
Now the "localEuler" ddt scheme does not apply any corrections due to
mesh-motion; the old-time volumes are not used and the mesh-motion flux is set
to zero. A consequence of these changes is that boundedness of transported
scalars is ensured but mesh-motion causes a conservation error which will
reduces to zero as steady-state is approached and the mesh becomes stationary.
vectorField or vector2DField from scalarField components. To do this
properly and have it work for field-type combinations would require some
new field function macros.
discontinuous fields, with the discontinuity defined by a level set. The
functions do a proper integration of the discontinuous fields by tet-
and tri-cutting along the plane of the level set.
now possible with level-sets as well as planes. Removed tetPoints class
as this wasn't really used anywhere except for the old tet-cutting
routines. Restored tetPointRef.H to be consistent with other primitive
shapes. Re-wrote tet-overlap mapping in terms of the new cutting.
See tutorials/compressible/rhoPimpleFoam/RAS/squareBendLiq for exapmle
pimpleControl: Added SIMPLErho option for running in SIMPLE mode
with large time-step/Courant number and relaxation. With this option the
density is updated from thermodynamics rather than continuity after the pressure
equation which is better behaved if pressure is relaxed and/or solved to a
loose relative tolerance. The need for this option is demonstrated in the
tutorials/compressible/rhoPimpleFoam/RAS/angledDuct tutorial which is unstable
without the option.
In addition to local Doxygen HTML directories an optional HTTP server directory
may be specified:
Documentation
{
docBrowser "firefox";
doxyDocDirs
(
"$WM_PROJECT_USER_DIR/html"
"~OpenFOAM/html"
"$WM_PROJECT_DIR/doc/Doxygen/html"
"http://cpp.openfoam.org/dev"
);
doxySourceFileExt "_8C.html";
}
from which the Doxygen documentation files may be obtained so now the "-doc"
command-line option may be used even if if Doxygen has not been run locally,
e.g.
pimpleFoam -doc
When typing OpenFOAM commands, the bash completion system will
complete option names, e.g. -help, -parallel, etc. After typing an
option that includes an argument, e.g. -case <dir>, completion will
adjust to the type of argument, e.g. present directories if the
argument is a directory. Similarly, for applications with mandarory
file arguments, file (and directory) names will appear on the
completion list.
Provides the additional compression necessary to ensure interface integrity
adjacent to a boundary at a low angle of incidence to the interface. This is
particularly important when simulating planing hulls.
This tutorial demonstrates moving mesh and AMI with a Lagrangian cloud.
It is very slow, as interaction lists (required to compute collisions)
are not optimised for moving meshes. The simulation time has therefore
been made very short, so that it finishes in a reasonable time. The
mixer only completes a small fraction of a rotation in this time. This
is still sufficient to test tracking and collisions in the presence of
AMI and mesh motion.
In order to generate a convincing animation, however, the end time must
be increased and the simulation run for a number of days.
terms of the local barycentric coordinates of the current tetrahedron,
rather than the global coordinate system.
Barycentric tracking works on any mesh, irrespective of mesh quality.
Particles do not get "lost", and tracking does not require ad-hoc
"corrections" or "rescues" to function robustly, because the calculation
of particle-face intersections is unambiguous and reproducible, even at
small angles of incidence.
Each particle position is defined by topology (i.e. the decomposed tet
cell it is in) and geometry (i.e. where it is in the cell). No search
operations are needed on restart or reconstruct, unlike when particle
positions are stored in the global coordinate system.
The particle positions file now contains particles' local coordinates
and topology, rather than the global coordinates and cell. This change
to the output format is not backwards compatible. Existing cases with
Lagrangian data will not restart, but they will still run from time
zero without any modification. This change was necessary in order to
guarantee that the loaded particle is valid, and therefore
fundamentally prevent "loss" and "search-failure" type bugs (e.g.,
2517, 2442, 2286, 1836, 1461, 1341, 1097).
The tracking functions have also been converted to function in terms
of displacement, rather than end position. This helps remove floating
point error issues, particularly towards the end of a tracking step.
Wall bounded streamlines have been removed. The implementation proved
incompatible with the new tracking algorithm. ParaView has a surface
LIC plugin which provides equivalent, or better, functionality.
Additionally, bug report <https://bugs.openfoam.org/view.php?id=2517>
is resolved by this change.
By specifying the optional outside surface emissivity radiative heat transfer to
the ambient conditions is enabled. The far-field is assumed to have an
emissivity of 1 but this could be made an optional input in the future if
needed.
Relaxation of the surface temperature is now provided via the optional
"relaxation" which aids stability of steady-state runs with strong radiative
coupling to the boundary.
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;
}
}
Radiative heat transfer may now be added to any solver in which an energy
equation is solved at run-time rather than having to change the solver code.
For example, radiative heat transfer is now enabled in the SandiaD_LTS
reactingFoam tutorial by providing a constant/fvOptions file containing
radiation
{
type radiation;
libs ("libradiationModels.so");
}
and appropriate settings in the constant/radiationProperties file.
For example the porosity coefficients may now be specified thus:
porosity1
{
type DarcyForchheimer;
cellZone porosity;
d (5e7 -1000 -1000);
f (0 0 0);
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (0.70710678 0.70710678 0);
e2 (0 0 1);
}
}
}
rather than
porosity1
{
type DarcyForchheimer;
active yes;
cellZone porosity;
DarcyForchheimerCoeffs
{
d (5e7 -1000 -1000);
f (0 0 0);
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (0.70710678 0.70710678 0);
e2 (0 0 1);
}
}
}
}
support for which is maintained for backward compatibility.
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.
Main changes in the tutorial:
- General cleanup of the phaseProperties of unnecessary entries
- sensibleEnthalpy is used for both phases
- setTimeStep functionObject is used to set a sharp reduction in time step near the start of the injection
- Monitoring of pressure minimum and maximum
Patch contributed by Juho Peltola, VTT.
The standard naming convention for heat flux is "q" and this is used for the
conductive and convective heat fluxes is OpenFOAM. The use of "Qr" for
radiative heat flux is an anomaly which causes confusion, particularly for
boundary conditions in which "Q" is used to denote power in Watts. The name of
the radiative heat flux has now been corrected to "qr" and all models, boundary
conditions and tutorials updated.
by combining with and rationalizing functionality from
turbulentHeatFluxTemperatureFvPatchScalarField.
externalWallHeatFluxTemperatureFvPatchScalarField now replaces
turbulentHeatFluxTemperatureFvPatchScalarField which is no longer needed and has
been removed.
Description
This boundary condition applies a heat flux condition to temperature
on an external wall in one of three modes:
- fixed power: supply Q
- fixed heat flux: supply q
- fixed heat transfer coefficient: supply h and Ta
where:
\vartable
Q | Power [W]
q | Heat flux [W/m^2]
h | Heat transfer coefficient [W/m^2/K]
Ta | Ambient temperature [K]
\endvartable
For heat transfer coefficient mode optional thin thermal layer resistances
can be specified through thicknessLayers and kappaLayers entries.
The thermal conductivity \c kappa can either be retrieved from various
possible sources, as detailed in the class temperatureCoupledBase.
Usage
\table
Property | Description | Required | Default value
mode | 'power', 'flux' or 'coefficient' | yes |
Q | Power [W] | for mode 'power' |
q | Heat flux [W/m^2] | for mode 'flux' |
h | Heat transfer coefficient [W/m^2/K] | for mode 'coefficent' |
Ta | Ambient temperature [K] | for mode 'coefficient' |
thicknessLayers | Layer thicknesses [m] | no |
kappaLayers | Layer thermal conductivities [W/m/K] | no |
qr | Name of the radiative field | no | none
qrRelaxation | Relaxation factor for radiative field | no | 1
kappaMethod | Inherited from temperatureCoupledBase | inherited |
kappa | Inherited from temperatureCoupledBase | inherited |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type externalWallHeatFluxTemperature;
mode coefficient;
Ta uniform 300.0;
h uniform 10.0;
thicknessLayers (0.1 0.2 0.3 0.4);
kappaLayers (1 2 3 4);
kappaMethod fluidThermo;
value $internalField;
}
\endverbatim
Description
Temperature-dependent surface tension model in which the surface tension
function provided by the phase Foam::liquidProperties class is used.
Usage
\table
Property | Description | Required | Default value
phase | Phase name | yes |
\endtable
Example of the surface tension specification:
\verbatim
sigma
{
type liquidProperties;
phase water;
}
\endverbatim
for use with e.g. compressibleInterFoam, see
tutorials/multiphase/compressibleInterFoam/laminar/depthCharge2D
snappyHexMesh produces a far better quality AMI interface using a cylindrical background mesh,
leading to much more robust performance, even on a relatively coarse mesh. The min/max AMI
weights remain close to 1 as the mesh moves, giving better conservation.
The rotating geometry template cases are configured with a blockMeshDict file for a cylindrical
background mesh aligned along the z-axis. The details of use are found in the README and
blockMeshDict files.
Uncommenting the patches provides a convenient way to use the patches in the background mesh
to define the external boundary of the final mesh. Replaces previous setup with a separate
blockMeshDict.extPatches file.
These models have been particularly designed for use in the VoF solvers, both
incompressible and compressible. Currently constant and temperature dependent
surface tension models are provided but it easy to write models in which the
surface tension is evaluated from any fields held by the mesh database.
Created a base-class from contactAngleForce from which the
distributionContactAngleForce (for backward compatibility) and the new
temperatureDependentContactAngleForce are derived:
Description
Temperature dependent contact angle force
The contact angle in degrees is specified as a \c Function1 type, to
enable the use of, e.g. contant, polynomial, table values.
See also
Foam::regionModels::surfaceFilmModels::contactAngleForce
Foam::Function1Types
SourceFiles
temperatureDependentContactAngleForce.C
Demonstrates meshing a cylinder with hemispehrical ends using snappyHexMesh with
a polar background mesh that uses the point and edge projection feature of blockMesh.
The case prescribes a multiMotion on the cylinder, combining an oscillatingLinearMotion
and transverse rotatingMotion.
Off-centering is specified via the mandatory coefficient \c ocCoeff in the
range [0,1] following the scheme name e.g.
\verbatim
ddtSchemes
{
default CrankNicolson 0.9;
}
\endverbatim
or with an optional "ramp" function to transition from the Euler scheme to
Crank-Nicolson over a initial period to avoid start-up problems, e.g.
\verbatim
ddtSchemes
{
default CrankNicolson
ocCoeff
{
type scale;
scale linearRamp;
duration 0.01;
value 0.9;
};
}
\endverbatim
Note this functionality is experimental and the specification and implementation
may change if issues arise.
For example in the potentialFreeSurfaceFoam/oscillatingBox tutorial it is
cleaner to apply the "linearRamp" function to the "sine" function rather than
using an amplitude table:
floatingObject
{
type fixedNormalInletOutletVelocity;
fixTangentialInflow false;
normalVelocity
{
type uniformFixedValue;
uniformValue
{
type scale;
value
{
type sine;
frequency 1;
amplitude 0.025;
scale (0 1 0);
level (0 0 0);
}
scale
{
type linearRamp;
duration 10;
}
}
}
value uniform (0 0 0);
}
coupled patches, to prevent rebound/stick/etc... on these patches. Also
added "none" interaction type to LocalInteraction, which reverts the
patch interaction to the fundamental behaviour. This is primarily useful
for non-coupled constraint types.
Resolves https://bugs.openfoam.org/view.php?id=2458
The pitzDaily case uses a lot of mesh grading close to walls and the shear layer.
Prior to v2.4, blockMesh only permitted grading in one direction within a single block,
so the pitzDaily mesh comprised of 13 blocks to accommodate the complex grading pattern.
blockMesh has multi-grading that allows users to divide a block in a given direction and
apply different grading within each division. The mesh generated with blockMesh using
13 blocks has been replaced with a mesh of 5 blocks that use multi-grading. The new
blockMeshDict configuration produces a mesh very similar to the original 13-block mesh.
including support for TDAC and ISAT for efficient chemistry calculation.
Description
Eddy Dissipation Concept (EDC) turbulent combustion model.
This model considers that the reaction occurs in the regions of the flow
where the dissipation of turbulence kinetic energy takes place (fine
structures). The mass fraction of the fine structures and the mean residence
time are provided by an energy cascade model.
There are many versions and developments of the EDC model, 4 of which are
currently supported in this implementation: v1981, v1996, v2005 and
v2016. The model variant is selected using the optional \c version entry in
the \c EDCCoeffs dictionary, \eg
\verbatim
EDCCoeffs
{
version v2016;
}
\endverbatim
The default version is \c v2015 if the \c version entry is not specified.
Model versions and references:
\verbatim
Version v2005:
Cgamma = 2.1377
Ctau = 0.4083
kappa = gammaL^exp1 / (1 - gammaL^exp2),
where exp1 = 2, and exp2 = 2.
Magnussen, B. F. (2005, June).
The Eddy Dissipation Concept -
A Bridge Between Science and Technology.
In ECCOMAS thematic conference on computational combustion
(pp. 21-24).
Version v1981:
Changes coefficients exp1 = 3 and exp2 = 3
Magnussen, B. (1981, January).
On the structure of turbulence and a generalized
eddy dissipation concept for chemical reaction in turbulent flow.
In 19th Aerospace Sciences Meeting (p. 42).
Version v1996:
Changes coefficients exp1 = 2 and exp2 = 3
Gran, I. R., & Magnussen, B. F. (1996).
A numerical study of a bluff-body stabilized diffusion flame.
Part 2. Influence of combustion modeling and finite-rate chemistry.
Combustion Science and Technology, 119(1-6), 191-217.
Version v2016:
Use local constants computed from the turbulent Da and Re numbers.
Parente, A., Malik, M. R., Contino, F., Cuoci, A., & Dally, B. B.
(2016).
Extension of the Eddy Dissipation Concept for
turbulence/chemistry interactions to MILD combustion.
Fuel, 163, 98-111.
\endverbatim
Tutorials cases provided: reactingFoam/RAS/DLR_A_LTS, reactingFoam/RAS/SandiaD_LTS.
This codes was developed and contributed by
Zhiyi Li
Alessandro Parente
Francesco Contino
from BURN Research Group
and updated and tested for release by
Henry G. Weller
CFD Direct Ltd.
to provide smoother behavior on start-up when an acceleration impulse is
applied, e.g. if the body is suddenly released. e.g.
dynamicFvMesh dynamicMotionSolverFvMesh;
motionSolverLibs ("librigidBodyMeshMotion.so");
solver rigidBodyMotion;
rigidBodyMotionCoeffs
{
report on;
solver
{
type Newmark;
}
ramp
{
type quadratic;
start 0;
duration 10;
}
.
.
.
will quadratically ramp the forces from 0 to their full values over the first
10s of the run starting from 0. If the 'ramp' entry is omitted no force ramping
is applied.
Description
Ramp function base class for the set of scalar functions starting from 0 and
increasing monotonically to 1 from \c start over the \c duration and
remaining at 1 thereafter.
Usage:
\verbatim
<entryName> <rampFunction>;
<entryName>Coeffs
{
start 10;
duration 20;
}
\endverbatim
or
\verbatim
<entryName>
{
type <rampFunction>;
start 10;
duration 20;
}
\endverbatim
Where:
\table
Property | Description | Required | Default value
start | Start time | no | 0
duration | Duration | yes |
\endtable
The following common ramp functions are provided: linear, quadratic, halfCosine,
quarterCosine and quaterSine, others can easily be added and registered to the run-time
selection system.
e.g.
ramp
{
type quadratic;
start 200;
duration 1.6;
}
but the old format is supported for backward compatibility:
ramp linear;
rampCoeffs
{
start 200;
duration 1.6;
}
Formally this is equivalent to the previous formulation but more convenient to
use given that for compressible flow the mass flux rather than the volume flux
is available.
These legacy boundary conditions are no longer needed and have been superseded
by the more flexible sixDoFRigidBodyMotion and rigidBodyMotion solvers. See tutorials:
incompressible/pimpleDyMFoam/wingMotion/wingMotion2D_pimpleDyMFoam
multiphase/interDyMFoam/RAS/DTCHull
multiphase/interDyMFoam/RAS/floatingObject
Resolves bug-report https://bugs.openfoam.org/view.php?id=2487
Using
decomposePar -copyZero
The mesh is decomposed as usual but the '0' directory is recursively copied to
the 'processor.*' directories rather than decomposing the fields. This is a
convenient option to handle cases where the initial field files are generic and
can be used for serial or parallel running. See for example the
incompressible/simpleFoam/motorBike tutorial case.
Both stardard SIMPLE and the SIMPLEC (using the 'consistent' option in
fvSolution) are now supported for both subsonic and transonic flow of all
fluid types.
rhoPimpleFoam now instantiates the lower-level fluidThermo which instantiates
either a psiThermo or rhoThermo according to the 'type' specification in
thermophysicalProperties, see also commit 655fc78748
Both stardard SIMPLE and the SIMPLEC (using the 'consistent' option in
fvSolution) are now supported for both subsonic and transonic flow of all
fluid types.
rhoSimpleFoam now instantiates the lower-level fluidThermo which instantiates
either a psiThermo or rhoThermo according to the 'type' specification in
thermophysicalProperties, e.g.
thermoType
{
type hePsiThermo;
mixture pureMixture;
transport sutherland;
thermo janaf;
equationOfState perfectGas;
specie specie;
energy sensibleInternalEnergy;
}
instantiates a psiThermo for a perfect gas with JANAF thermodynamics, whereas
thermoType
{
type heRhoThermo;
mixture pureMixture;
properties liquid;
energy sensibleInternalEnergy;
}
mixture
{
H2O;
}
instantiates a rhoThermo for water, see new tutorial
compressible/rhoSimpleFoam/squareBendLiq.
In order to support complex equations of state the pressure can no longer be
unlimited and rhoSimpleFoam now limits the pressure rather than the density to
handle start-up more robustly.
For backward compatibility 'rhoMin' and 'rhoMax' can still be used in the SIMPLE
sub-dictionary of fvSolution which are converted into 'pMax' and 'pMin' but it
is better to set either 'pMax' and 'pMin' directly or use the more convenient
'pMinFactor' and 'pMinFactor' from which 'pMax' and 'pMin' are calculated using
the fixed boundary pressure or reference pressure e.g.
SIMPLE
{
nNonOrthogonalCorrectors 0;
pMinFactor 0.1;
pMaxFactor 1.5;
transonic yes;
consistent yes;
residualControl
{
p 1e-3;
U 1e-4;
e 1e-3;
"(k|epsilon|omega)" 1e-3;
}
}
This allows single, multi-phase and VoF compressible simulations to be performed
with the accurate thermophysical property functions for liquids provided by the
liquidProperty classes. e.g. in the
multiphase/compressibleInterFoam/laminar/depthCharge2D tutorial water can now be
specified by
thermoType
{
type heRhoThermo;
mixture pureMixture;
properties liquid;
energy sensibleInternalEnergy;
}
mixture
{
H2O;
}
as an alternative to the previous less accurate representation defined by
thermoType
{
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState perfectFluid;
specie specie;
energy sensibleInternalEnergy;
}
mixture
{
specie
{
molWeight 18.0;
}
equationOfState
{
R 3000;
rho0 1027;
}
thermodynamics
{
Cp 4195;
Hf 0;
}
transport
{
mu 3.645e-4;
Pr 2.289;
}
}
However the increase in accuracy of the new simpler and more convenient
specification and representation comes at a cost: the NSRDS functions used by
the liquidProperties classes are relatively expensive to evaluate and the
depthCharge2D case takes ~14% longer to run.
Description
Base-class for thermophysical properties of solids, liquids and gases
providing an interface compatible with the templated thermodynamics
packages.
liquidProperties, solidProperties and thermophysicalFunction libraries have been
combined with the new thermophysicalProperties class into a single
thermophysicalProperties library to simplify compilation and linkage of models,
libraries and applications dependent on these classes.
The entries for liquid and solid species can now be simply be the name unless
property coefficients are overridden in which are specified in a dictionary as
before e.g. in the tutorials/lagrangian/coalChemistryFoam/simplifiedSiwek case
the water is simply specified
liquids
{
H2O;
}
and solid ash uses standard coefficients but the coefficients for carbon are
overridden thus
solids
{
C
{
rho 2010;
Cp 710;
kappa 0.04;
Hf 0;
emissivity 1.0;
}
ash;
}
The defaultCoeffs entry is now redundant and supported only for backward
compatibility. To specify a liquid with default coefficients simply leave the
coefficients dictionary empty:
liquids
{
H2O {}
}
Any or all of the coefficients may be overridden by specifying the properties in
the coefficients dictionary, e.g.
liquids
{
H2O
{
rho
{
a 1000;
b 0;
c 0;
d 0;
}
}
}
When liquids are constructed from dictionary the coefficients are now first
initialized to their standard values and overridden by the now optional entries
provided in the dictionary. For example to specify water with all the standard
temperature varying properties but override only the density with a constant
value of 1000 specify in thermophysicalProperties
liquids
{
H2O
{
defaultCoeffs no;
H2OCoeffs
{
rho
{
a 1000;
b 0;
c 0;
d 0;
}
}
}
}
The fundamental properties provided by the specie class hierarchy were
mole-based, i.e. provide the properties per mole whereas the fundamental
properties provided by the liquidProperties and solidProperties classes are
mass-based, i.e. per unit mass. This inconsistency made it impossible to
instantiate the thermodynamics packages (rhoThermo, psiThermo) used by the FV
transport solvers on liquidProperties. In order to combine VoF with film and/or
Lagrangian models it is essential that the physical propertied of the three
representations of the liquid are consistent which means that it is necessary to
instantiate the thermodynamics packages on liquidProperties. This requires
either liquidProperties to be rewritten mole-based or the specie classes to be
rewritten mass-based. Given that most of OpenFOAM solvers operate
mass-based (solve for mass-fractions and provide mass-fractions to sub-models it
is more consistent and efficient if the low-level thermodynamics is also
mass-based.
This commit includes all of the changes necessary for all of the thermodynamics
in OpenFOAM to operate mass-based and supports the instantiation of
thermodynamics packages on liquidProperties.
Note that most users, developers and contributors to OpenFOAM will not notice
any difference in the operation of the code except that the confusing
nMoles 1;
entries in the thermophysicalProperties files are no longer needed or used and
have been removed in this commet. The only substantial change to the internals
is that species thermodynamics are now "mixed" with mass rather than mole
fractions. This is more convenient except for defining reaction equilibrium
thermodynamics for which the molar rather than mass composition is usually know.
The consequence of this can be seen in the adiabaticFlameT, equilibriumCO and
equilibriumFlameT utilities in which the species thermodynamics are
pre-multiplied by their molecular mass to effectively convert them to mole-basis
to simplify the definition of the reaction equilibrium thermodynamics, e.g. in
equilibriumCO
// Reactants (mole-based)
thermo FUEL(thermoData.subDict(fuelName)); FUEL *= FUEL.W();
// Oxidant (mole-based)
thermo O2(thermoData.subDict("O2")); O2 *= O2.W();
thermo N2(thermoData.subDict("N2")); N2 *= N2.W();
// Intermediates (mole-based)
thermo H2(thermoData.subDict("H2")); H2 *= H2.W();
// Products (mole-based)
thermo CO2(thermoData.subDict("CO2")); CO2 *= CO2.W();
thermo H2O(thermoData.subDict("H2O")); H2O *= H2O.W();
thermo CO(thermoData.subDict("CO")); CO *= CO.W();
// Product dissociation reactions
thermo CO2BreakUp
(
CO2 == CO + 0.5*O2
);
thermo H2OBreakUp
(
H2O == H2 + 0.5*O2
);
Please report any problems with this substantial but necessary rewrite of the
thermodynamic at https://bugs.openfoam.org
Henry G. Weller
CFD Direct Ltd.
Description
Evolves a passive scalar transport equation.
- To specify the field name set the \c field entry
- To employ the same numerical schemes as another field set
the \c schemesField entry,
- A constant diffusivity may be specified with the \c D entry,
- Alternatively if a turbulence model is available a turbulent diffusivity
may be constructed from the laminar and turbulent viscosities using the
optional diffusivity coefficients \c alphaD and \c alphaDt (which default
to 1):
\verbatim
D = alphaD*nu + alphaDt*nut
\endverbatim
Resolves feature request https://bugs.openfoam.org/view.php?id=2453
Now the interFoam and compressibleInterFoam families of solvers use the same
alphaEqn formulation and supporting all of the MULES options without
code-duplication.
The semi-implicit MULES support allows running with significantly larger
time-steps but this does reduce the interface sharpness.
Description
Simple solidification porosity model
This is a simple approximation to solidification where the solid phase
is represented as a porous blockage with the drag-coefficient evaluated from
\f[
S = - \alpha \rho D(T) U
\f]
where
\vartable
\alpha | Optional phase-fraction of solidifying phase
D(T) | User-defined drag-coefficient as function of temperature
\endvartable
Note that the latent heat of solidification is not included and the
temperature is unchanged by the modelled change of phase.
Example of the solidification model specification:
\verbatim
type solidification;
solidificationCoeffs
{
// Solidify between 330K and 330.5K
D table
(
(330.0 10000) // Solid below 330K
(330.5 0) // Liquid above 330.5K
);
// Optional phase-fraction of solidifying phase
alpha alpha.liquid;
// Solidification porosity is isotropic
// use the global coordinate system
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (1 0 0);
e2 (0 1 0);
}
}
}
\endverbatim
Description
Simple solidification porosity model
This is a simple approximation to solidification where the solid phase
is represented as a porous blockage with the drag-coefficient evaluated from
\f[
S = - \rho D(T) U
\f]
where
\vartable
D(T) | User-defined drag-coefficient as function of temperature
\endvartable
Note that the latent heat of solidification is not included and the
temperature is unchanged by the modelled change of phase.
Example of the solidification model specification:
\verbatim
type solidification;
solidificationCoeffs
{
// Solidify between 330K and 330.5K
D table
(
(330.0 10000) // Solid below 330K
(330.5 0) // Liquid above 330.5K
);
// Solidification porosity is isotropic
// use the global coordinate system
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (1 0 0);
e2 (0 1 0);
}
}
}
\endverbatim
if convergence is not achieved within the maximum number of iterations.
Sometimes, particularly running in parallel, PBiCG fails to converge or diverges
without warning or obvious cause leaving a solution field containing significant
errors which can cause divergence of the application. PBiCGStab is more robust
and does not suffer from the problems encountered with PBiCG.
The previous time-step compression flux is not valid/accurate on the new mesh
and it is better to re-calculate it rather than map it from the previous mesh to
the new mesh.
By default snappyHexMesh writes files relating to the hex-splitting process into
the polyMesh directory: cellLevel level0Edge pointLevel surfaceIndex
but by setting the noRefinement flag:
writeFlags
(
noRefinement
.
.
.
);
these optional files which are generally not needed are not written.
If you run the three stages of snappyHexMesh separately or run a dynamic mesh
solver supporting refinement and unrefinement these files are needed
and "noRefinement" should not be set.
unless the blockMeshDict is in the polyMesh directory or the "-noClean" option
is specified.
This avoids problems running snappyHexMesh without first clearing files from
polyMesh which interfere with the operation of snappyHexMesh.
The files relating to the hex refinement are written out explicitly both by
snappyHexMesh and dynamicRefineFvMesh and hence should be set "NO_WRITE" rather
than "AUTO_WRITE" to avoid writing them twice. This change corrects the
handling of the "refinementHistory" file which should not be written by
snappyHexMesh.
Avoids slight phase-fraction unboundedness at entertainment BCs and improved
robustness.
Additionally the phase-fractions in the multi-phase (rather than two-phase)
solvers are adjusted to avoid the slow growth of inconsistency ("drift") caused
by solving for all of the phase-fractions rather than deriving one from the
others.
e.g.
fieldMinMax fieldMinMax write:
min(T) = 291 in cell 255535 at location (-0.262546 -0.538933 1.00574) on processor 9
max(T) = 336.298 in cell 419031 at location (1.7468 0.758405 8.10989) on processor 1
min(mag(U)) = 0 in cell 14990 at location (-0.0824383 1.68479 1.5349) on processor 0
max(mag(U)) = 652.341 in cell 218284 at location (0.609849 0.167247 1.00091) on processor 12
New reactingFoam tutorial counterFlowFlame2DLTS_GRI_TDAC demonstrates this new
functionality.
Additionally the ISAT table growth algorithm has been further optimized
providing an overall speedup of between 15% and 38% for the tests run so far.
Updates to TDAC and ISAT provided by Francesco Contino.
Implementation updated and integrated into OpenFOAM-dev by
Henry G. Weller, CFD Direct Ltd with the help of Francesco Contino.
Original code providing all algorithms for chemistry reduction and
tabulation contributed by Francesco Contino, Tommaso Lucchini, Gianluca
D’Errico, Hervé Jeanmart, Nicolas Bourgeois and Stéphane Backaert.
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.
motorBike
{
type triSurfaceMesh;
file "motorBike.obj";
}
Based on patch provided by Mattijs Janssens
Resolves part of bug-report https://bugs.openfoam.org/view.php?id=2396
e.g. in the reactingFoam/laminar/counterFlowFlame2DLTS tutorial:
PIMPLE
{
momentumPredictor no;
nOuterCorrectors 1;
nCorrectors 1;
nNonOrthogonalCorrectors 0;
maxDeltaT 1e-2;
maxCo 1;
alphaTemp 0.05;
alphaY 0.05;
Yref
{
O2 0.1;
".*" 1;
}
rDeltaTSmoothingCoeff 1;
rDeltaTDampingCoeff 1;
}
will limit the LTS time-step according to the rate of consumption of 'O2'
normalized by the reference mass-fraction of 0.1 and all other species
normalized by the reference mass-fraction of 1. Additionally the time-step
factor of 'alphaY' is applied to all species. Only the species specified in the
'Yref' sub-dictionary are included in the LTS limiter and if 'alphaY' is omitted
or set to 1 the reaction rates are not included in the LTS limiter.
Combined 'dQ()' and 'Sh()' into 'Qdot()' which returns the heat-release rate in
the normal units [kg/m/s3] and used as the heat release rate source term in
the energy equations, to set the field 'Qdot' in several combustion solvers
and for the evaluation of the local time-step when running LTS.
defined by functionObjects, e.g. wallHeatFlux, wallShearStress and yPlus.
Patch contributed by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2353
which provided warning about backward-compatibility issue with setting div
schemes for steady-state. It caused confusion by generating incorrect warning
messages for compressible cases for which the 'bounded' should NOT be applied to
the 'div(phid,p)'.
e.g. the motion of two counter-rotating AMI regions could be defined:
dynamicFvMesh dynamicMotionSolverListFvMesh;
solvers
(
rotor1
{
solver solidBody;
cellZone rotor1;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 6.2832; // rad/s
}
}
rotor2
{
solver solidBody;
cellZone rotor2;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega -6.2832; // rad/s
}
}
);
Any combination of motion solvers may be selected but there is no special
handling of motion interaction; the motions are applied sequentially and
potentially cumulatively.
To support this new general framework the solidBodyMotionFvMesh and
multiSolidBodyMotionFvMesh dynamicFvMeshes have been converted into the
corresponding motionSolvers solidBody and multiSolidBody and the tutorials
updated to reflect this change e.g. the motion in the mixerVesselAMI2D tutorial
is now defined thus:
dynamicFvMesh dynamicMotionSolverFvMesh;
solver solidBody;
solidBodyCoeffs
{
cellZone rotor;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 6.2832; // rad/s
}
}
to avoid duplicate instantiation of the thermodynamics package.
The 'zoneCombustion' model is now selected in constant/combustionProperties by
either
combustionModel zoneCombustion<psiCombustionModel>;
or
combustionModel zoneCombustion<rhoCombustionModel>;
as appropriate.
Resolves bug-report http://bugs.openfoam.org/view.php?id=2354
- provides support for manipulating polyMesh/boundary
- changed behaviour of disableFunctionEntries option to preserve
#include
- dictionary: added reading of lists of dictionaries.
+ each list element may be accessed using the 'entryDDD' keyword
according to their list index.
Patch contributed by Mattijs Janssens
cellZones and pointZones can now be created in one action without the
need to first create a cellSet or pointSet and converting that to the
corresponding zone, e.g.
actions
(
// Example: create cellZone from a box region
{
name c0;
type cellZoneSet;
action new;
source boxToCell;
sourceInfo
{
box (0.04 0 0)(0.06 100 100);
}
}
);
postProcess -func MachNo
previously generated the warning
Executing functionObjects
--> FOAM Warning : functionObjects::MachNo MachNo cannot find required field U
which is incorrect; the field 'U' is available but the
thermophysicalProperties is not. Now 'postProcess' generates the
warning:
Executing functionObjects
--> FOAM Warning : functionObjects::MachNo MachNo cannot find required object thermophysicalProperties of type fluidThermo
--> FOAM Warning : functionObjects::MachNo MachNo failed to execute.
Resolves bug-report http://bugs.openfoam.org/view.php?id=2352
in which the reactions are enabled only in the specified list of
cellZones. e.g. in constant/combustionProperties
combustionModel zoneCombustion<psiChemistryCombustion>;
active true;
zoneCombustionCoeffs
{
zones (catalyst);
}
and in constant/zoneCombustionProperties
combustionModel laminar<psiChemistryCombustion>;
active true;
laminarCoeffs
{}
Corrected form of the Rosin-Rammler distribution taking into account the
varying number of particels per parces for for fixed-mass parcels. This
distribution should be used when
\verbatim
parcelBasisType mass;
\endverbatim
See equation 10 in reference:
\verbatim
Yoon, S. S., Hewson, J. C., DesJardin, P. E., Glaze, D. J.,
Black, A. R., & Skaggs, R. R. (2004).
Numerical modeling and experimental measurements of a high speed
solid-cone water spray for use in fire suppression applications.
International Journal of Multiphase Flow, 30(11), 1369-1388.
\endverbatim
The operation can be applied to any volume or surface fields generating a
volume or surface scalar field.
Example of function object specification:
\verbatim
Ttot
{
type add;
libs ("libfieldFunctionObjects.so");
fields (T Tdelta);
result Ttot;
executeControl writeTime;
writeControl writeTime;
}
\endverbatim
Also refactored functionObjects::fieldsExpression to avoid code
duplication between the 'add' and 'subtract' functionObjects.
The operation can be applied to any volume or surface fields generating a
volume or surface scalar field.
Example of function object specification:
\verbatim
Tdiff
{
type subtract;
libs ("libfieldFunctionObjects.so");
fields (T Tmean);
result Tdiff;
executeControl writeTime;
writeControl writeTime;
}
\endverbatim
The spherical part of the Reynolds stress is included in the pressure so
that the wall boundary condition for the pressure is zeroGradient.
Resolves bug-report http://bugs.openfoam.org/view.php?id=2325
Added the interfacial pressure-work terms according to:
Ishii, M., Hibiki, T.,
Thermo-fluid dynamics of two-phase flow,
ISBN-10: 0-387-28321-8, 2006
While this is the most common approach to handling the interfacial
pressure-work it introduces numerical stability issues in regions of low
phase-fraction and rapid flow deformation. To alleviate this problem an
optional limiter may be applied to the pressure-work term in either of
the energy forms. This may specified in the
"thermophysicalProperties.<phase>" file, e.g.
pressureWorkAlphaLimit 1e-3;
which sets the pressure work term to 0 for phase-fractions below 1e-3.
For particularly unstable cases a limit of 1e-2 may be necessary.
The best of the current options is to use the latest version of
exuberant ctags (which has a new C++ parser) to generate both
declaration and definition tags.
gtags works to some extent and provides additional information about the
function signatures but the C++ parser is not accurate and misses scope
information. gtags can be used with the ctags parser which is effective
but looses the primary advantage of gtags being able to provide function
signatures so support has been switched-off by default.
ebrowse does not appear to be very useful for traversing the OpenFOAM
class tree and the support has been switched-off by default.
Added 'READ_IF_PRESENT' option to support overriding of the default BCs
for complex problems requiring special treatment of Udm at boundaries.
Resolves bug-report http://bugs.openfoam.org/view.php?id=2317
In many publications and Euler-Euler codes the pressure-work term in the
total enthalpy is stated and implemented as -alpha*dp/dt rather than the
conservative form derived from the total internal energy equation
-d(alpha*p)/dt. In order for the enthalpy and internal energy equations
to be consistent this error/simplification propagates to the total
internal energy equation as a spurious additional term p*d(alpha)/dt
which is included in the OpenFOAM Euler-Euler solvers and causes
stability and conservation issues.
I have now re-derived the energy equations for multiphase flow from
first-principles and implemented in the reactingEulerFoam solvers the
correct conservative form of pressure-work in both the internal energy
and enthalpy equations.
Additionally an optional limiter may be applied to the pressure-work
term in either of the energy forms to avoid spurious fluctuations in the
phase temperature in regions where the phase-fraction -> 0. This may
specified in the "thermophysicalProperties.<phase>" file, e.g.
pressureWorkAlphaLimit 1e-3;
which sets the pressure work term to 0 for phase-fractions below 1e-3.
New functionality contributed by Mattijs Janssens:
- new edge projection: projectCurve for use with new geometry
'searchableCurve'
- new tutorial 'pipe'
- naming of vertices and blocks (see pipe tutorial). Including back
substitution for error messages.
Previously the inlet flow of phase 1 (the phase solved for) is corrected
to match the inlet specification for that phase. However, if the second
phase is also constrained at inlets the inlet flux must also be
corrected to match the inlet specification.
Loop over the edges of each block rather than the edgeList of the
topological mesh due to problems with calcEdges for blocks with repeated
point labels
- Write differences with respect to the specified dictionary
(or sub entry if -entry specified)
- Write the differences with respect to a template dictionary:
foamDictionary 0/U -diff $FOAM_ETC/templates/closedVolume/0/U
- Write the differences in boundaryField with respect to a
template dictionary:
foamDictionary 0/U -diff $FOAM_ETC/templates/closedVolume/0/U \
-entry boundaryField
Patch contributed by Mattijs Janssens
Patch contributed by Mattijs Janssens
- Added projected vertices
- Added projected edges
- Change of blockEdges API (operate on list lambdas)
- Change of blockFaces API (pass in blockDescriptor and blockFacei)
- Added sphere7ProjectedEdges tutorial to demonstrate vertex and edge projection
For example, to mesh a sphere with a single block the geometry is defined in the
blockMeshDict as a searchableSurface:
geometry
{
sphere
{
type searchableSphere;
centre (0 0 0);
radius 1;
}
}
The vertices, block topology and curved edges are defined in the usual
way, for example
v 0.5773502;
mv -0.5773502;
a 0.7071067;
ma -0.7071067;
vertices
(
($mv $mv $mv)
( $v $mv $mv)
( $v $v $mv)
($mv $v $mv)
($mv $mv $v)
( $v $mv $v)
( $v $v $v)
($mv $v $v)
);
blocks
(
hex (0 1 2 3 4 5 6 7) (10 10 10) simpleGrading (1 1 1)
);
edges
(
arc 0 1 (0 $ma $ma)
arc 2 3 (0 $a $ma)
arc 6 7 (0 $a $a)
arc 4 5 (0 $ma $a)
arc 0 3 ($ma 0 $ma)
arc 1 2 ($a 0 $ma)
arc 5 6 ($a 0 $a)
arc 4 7 ($ma 0 $a)
arc 0 4 ($ma $ma 0)
arc 1 5 ($a $ma 0)
arc 2 6 ($a $a 0)
arc 3 7 ($ma $a 0)
);
which will produce a mesh in which the block edges conform to the sphere
but the faces of the block lie somewhere between the original cube and
the spherical surface which is a consequence of the edge-based
transfinite interpolation.
Now the projection of the block faces to the geometry specified above
can also be specified:
faces
(
project (0 4 7 3) sphere
project (2 6 5 1) sphere
project (1 5 4 0) sphere
project (3 7 6 2) sphere
project (0 3 2 1) sphere
project (4 5 6 7) sphere
);
which produces a mesh that actually conforms to the sphere.
See OpenFOAM-dev/tutorials/mesh/blockMesh/sphere
This functionality is experimental and will undergo further development
and generalization in the future to support more complex surfaces,
feature edge specification and extraction etc. Please get involved if
you would like to see blockMesh become a more flexible block-structured
mesher.
Henry G. Weller, CFD Direct.
to handle the size of bubbles created by boiling. To be used in
conjunction with the alphatWallBoilingWallFunction boundary condition.
The IATE variant of the wallBoiling tutorial case is provided to
demonstrate the functionality:
tutorials/multiphase/reactingTwoPhaseEulerFoam/RAS/wallBoilingIATE
Contributed by Juho Peltola, VTT
Notable changes:
1. The same wall function is now used for both phases, but user must
specify phaseType ‘liquid’ or ‘vapor’
2. Runtime selectable submodels for:
- wall heat flux partitioning between the phases
- nucleation site density
- bubble departure frequency
- bubble departure diameter
3. An additional iteration loop for the wall boiling model in case
the initial guess for the wall temperature proves to be poor.
The wallBoiling tutorial has been updated to demonstrate this new functionality.
This supports the abstraction of the set of fields from the field code
generation macros making it easier to change the set of fields supported
by OpenFOAM. This functionality is demonstrated in the updated
fvPatchFields macros and will be applied to the rest of the field code
generation macros in the future.
blockMesh -help
Usage: blockMesh [OPTIONS]
options:
-blockTopology write block edges and centres as .obj files
-case <dir> specify alternate case directory, default is the cwd
-dict <file> specify alternative dictionary for the blockMesh description
-noFunctionObjects
do not execute functionObjects
-region <name> specify alternative mesh region
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
Block description
For a given block, the correspondence between the ordering of
vertex labels and face labels is shown below.
For vertex numbering in the sequence 0 to 7 (block, centre):
faces 0 (f0) and 1 are left and right, respectively;
faces 2 and 3 are bottom and top;
and faces 4 and 5 are front the back:
4 ---- 5
f3 |\ |\ f5
| | 7 ---- 6 \
| 0 |--- 1 | \
| \| \| f4
f2 3 ---- 2
f0 ----- f1
Using: OpenFOAM-dev (see www.OpenFOAM.org)
Build: dev-9d3f407fc741
Patch contributed by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2267
1. Spaced ending of multi-level template parameters are not allowed, such as:
List<List<scalar> >
which instead should be:
List<List<scalar>>
2. The use of the 'NULL' macro should be replaced by 'nullptr'
to ensure 'patchType' is set as specified.
Required substantial change to the organization of the reading of the
'value' entry requiring careful testing and there may be some residual
issues remaining. Please report any problems with the reading and
initialization of patch fields.
Resolves bug-report http://bugs.openfoam.org/view.php?id=2266
e.g. for the cavity tutorial the moving wall patch can be specified in
terms of the block vertices as before:
boundary
(
movingWall
{
type wall;
faces
(
(3 7 6 2)
);
}
.
.
.
or the new specification of the face as block 0, block face 3:
boundary
(
movingWall
{
type wall;
faces
(
(0 3)
);
}
Renamed the original 'laminar' model to 'Stokes' to indicate it is a
linear stress model supporting both Newtonian and non-Newtonian
viscosity.
This general framework will support linear, non-linear, visco-elastic
etc. laminar transport models.
For backward compatibility the 'Stokes' laminar stress model can be
selected either the original 'laminar' 'simulationType'
specification in turbulenceProperties:
simulationType laminar;
or using the new more general 'laminarModel' specification:
simulationType laminar;
laminar
{
laminarModel Stokes;
}
which allows other laminar stress models to be selected.
Required to support LTS with the -postProcess option with sub-models dependent on ddt
terms during construction, in particular reactingTwoPhaseEulerFoam.
Individual inward-pointing faces are checked and if all faces are
inward-pointing the block is inside-out. These errors are fatal and the
message indicates which block the error occurs in and where in the
blockMeshDict the block is defined.
Now the postProcess utility '-region' option works correctly, e.g. for
the chtMultiRegionSimpleFoam/heatExchanger case
postProcess -region air -func "mag(U)"
calculates 'mag(U)' for all the time steps in region 'air'.
using a run-time selectable preconditioner
References:
Van der Vorst, H. A. (1992).
Bi-CGSTAB: A fast and smoothly converging variant of Bi-CG
for the solution of nonsymmetric linear systems.
SIAM Journal on scientific and Statistical Computing, 13(2), 631-644.
Barrett, R., Berry, M. W., Chan, T. F., Demmel, J., Donato, J.,
Dongarra, J., Eijkhout, V., Pozo, R., Romine, C. & Van der Vorst, H.
(1994).
Templates for the solution of linear systems:
building blocks for iterative methods
(Vol. 43). Siam.
See also: https://en.wikipedia.org/wiki/Biconjugate_gradient_stabilized_method
Tests have shown that PBiCGStab with the DILU preconditioner is more
robust, reliable and shows faster convergence (~2x) than PBiCG with
DILU, in particular in parallel where PBiCG occasionally diverges.
This remarkable improvement over PBiCG prompted the update of all
tutorial cases currently using PBiCG to use PBiCGStab instead. If any
issues arise with this update please report on Mantis: http://bugs.openfoam.org
- There will be triangles rendered inside the mesh (when
surface-rendering), because one of the cell's triangles is defined
as a quadrangle in VTK_WEDGE.
- Therefore, this VTK_WEDGE representation is only used when
decomposing the mesh, otherwise the correct representation is done
by VTK_POLYHEDRON.
- Furthermore, using VTK_PYRAMID gave worse result, because it renders
2 triangles inside the mesh for the collapsed quadrangle, likely due
to mismatch with the adjacent cell's face.
- Using VTK_HEXAHEDRON was not tested in this iteration, given that it
should give even worse results, when compared to using VTK_PYRAMID.
Patch contributed by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2099
- "$FOAM_USER_APPBIN" and "$FOAM_USER_LIBBIN" have been added to
"foamOldDirs" in "etc/bashrc" and "etc/config.sh/unset"
- "$OPAL_PREFIX" is now undefined in the option "SYSTEMOPENMPI" within
"etc/config.sh/mpi", but only if the path defined in this variable
is cleaned when using "foamCleanPath".
- "$OPAL_PREFIX" is now also conditionally undefined in
"etc/config.sh/unset" when the path is picked up by "foamCleanPath".
Patch contributed by Bruno Santos
Resolved bug-report http://bugs.openfoam.org/view.php?id=2210
Description
An incompressible Casson non-Newtonian viscosity model.
References:
\verbatim
Casson, N. (1959).
Rheology of disperse systems.
In Proceedings of a Conference Organized by the
British Society of Rheology.
Pergamon Press, New York.
Fournier, R. L. (2011).
Basic transport phenomena in biomedical engineering.
CRC Press.
\endverbatim
Contributed by Sergey Sindeev
Description
Allows specification of different writing frequency of objects registered
to the database.
It has similar functionality as the main time database through the
\c writeControl setting:
- timeStep
- writeTime
- adjustableRunTime
- runTime
- clockTime
- cpuTime
It also has the ability to write the selected objects that were defined
with the respective write mode for the requested \c writeOption, namely:
- \c autoWrite - objects set to write at output time
- \c noWrite - objects set to not write by default
- \c anyWrite - any option of the previous two
Example of function object specification:
\verbatim
writeObjects1
{
type writeObjects;
libs ("libutilityFunctionObjects.so");
...
objects (obj1 obj2);
writeOption anyWrite;
}
\endverbatim
Patch contributed by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2090
Time: call functionObject 'execute()' and 'end()' for last time-step
Now the operation of functionObject 'end()' call is consistent between running and post-processing
Now the number of iterations to solve each component in a segregated
solution are stored and returned in the SolverPerformance class.
Resolves bug-report http://bugs.openfoam.org/view.php?id=2189
Now the functionality to write single graph files or log files (vs time)
may be used in the creation of any form of functionObject, not just
those relating to a mesh region.
The change from C++0x to C++11 allows all of C++11 functionality to be
used in OpenFOAM, in particular constructor delegation which avoids code
duplication or constructor helper functions. However, this also means a
change to the minimum gcc version supported which is now 4.7 rather than
4.5.
Note that gcc-4.7 does not support the entire C++11 standard but does
support all of the functionality currently needed for further OpenFOAM
development. The minimum gcc-version which supports the entire C++11
standard is 4.8 which is now the recommended minimum gcc version.
The diameter of the drops formed are obtained from the local capillary
length multiplied by the \c dCoeff coefficient which defaults to 3.3.
Reference:
Lefebvre, A. (1988).
Atomization and sprays
(Vol. 1040, No. 2756). CRC press.
Changed default mode of operation to use standard y+ based switching
rather than the previous ad hoc blending and added consistent handling
of the near-wall generation term.
This boundary condition provides a wall constraint on turbulnce specific
dissipation, omega for both low and high Reynolds number turbulence models.
The near-wall omega may be either blended between the viscous region and
logarithmic region values using:
\f[
\omega = sqrt(\omega_{vis}^2 + \omega_{log}^2)
\f]
where
\vartable
\omega_{vis} | omega in viscous region
\omega_{log} | omega in logarithmic region
\endvartable
see eq.(15) of:
\verbatim
Menter, F., Esch, T.
"Elements of Industrial Heat Transfer Prediction"
16th Brazilian Congress of Mechanical Engineering (COBEM),
Nov. 2001
\endverbatim
or switched between these values based on the laminar-to-turbulent y+ value
derived from kappa and E. Recent tests have shown that the standard
switching method provides more accurate results for 10 < y+ < 30 when used
with high Reynolds number wall-functions and both methods provide accurate
results when used with continuous wall-functions. Based on this the
standard switching method is used by default.
This boundary condition provides a turbulence dissipation wall constraint
for low- and high-Reynolds number turbulence models.
The condition can be applied to wall boundaries for which it
- calculates \c epsilon and \c G
- specifies the near-wall epsilon value
where
\vartable
epsilon | turblence dissipation field
G | turblence generation field
\endvartable
The model switches between laminar and turbulent functions based on the
laminar-to-turbulent y+ value derived from kappa and E.
Recent tests have shown that this formulation is more accurate than
the standard high-Reynolds number form for 10 < y+ < 30 with both
standard and continuous wall-functions.
Replaces epsilonLowReWallFunction and should be used for all
low-Reynolds number models for which the epsilonLowReWallFunction BC was
recommended.
of film flow on an inclined plane by Brun et.al.
Brun, P. T., Damiano, A., Rieu, P., Balestra, G., & Gallaire, F. (2015).
Rayleigh-Taylor instability under an inclined plane.
Physics of Fluids (1994-present), 27(8), 084107.
Until C++ supports 'concepts' the only way to support construction from
two iterators is to provide a constructor of the form:
template<class InputIterator>
List(InputIterator first, InputIterator last);
which for some types conflicts with
//- Construct with given size and value for all elements
List(const label, const T&);
e.g. to construct a list of 5 scalars initialized to 0:
List<scalar> sl(5, 0);
causes a conflict because the initialization type is 'int' rather than
'scalar'. This conflict may be resolved by specifying the type of the
initialization value:
List<scalar> sl(5, scalar(0));
The new initializer list contructor provides a convenient and efficient alternative
to using 'IStringStream' to provide an initial list of values:
List<vector> list4(IStringStream("((0 1 2) (3 4 5) (6 7 8))")());
or
List<vector> list4
{
vector(0, 1, 2),
vector(3, 4, 5),
vector(6, 7, 8)
};
References:
Savill, A. M. (1993).
Some recent progress in the turbulence modelling of by-pass transition.
Near-wall turbulent flows, 829-848.
Savill, A. M. (1996).
One-point closures applied to transition.
In Turbulence and transition modelling (pp. 233-268).
Springer Netherlands.
Based on case contributed by Florian Schwertfirm, Kreuzinger und Manhart Turbulenz GmbH.
Description
Langtry-Menter 4-equation transitional SST model
based on the k-omega-SST RAS model.
References:
Langtry, R. B., & Menter, F. R. (2009).
Correlation-based transition modeling for unstructured parallelized
computational fluid dynamics codes.
AIAA journal, 47(12), 2894-2906.
Menter, F. R., Langtry, R., & Volker, S. (2006).
Transition modelling for general purpose CFD codes.
Flow, turbulence and combustion, 77(1-4), 277-303.
Langtry, R. B. (2006).
A correlation-based transition model using local variables for
unstructured parallelized CFD codes.
Phd. Thesis, Universität Stuttgart.
Implemented by Henry G. Weller, CFD Direct in collaboration with Florian
Schwertfirm, Kreuzinger und Manhart Turbulenz GmbH.
- the checking for point-connected multiple-regions now also writes the
conflicting points to a pointSet
- with the -writeSets option it now also reconstructs & writes pointSets
- the checking for point-connected multiple-regions now also writes the
conflicting points to a pointSet
- with the -writeSets option it now also reconstructs & writes pointSets
rather than being calculated on construction and stored as member data.
The convergence warning has be replaced with the 'convergence()' member
function which returns 'true' if the SVD iteration converged, otherwise 'false'.
Provides efficient integration of complex laminar reaction chemistry,
combining the advantages of automatic dynamic specie and reaction
reduction with ISAT (in situ adaptive tabulation). The advantages grow
as the complexity of the chemistry increases.
References:
Contino, F., Jeanmart, H., Lucchini, T., & D’Errico, G. (2011).
Coupling of in situ adaptive tabulation and dynamic adaptive chemistry:
An effective method for solving combustion in engine simulations.
Proceedings of the Combustion Institute, 33(2), 3057-3064.
Contino, F., Lucchini, T., D'Errico, G., Duynslaegher, C.,
Dias, V., & Jeanmart, H. (2012).
Simulations of advanced combustion modes using detailed chemistry
combined with tabulation and mechanism reduction techniques.
SAE International Journal of Engines,
5(2012-01-0145), 185-196.
Contino, F., Foucher, F., Dagaut, P., Lucchini, T., D’Errico, G., &
Mounaïm-Rousselle, C. (2013).
Experimental and numerical analysis of nitric oxide effect on the
ignition of iso-octane in a single cylinder HCCI engine.
Combustion and Flame, 160(8), 1476-1483.
Contino, F., Masurier, J. B., Foucher, F., Lucchini, T., D’Errico, G., &
Dagaut, P. (2014).
CFD simulations using the TDAC method to model iso-octane combustion
for a large range of ozone seeding and temperature conditions
in a single cylinder HCCI engine.
Fuel, 137, 179-184.
Two tutorial cases are currently provided:
+ tutorials/combustion/chemFoam/ic8h18_TDAC
+ tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D_GRI_TDAC
the first of which clearly demonstrates the advantage of dynamic
adaptive chemistry providing ~10x speedup,
the second demonstrates ISAT on the modest complex GRI mechanisms for
methane combustion, providing a speedup of ~4x.
More tutorials demonstrating TDAC on more complex mechanisms and cases
will be provided soon in addition to documentation for the operation and
settings of TDAC. Also further updates to the TDAC code to improve
consistency and integration with the rest of OpenFOAM and further
optimize operation can be expected.
Original code providing all algorithms for chemistry reduction and
tabulation contributed by Francesco Contino, Tommaso Lucchini, Gianluca
D’Errico, Hervé Jeanmart, Nicolas Bourgeois and Stéphane Backaert.
Implementation updated, optimized and integrated into OpenFOAM-dev by
Henry G. Weller, CFD Direct Ltd with the help of Francesco Contino.
Note: this reuses the existing storage rather than costly reallocation
which requires the initial allocation to be sufficient for the largest
size the ODE system might have. Attempt to set a size larger than the
initial size is a fatal error.
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;
}
}
Contributed by Alberto Passalacqua, Iowa State University
Foam::dragModels::Beetstra
Drag model of Beetstra et al. for monodisperse gas-particle flows obtained
with direct numerical simulations with the Lattice-Boltzmann method and
accounting for the effect of particle ensembles.
Reference:
\verbatim
Beetstra, R., van der Hoef, M. A., & Kuipers, J. a. M. (2007).
Drag force of intermediate Reynolds number flow past mono- and
bidisperse arrays of spheres.
AIChE Journal, 53(2), 489–501.
\endverbatim
Foam::dragModels::Tenneti
Drag model of Tenneti et al. for monodisperse gas-particle flows obtained
with particle-resolved direct numerical simulations and accounting for the
effect of particle ensembles.
Reference:
\verbatim
Tenneti, S., Garg, R., & Subramaniam, S. (2011).
Drag law for monodisperse gas–solid systems using particle-resolved
direct numerical simulation of flow past fixed assemblies of spheres.
International Journal of Multiphase Flow, 37(9), 1072–1092.
\verbatim
and added support for queue scheduling option '-q', '-queue'
Now the 'Allwmake' scripts execute 'wmake -all' to handle parallel
processing in a general way, avoiding code duplication.
wmakeCollect collects the compilation commands for the all of the object
files to be compiled into a single makefile which is passed to make to
schedule the compilations in parallel efficiently.
Before wmakeCollect can be called the lnInclude directories must be
up-to-date and after wmakeCollect the linkage stage of the compilation
must executed using wmake.
This entire process is now handled by wmake using the new '-queue' or
'-q' option to compile sections of the OpenFOAM source tree or the
entire tree efficiently. The number of cores the compilation executes
on may be specified either using the WM_NCOMPPROCS variable or the '-j'
option.
To efficiently compile OpenFOAM after a 'git pull' the '-update' option
is provided which updates lnInclude directories, dep files and removes
deprecated files and directories. This option may be used with '-q':
wmake -q -update
- patchFields now get mapped (instead of created)
- with -consistent it now maps all patches except for processor ones (they are
the only ones that are processor-local)
- all constraint patches get evaluated after mapping to bring them up to date.
Patch contributed by Mattijs Janssens
dictionary files of a particular name and extracts entries of a
particular keyword, sorting results into a unique list.
For example,
foamSearch $FOAM_TUTORIALS laplacianSchemes.default fvSchemes
produces...
default Gauss linear corrected;
default Gauss linear limited corrected 0.33;
default Gauss linear limited corrected 0.5;
default Gauss linear orthogonal;
default Gauss linear uncorrected;
default none;
Uses the fantastic foamDictionary utility.
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.
The modes of operation are set by the dimensions of the pressure field
to which this boundary condition is applied, the \c psi entry and the value
of \c gamma:
\table
Mode | dimensions | psi | gamma
incompressible subsonic | p/rho | |
compressible subsonic | p | none |
compressible transonic | p | psi | 1
compressible supersonic | p | psi | > 1
\endtable
For most applications the totalPressure boundary condition now only
requires p0 to be specified e.g.
outlet
{
type totalPressure;
p0 uniform 1e5;
}
updateCoeffs(const scalarField&) -> updateWeightedCoeffs(const scalarField&)
to avoid confusion with other specialized forms of updateCoeffs.
Patch contributed by Mattijs Janssens
Added the option '-subDict' to specify a sub-dictionary if multiple
replacement sets are present in the same file. This also provides
backward compatibility by setting '-subDict dictionaryReplacement'
Usage: foamList [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-compressibleTurbulenceModels
List compressible turbulenceModels
-functionObjects List functionObjects
-fvOptions List fvOptions
-incompressibleTurbulenceModels
List incompressible turbulenceModels
-noFunctionObjects
do not execute functionObjects
-registeredSwitches
List switches registered for run-time modification
-scalarBCs List scalar field boundary conditions (fvPatchField<scalar>)
-switches List switches declared in libraries but not set in
etc/controlDict
-unset List switches declared in libraries but not set in
etc/controlDict
-vectorBCs List vector field boundary conditions (fvPatchField<vector>)
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
Usage: foamList [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-compressibleTurbulenceModels
List compressible turbulenceModels
-functionObjects List functionObjects
-fvOptions List fvOptions
-incompressibleTurbulenceModels
List incompressible turbulenceModels
-noFunctionObjects
do not execute functionObjects
-registeredSwitches
List switches registered for run-time modification
-switches List switches declared in libraries but not set in
etc/controlDict
-unset List switches declared in libraries but not set in
etc/controlDict
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
To re-use existing 'sampleDict' files simply add the following entries:
type sets;
libs ("libsampling.so");
and run
postProcess -func sampleDict
It is probably better to also rename 'sampleDict' -> 'sample' and then run
postProcess -func sampleDict
Replaced the 'postProcess' argument to the 'write' and 'execute'
functions with the single static member 'postProcess' in the
functionObject base-class.
The use of the term 'source' in the context of post-processing is
confusing and does not properly describe the process of region
selection. The new names 'surfaceRegion' and 'volRegion' better
describe the purpose of the functionObjects which is to provide field
processing functionality limited to a specified region of space, either
a surface or volume.
The keyword 'source' is renamed 'regionType' which better describes the
purpose which is to specify the method by which the surface or volume
region is selected.
The keyword to select the name of the surface or volume region is
renamed from 'sourceName' to 'name' consistent with the other
name-changes above.
In parallel the sets are reconstructed. e.g.
mpirun -np 6 checkMesh -parallel -allGeometry -allTopology -writeSets vtk
will create a postProcessing/ folder with the vtk files of the
(reconstructed) faceSets and cellSets.
Also improved analysis of disconnected regions now also checks for point
connectivity with is useful for detecting if AMI regions have duplicate
points.
Patch contributed by Mattijs Janssens
FOAM_INST_DIR is the location of the OpenFOAM installation which defaults to
the directory containing the etc/bashrc,cshrc file. If this default is
not appropriate FOAM_INST_DIR can be set explicitly.
Description
Implementation of the k-omega-SST-DES turbulence model for
incompressible and compressible flows.
DES model described in:
\verbatim
Menter, F. R., Kuntz, M., and Langtry, R. (2003).
Ten Years of Industrial Experience with the SST Turbulence Model.
Turbulence, Heat and Mass Transfer 4, ed: K. Hanjalic, Y. Nagano,
& M. Tummers, Begell House, Inc., 625 - 632.
\endverbatim
Optional support for zonal filtering based on F1 or F2 is provided as
described in the paper.
For further details of the implementation of the base k-omega-SST model
see Foam::kOmegaSST.
The DES coefficient 'CDES' defaults to 0.61 but may be changed as
necessary.
The zonal filter filter defaults to '2' which uses "(1 - F2)" as
suggested in the paper but '0' (no filtering) and '1' which uses
"(1 - F1)" are also supported.
Replaces the dictionary access functionality of foamInfoExec and
provides additional options to edit individual entries.
Contributed by Mattijs Janssens
e.g.
functions
{
#includeFunc mag(U)
}
executes 'mag' on the field 'U' writing the field 'mag(U)'.
The equivalent post-processing command is
postProcess -func 'mag(U)'
with the more general and flexible 'postProcess' utility and '-postProcess' solver option
Rationale
---------
Both the 'postProcess' utility and '-postProcess' solver option use the
same extensive set of functionObjects available for data-processing
during the run avoiding the substantial code duplication necessary for
the 'foamCalc' and 'postCalc' utilities and simplifying maintenance.
Additionally consistency is guaranteed between solver data processing
and post-processing.
The functionObjects have been substantially re-written and generalized
to simplify development and encourage contribution.
Configuration
-------------
An extensive set of simple functionObject configuration files are
provided in
OpenFOAM-dev/etc/caseDicts/postProcessing
and more will be added in the future. These can either be copied into
'<case>/system' directory and included into the 'controlDict.functions'
sub-dictionary or included directly from 'etc/caseDicts/postProcessing'
using the '#includeEtc' directive or the new and more convenient
'#includeFunc' directive which searches the
'<etc>/caseDicts/postProcessing' directories for the selected
functionObject, e.g.
functions
{
#includeFunc Q
#includeFunc Lambda2
}
'#includeFunc' first searches the '<case>/system' directory in case
there is a local configuration.
Description of #includeFunc
---------------------------
Specify a functionObject dictionary file to include, expects the
functionObject name to follow (without quotes).
Search for functionObject dictionary file in
user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/postProcessing
- ~/.OpenFOAM/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_SITE/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_INST_DIR/site/caseDicts/postProcessing
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/postProcessing
An example of the \c \#includeFunc directive:
\verbatim
#includeFunc <funcName>
\endverbatim
postProcess
-----------
The 'postProcess' utility and '-postProcess' solver option provide the
same set of controls to execute functionObjects after the run either by
reading a specified set of fields to process in the case of
'postProcess' or by reading all fields and models required to start the
run in the case of '-postProcess' for each selected time:
postProcess -help
Usage: postProcess [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
pimpleFoam -postProcess -help
Usage: pimpleFoam [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-postProcess Execute functionObjects only
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
The functionObjects to execute may be specified on the command-line
using the '-func' option for a single functionObject or '-funcs' for a
list, e.g.
postProcess -func Q
postProcess -funcs '(div(U) div(phi))'
In the case of 'Q' the default field to process is 'U' which is
specified in and read from the configuration file but this may be
overridden thus:
postProcess -func 'Q(Ua)'
as is done in the example above to calculate the two forms of the divergence of
the velocity field. Additional fields which the functionObjects may depend on
can be specified using the '-field' or '-fields' options.
The 'postProcess' utility can only be used to execute functionObjects which
process fields present in the time directories. However, functionObjects which
depend on fields obtained from models, e.g. properties derived from turbulence
models can be executed using the '-postProcess' of the appropriate solver, e.g.
pisoFoam -postProcess -func PecletNo
or
sonicFoam -postProcess -func MachNo
In this case all required fields will have already been read so the '-field' or
'-fields' options are not be needed.
Henry G. Weller
CFD Direct Ltd.
//- Recursively search the given directory for the file
// returning the path relative to the directory or
// fileName::null if not found
fileName search(const word& file, const fileName& directory);
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
Updated and simplified 'div', 'grad' and 'mag' functionObjects by deriving from 'fieldExpression'.
Corrected the handling of cached gradients in 'grad'.
the equivalent functionality is provided by the writeRegisteredObject
functionObject in a MUCH simpler, easier and extensible manner.
functionObject: Removed the now redundant 'timeSet' function.
codedFunctionObject: Added the "codeWrite" entry
for the "write" function for consistency.
The previous method of using the "code" entry for the "write"
function was inconsistent and very confusing.
Description
This Foam::functionObject tracks a uncoupled kinematic particle cloud in the
specified velocity field of an incompressible flow (laminar, RANS or LES).
It may be used in conjunction with any transient single-phase incompressible
flow solver such as \c pisoFoam or \c pimpleFoam and tracks the particles or
parcels without affecting the the flow-field.
The \c kinematicCloud requires the the density of the fluid which is
looked-up from \c constant/transportProperties dictionary and the
acceleration due to gravity which is read from the \c constant/g file if
present or defaults to zero.
The \c kinematicCloud properties are read from the \c
constant/kinematicCloudProperties dictionary in the usual manner.
Example of function object specification:
\verbatim
tracks
{
libs ("liblagrangianFunctionObjects.so");
type icoUncoupledKinematicCloud;
}
\endverbatim
\heading Function object usage
\table
Property | Description | Required | Default value
type | Type name: icoUncoupledKinematicCloud | yes |
U | Name of the velocity field | no | U
kinematicCloud | Name of the kinematicCloud | no | kinematicCloud
\endtable
This changes simplifies the specification of functionObjects in
controlDict and is consistent with the 'libs' option in controlDict to
load special solver libraries.
Support for the old 'functionObjectLibs' name is supported for backward compatibility.
- Avoids the need for the 'OutputFilterFunctionObject' wrapper
- Time-control for execution and writing is now provided by the
'timeControlFunctionObject' which instantiates the processing
'functionObject' and controls its operation.
- Alternative time-control functionObjects can now be written and
selected at run-time without the need to compile wrapped version of
EVERY existing functionObject which would have been required in the
old structure.
- The separation of 'execute' and 'write' functions is now formalized in the
'functionObject' base-class and all derived classes implement the
two functions.
- Unnecessary implementations of functions with appropriate defaults
in the 'functionObject' base-class have been removed reducing
clutter and simplifying implementation of new functionObjects.
- The 'coded' 'functionObject' has also been updated, simplified and tested.
- Further simplification is now possible by creating some general
intermediate classes derived from 'functionObject'.
splitMeshRegions: handle flipping of faces for surface fields
subsetMesh: subset dimensionedFields
decomposePar: use run-time selection of decomposition constraints. Used to
keep cells on particular processors. See the decomposeParDict in
$FOAM_UTILITIES/parallel/decomposePar:
- preserveBaffles: keep baffle faces on same processor
- preserveFaceZones: keep faceZones owner and neighbour on same processor
- preservePatches: keep owner and neighbour on same processor. Note: not
suitable for cyclicAMI since these are not coupled on the patch level
- singleProcessorFaceSets: keep complete faceSet on a single processor
- refinementHistory: keep cells originating from a single cell on the
same processor.
decomposePar: clean up decomposition of refinement data from snappyHexMesh
reconstructPar: reconstruct refinement data (refineHexMesh, snappyHexMesh)
reconstructParMesh: reconstruct refinement data (refineHexMesh, snappyHexMesh)
redistributePar:
- corrected mapping surfaceFields
- adding processor patches in order consistent with decomposePar
argList: check that slaves are running same version as master
fvMeshSubset: move to dynamicMesh library
fvMeshDistribute:
- support for mapping dimensionedFields
- corrected mapping of surfaceFields
parallel routines: allow parallel running on single processor
Field: support for
- distributed mapping
- mapping with flipping
mapDistribute: support for flipping
AMIInterpolation: avoid constructing localPoints
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.
for consistency with the time controls in controlDict and to avoid
unnecessary confusion. All code and tutorials have been updated.
The old names 'outputControl' and 'outputInterval' are but supported for
backward compatibility but deprecated.
Simplified and generalized the handling of functionObjects which fail to
construct by removing them from the list rather than maintaining an
"enabled" switch in each functionObject.
See commit b627924a4bf104521b567d3aa3dc80c864325b1a
Allwmake: Added scripted changes for REALTYPEWIDTH and IDXTYPEWIDTH
Patch contributed by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2085
Description
This functionObject writes objects registered to the database in VTK format
using the foamToVTK library.
Currently only the writing of the cell-values of volFields is supported but
support for other field types, patch fields, Lagrangian data etc. will be
added.
Example of function object specification:
\verbatim
writeVTK1
{
type writeVTK;
functionObjectLibs ("libIOFunctionObjects.so");
...
objectNames (obj1 obj2);
}
\endverbatim
\heading Function object usage
\table
Property | Description | Required | Default value
type | type name: writeVTK | yes |
objectNames | objects to write | yes |
\endtable
Executes application functionObjects to post-process existing results.
If the "dict" argument is specified the functionObjectList is constructed
from that dictionary otherwise the functionObjectList is constructed from
the "functions" sub-dictionary of "system/controlDict"
Multiple time-steps may be processed and the standard utility time
controls are provided.
This functionality is equivalent to execFlowFunctionObjects but in a
more efficient and general manner and will be included in all the
OpenFOAM solvers if it proves effective and maintainable.
The command-line options available with the "-postProcess" option may be
obtained by
simpleFoam -help -postProcess
Usage: simpleFoam [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-postProcess Execute functionObjects only
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
Henry G. Weller
CFD Direct Ltd.
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".
See http://www.openfoam.org/mantisbt/view.php?id=2076
- .org is the file extension for emacs org-mode as well
- .orig is more to the point (.org isn't always recognized as "original")
- .original is too long, although more consistent with the convention
of source code file naming
Update script contributed by Bruno Santos
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.
In order to simplify expressions involving dimensioned internal field it
is preferable to use a simpler access convention. Given that
GeometricField is derived from DimensionedField it is simply a matter of
de-referencing this underlying type unlike the boundary field which is
peripheral information. For consistency with the new convention in
"tmp" "dimensionedInteralFieldRef()" has been renamed "ref()".
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.
Given that the type of the dimensioned internal field is encapsulated in
the GeometricField class the name need not include "Field"; the type
name is "Internal" so
volScalarField::DimensionedInternalField -> volScalarField::Internal
In addition to the ".dimensionedInternalField()" access function the
simpler "()" de-reference operator is also provided to greatly simplify
FV equation source term expressions which need not evaluate boundary
conditions. To demonstrate this kEpsilon.C has been updated to use
dimensioned internal field expressions in the k and epsilon equation
source terms.
both of which return the dimensionedInternalField for volFields only.
These will be useful in FV equation source term expressions which need
not evaluate boundary conditions.
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1938
Because C++ does not support overloading based on the return-type there
is a problem defining both const and non-const member functions which
are resolved based on the const-ness of the object for which they are
called rather than the intent of the programmer declared via the
const-ness of the returned type. The issue for the "boundaryField()"
member function is that the non-const version increments the
event-counter and checks the state of the stored old-time fields in case
the returned value is altered whereas the const version has no
side-effects and simply returns the reference. If the the non-const
function is called within the patch-loop the event-counter may overflow.
To resolve this it in necessary to avoid calling the non-const form of
"boundaryField()" if the results is not altered and cache the reference
outside the patch-loop when mutation of the patch fields is needed.
The most straight forward way of resolving this problem is to name the
const and non-const forms of the member functions differently e.g. the
non-const form could be named:
mutableBoundaryField()
mutBoundaryField()
nonConstBoundaryField()
boundaryFieldRef()
Given that in C++ a reference is non-const unless specified as const:
"T&" vs "const T&" the logical convention would be
boundaryFieldRef()
boundaryFieldConstRef()
and given that the const form which is more commonly used is it could
simply be named "boundaryField()" then the logical convention is
GeometricBoundaryField& boundaryFieldRef();
inline const GeometricBoundaryField& boundaryField() const;
This is also consistent with the new "tmp" class for which non-const
access to the stored object is obtained using the ".ref()" member function.
This new convention for non-const access to the components of
GeometricField will be applied to "dimensionedInternalField()" and "internalField()" in the
future, i.e. "dimensionedInternalFieldRef()" and "internalFieldRef()".
There is a need to specify const or non-const access to a non-const
object which is not currently possible with the "boundaryField()" access
function the const-ness of the return of which is defined by the
const-ness of the object for which it is called. For consistency with
the latest "tmp" storage class in which non-const access is obtained
with the "ref()" function it is proposed to replace the non-const form
of "boundaryField()" with "boundaryFieldRef()".
Thanks to Mattijs Janssens for starting the process of migration to
"boundaryFieldRef()" and providing a patch for the OpenFOAM and
finiteVolume libraries.
This condition creates a zero-dimensional model of an enclosed volume of
gas upstream of the inlet. The pressure that the boundary condition
exerts on the inlet boundary is dependent on the thermodynamic state of
the upstream volume. The upstream plenum density and temperature are
time-stepped along with the rest of the simulation, and momentum is
neglected. The plenum is supplied with a user specified mass flow and
temperature.
The result is a boundary condition which blends between a pressure inlet
condition condition and a fixed mass flow. The smaller the plenum
volume, the quicker the pressure responds to a deviation from the supply
mass flow, and the closer the model approximates a fixed mass flow. As
the plenum size increases, the model becomes more similar to a specified
pressure.
The expansion from the plenum to the inlet boundary is controlled by an
area ratio and a discharge coefficient. The area ratio can be used to
represent further acceleration between a sub-grid blockage such as fins.
The discharge coefficient represents a fractional deviation from an
ideal expansion process.
This condition is useful for simulating unsteady internal flow problems
for which both a mass flow boundary is unrealistic, and a pressure
boundary is susceptible to flow reversal. It was developed for use in
simulating confined combustion.
tutorials/compressible/rhoPimpleFoam/laminar/helmholtzResonance:
helmholtz resonance tutorial case for plenum pressure boundary
This development was contributed by Will Bainbridge
Also added the new prghTotalHydrostaticPressure p_rgh BC which uses the
hydrostatic pressure field as the reference state for the far-field
which provides much more accurate entrainment is large open domains
typical of many fire simulations.
The hydrostatic field solution is controlled by the optional entries in
the fvSolution.PIMPLE dictionary, e.g.
hydrostaticInitialization yes;
nHydrostaticCorrectors 5;
and the solver must also be specified for the hydrostatic p_rgh field
ph_rgh e.g.
ph_rgh
{
$p_rgh;
}
Suitable boundary conditions for ph_rgh cannot always be derived from
those for p_rgh and so the ph_rgh is read to provide them.
To avoid accuracy issues with IO, restart and post-processing the p_rgh
and ph_rgh the option to specify a suitable reference pressure is
provided via the optional pRef file in the constant directory, e.g.
dimensions [1 -1 -2 0 0 0 0];
value 101325;
which is used in the relationship between p_rgh and p:
p = p_rgh + rho*gh + pRef;
Note that if pRef is specified all pressure BC specifications in the
p_rgh and ph_rgh files are relative to the reference to avoid round-off
errors.
For examples of suitable BCs for p_rgh and ph_rgh for a range of
fireFoam cases please study the tutorials in
tutorials/combustion/fireFoam/les which have all been updated.
Henry G. Weller
CFD Direct Ltd.
Patch contributed by Juho Peltola, VTT
The new JohnsonJacksonSchaefferFrictionalStress model is included and
the LBend tutorial case to demonstrate the need for the changes to the
frictional stress models.
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=2058
The joint-space dynamics is solved on the master processor only and the
resulting joint-state distributed to the slave processors on which the
body-state is then updated. This guarantees consistency of the body
position and orientation on all processors.
The motion of the bodies is integrated using the rigidBodyDynamics
library with joints, restraints and external forces.
The mesh-motion is interpolated using septernion averaging.
This development is sponsored by Carnegie Wave Energy Ltd.
inline Foam::vector Foam::septernion::transformPoint(const vector& v) const
{
return r().transform(v - t());
}
Now there is a 1:1 correspondence between septernion and
spatialTransform and a septernion constructor from spatialTransform
provided.
Additionally "septernion::transform" has been renamed
"septernion::transformPoint" to clarify that it transforms coordinate
points rather than displacements or other relative vectors.
'w' is now obtained from 'v' using the relation w = sqrt(1 - |sqr(v)|)
and 'v' is stored in the joint state field 'q' and integrated in the
usual manner but corrected using quaternion transformations.
Currently supported solvers: symplectic, Newmark, CrankNicolson
The symplectic solver should only be used if iteration over the forces
and body-motion is not required. Newmark and CrankNicolson both require
iteration to provide 2nd-order behavior.
See applications/test/rigidBodyDynamics/spring for an example of the
application of the Newmark solver.
This development is sponsored by Carnegie Wave Energy Ltd.
This is a more convenient way of maintaining the state or multiple
states (for higher-order integration), storing, retrieving and passing
between processors.
Included for backward-compatibility with the 6-DoF solver but in the
future will be re-implemented as a joint rather than body restraint and
accumulated in tau (internal forces) rather than fx (external forces).
applications/test/rigidBodyDynamics/spring: Test of the linear spring with damper restraint
Damped simple harmonic motion of a weight on a spring is simulated and
the results compared with analytical solution
Test-spring
gnuplot spring.gnuplot
evince spring.eps
This development is sponsored by Carnegie Wave Energy Ltd.
e.g. (fvc::interpolate(HbyA) & mesh.Sf()) -> fvc::flux(HbyA)
This removes the need to create an intermediate face-vector field when
computing fluxes which is more efficient, reduces the peak storage and
improved cache coherency in addition to providing a simpler and cleaner
API.
dotInterpolate interpolates the field and "dots" the resulting
face-values with the vector field provided which removes the need to
create a temporary field for the interpolate. This reduces the peak
storage of OpenFOAM caused by the divergence of the gradient of vector
fields, improves memory management and under some conditions decreases
run-time.
This development is based on a patch contributed by Paul Edwards, Intel.
to allow the construction of vtables for virtual member functions
involving the inner-products of fields for which a "NotImplemented"
specialization for scalar is provided.
Based on the principles, algorithms, data structures and notation
presented in the book:
Featherstone, R. (2008).
Rigid body dynamics algorithms.
Springer.
This development is sponsored by Carnegie Wave Energy Ltd.
//- Disallow default shallow-copy assignment
//
// Assignment of UList<T> may need to be either shallow (copy pointer)
// or deep (copy elements) depending on context or the particular type
// of list derived from UList and it is confusing and prone to error
// for the default assignment to be either. The solution is to
// disallow default assignment and provide separate 'shallowCopy' and
// 'deepCopy' member functions.
void operator=(const UList<T>&) = delete;
//- Copy the pointer held by the given UList.
inline void shallowCopy(const UList<T>&);
//- Copy elements of the given UList.
void deepCopy(const UList<T>&);
Contributed by Mattijs Janssens.
1. Any non-blocking data exchange needs to know in advance the sizes to
receive so it can size the buffer. For "halo" exchanges this is not
a problem since the sizes are known in advance but or all other data
exchanges these sizes need to be exchanged in advance.
This was previously done by having all processors send the sizes of data to
send to the master and send it back such that all processors
- had the same information
- all could work out who was sending what to where and hence what needed to
be received.
This is now changed such that we only send the size to the
destination processor (instead of to all as previously). This means
that
- the list of sizes to send is now of size nProcs v.s. nProcs*nProcs before
- we cut out the route to the master and back by using a native MPI
call
It causes a small change to the API of exchange and PstreamBuffers -
they now return the sizes of the local buffers only (a labelList) and
not the sizes of the buffers on all processors (labelListList)
2. Reversing the order of the way in which the sending is done when
scattering information from the master processor to the other
processors. This is done in a tree like fashion. Each processor has a
set of processors to receive from/ send to. When receiving it will
first receive from the processors with the least amount of
sub-processors (i.e. the ones which return first). When sending it
needs to do the opposite: start sending to the processor with the
most amount of sub-tree since this is the critical path.
The blocks may be specified directly in terms of the size and location in the
parent matrix or with the size obtained from a template specified
VectorSpace or MatrixSpace type.
This new approach to 0 initialization is simpler, cleaner, more readable
and more efficient. The rest of the OpenFOAM code will be updated in
due course.
Patch contributed by Bruno Santos:
- "etc/config.sh/CGAL":
- Indented the contents of the recently added if block.
- Added comment about using system versions.
- Library paths are now only added if the respective version is not "boost-system" and "cgal-system".
- "src/renumber/Allwmake":
It now relies on the previous file to get the version for
Boost (the same way as in "makeCGAL"). This is so that it will also
build "SloanRenumber" if "boost_version" is set to "boost-system".
- "applications/utilities/mesh/generation/Allwmake":
It now also relies on the script "config.sh/CGAL" to get the
version for CGAL. If "cgal_version" is set to "cgal-system", it
will now also build "foamy*Mesh" utilities and respective
libraries.
Resolves report http://www.openfoam.org/mantisbt/view.php?id=1232
The row-start pointer array provided performance benefits on old
computers but now that computation is often cache-miss limited the
benefit of avoiding a integer multiply is more than offset by the
addition memory access into a separately allocated array.
With the new addressing scheme LUsolve is 15% faster.
in terms of the rotation tensor \c E and translation vector \c r .
See Chapter 2 and Appendix A in reference:
Featherstone, R. (2008).
Rigid body dynamics algorithms.
Springer.
This work is sponsored by Carnegie Wave Energy Ltd
Henry G. Weller
CFD Direct
Based on definitions in chapter 2 of the book:
Featherstone, R. (2008).
Rigid body dynamics algorithms.
Springer.
This work is sponsored by Carnegie Wave Energy Ltd
The particular rotation sequence is specified via the enumeration:
//- Euler-angle rotation sequence
enum rotationSequence
{
ZYX, ZYZ, ZXY, ZXZ, YXZ, YXY, YZX, YZY, XYZ, XYX, XZY, XZX
};
and provided as an argument to the constructor from Euler-angles
//- Construct a quaternion given the three Euler angles:
inline quaternion
(
const rotationSequence rs,
const vector& angles
);
and conversion to Euler-angles:
//- Return a vector of euler angles corresponding to the
// specified rotation sequence
inline vector eulerAngles(const rotationSequence rs) const;
Provides '(i, j)' element access and general forms of inner and outer
products, transpose etc. for square and rectangular VectorSpaces.
VectorSpaces default to be column-vectors as before whereas row-vectors
may be represented as 1xn MatrixSpaces. In the future it may be
preferable to create a specializations of VectorSpace for column- and
maybe row-vectors but it would add complexity to MatrixSpace to handle
all the type combinations.
Tensor is now a 3x3 specialization of MatrixSpace.
Sub-block const and non-const access is provided via the
'.block<SubTensor, RowStart, ColStart>()' member functions. Consistent
sub-block access is also provide for VectorSpace so that columns of
MatrixSpaces may be accessed and substituted.
These new classes will be used to create a more extensive set of
primitive vector and tensor types over the next few weeks.
Henry G. Weller
CFD Direct
Foam::direction is an unsigned type which makes it easier for the
compiler to pickup and report errors in the instantiation of
VectorSpaces and associated types.
1. "foamCompiler" was changed to a more permanent "WM_COMPILER_TYPE"
environment variable, so that it can be used by 3rd party
installation scripts, such as "makeGcc", "makeLLVM" and so on. More
on this will be provided in issue #1215.
2. The script functions such as "_foamSource()" and "_foamAddPath()"
were moved to a new file "etc/config.sh/functions". It has the
ability to set or unset, depending on whether "WM_BASH_FUNCTIONS" is
defined or not. This allows for these functions to be reused by
other scripts, such as "makeGcc".
3. The script "etc/config.sh/CGAL" relies on whether a local
environment variable "SOURCE_CGAL_VERSIONS_ONLY" is defined or not,
so that it will load only the version settings if it's defined. This
is to make it easier to call this script from "makeCGAL". Although
it still feels a bit of a clunky hack, but I didn't manage to deduce
any other way we could do this :( I didn't add indentation within
the if-block, to make it easier to read the changes. In addition,
the local variable "common_path" is used to shorten the length of
the lines and use slightly less repeated code.
4. Added another new script "etc/config.sh/compiler", which has only
the version numbers for the compilers taken out from the "settings"
file. It currently depends on "WM_COMPILER_TYPE" for setting the
variables, the same way it did with "foamCompiler". This script is
now always sourced from the "settings" file, for the following
reasons:
- "makeGCC" and "makeLLVM" can now take advantage of this script file.
- The example "compiler" script (detailed next) can rely on this
script file and then override parameters on-demand, as well as
allowing for system compilers to have dedicated settings, such as
setting "WM_CC". This is similar to how the example environment
script for "paraview" works.
5. To the script "etc/config.sh/example/compiler" were added a few more examples:
- It now starts with a block where it first loads the default "compiler" script.
- Has a "WM_COMPILER=Gcc48u" case example for when we try to use GCC
4.8 in Ubuntu 15.10. This is just to give the idea that in a
particular system, we might have several system-wide compiler
versions. For example, in Ubuntu 15.10, there is GCC 4.7, 4.8 and
5.2, which could be used for testing performances or compatibility
with some other 3rd party library.
- Has the "WM_COMPILER=Icc" case example, related to the original bug
report, where "WM_CC=icc" and "WM_CXX=icpc", so that the user then
simply copies this file to their own local preferences folder.
6. Small bug fix in "etc/config.sh/mpi", where unsetting "minBufferSize" was missing at the end of the script.
7. Small change in "etc/config.sh/paraview", where "CMAKE_ROOT" is set
along with "CMAKE_HOME". This is due to a rare issue that occurs on
people's systems where they have a custom system-wide CMake version
installed and which is used by having "CMAKE_ROOT" set on that
environment. This can mess up OpenFOAM's custom ParaView builds,
given that conflicting CMake versions can lead to not building
ParaView at all.
- For more details about "CMAKE_ROOT":
https://cmake.org/Wiki/CMake_Useful_Variables [^]
8. The scripts "_foamAddPath _foamAddLib _foamAddMan" were not being
unset at the end of "settings". They are now unset at the end of
"bashrc", through a call to the new double-use "functions" script.
Additionally all references to "foamCompiler" have been changed to
"WM_COMPILER_TYPE".
See also http://www.openfoam.org/mantisbt/view.php?id=1232
Wall-velocity condition to be used in conjunction with the single rotating
frame (SRF) model (see: FOAM::SRFModel)
The condition applies the appropriate rotation transformation in time and
space to determine the local SRF velocity of the wall.
\f[
U_p = - U_{p,srf}
\f]
where
\vartable
U_p = patch velocity [m/s]
U_{p,srf} = SRF velocity
\endvartable
The normal component of \f$ U_p \f$ is removed to ensure 0 wall-flux even
if the wall patch faces are irregular.
\heading Patch usage
Example of the boundary condition specification:
\verbatim
myPatch
{
type SRFWallVelocity;
value uniform (0 0 0); // Initial value
}
\endverbatim
DebugInfo:
Report an information message using Foam::Info if the local debug
switch is true
DebugInFunction:
Report an information message using Foam::Info for FUNCTION_NAME in
file __FILE__ at line __LINE__ if the local debug switch is true
which reduces the number of potential problems with the reuse of
temporary objects.
In order to avoid unnecessary creation of tmp's referring to temporary
objects the assignment operator now transfers ownership of the object
and resets the argument.
The deprecated non-const tmp functionality is now on the compiler switch
NON_CONST_TMP which can be enabled by adding -DNON_CONST_TMP to EXE_INC
in the Make/options file. However, it is recommended to upgrade all
code to the new safer tmp by using the '.ref()' member function rather
than the non-const '()' dereference operator when non-const access to
the temporary object is required.
Please report any problems on Mantis.
Henry G. Weller
CFD Direct.
in case of tmp misuse.
Simplified tmp reuse pattern in field algebra to use tmp copy and
assignment rather than the complex delayed call to 'ptr()'.
Removed support for unused non-const 'REF' storage of non-tmp objects due to C++
limitation in constructor overloading: if both tmp(T&) and tmp(const T&)
constructors are provided resolution is ambiguous.
The turbulence libraries have been upgraded and '-DCONST_TMP' option
specified in the 'options' file to switch to the new 'tmp' behavior.
This change requires that the de-reference operator '()' returns a
const-reference to the object stored irrespective of the const-ness of
object stored and the new member function 'ref()' is provided to return
an non-const reference to stored object which throws a fatal error if the
stored object is const.
In order to smooth the transition to this new safer 'tmp' the now
deprecated and unsafe non-const de-reference operator '()' is still
provided by default but may be switched-off with the compilation switch
'CONST_TMP'.
The main OpenFOAM library has already been upgraded and '-DCONST_TMP'
option specified in the 'options' file to switch to the new 'tmp'
behavior. The rest of OpenFOAM-dev will be upgraded over the following
few weeks.
Henry G. Weller
CFD Direct
To be used instead of zeroGradientFvPatchField for temporary fields for
which zero-gradient extrapolation is use to evaluate the boundary field
but avoiding fields derived from temporary field using field algebra
inheriting the zeroGradient boundary condition by the reuse of the
temporary field storage.
zeroGradientFvPatchField should not be used as the default patch field
for any temporary fields and should be avoided for non-temporary fields
except where it is clearly appropriate;
extrapolatedCalculatedFvPatchField and calculatedFvPatchField are
generally more suitable defaults depending on the manner in which the
boundary values are specified or evaluated.
The entire OpenFOAM-dev code-base has been updated following the above
recommendations.
Henry G. Weller
CFD Direct
Vastly reduces the scattering and churning behaviour of packed beds.
Development provided by Will Bainbridge <github.com/will-bainbridge>
See also http://www.openfoam.org/mantisbt/view.php?id=1994
RunFunctions: Added "isTest()" argument parsing function
tutorials: Updated Allrun scripts to propagate the "-test" option
tutorials: Removed the lower Alltest scripts and updated the Allrun to
use the "isTest()" function to handle test-specific operation
The boundary conditions of HbyA are now constrained by the new "constrainHbyA"
function which applies the velocity boundary values for patches for which the
velocity cannot be modified by assignment and pressure extrapolation is
not specified via the new
"fixedFluxExtrapolatedPressureFvPatchScalarField".
The new function "constrainPressure" sets the pressure gradient
appropriately for "fixedFluxPressureFvPatchScalarField" and
"fixedFluxExtrapolatedPressureFvPatchScalarField" boundary conditions to
ensure the evaluated flux corresponds to the known velocity values at
the boundary.
The "fixedFluxPressureFvPatchScalarField" boundary condition operates
exactly as before, ensuring the correct flux at fixed-flux boundaries by
compensating for the body forces (gravity in particular) with the
pressure gradient.
The new "fixedFluxExtrapolatedPressureFvPatchScalarField" boundary
condition may be used for cases with or without body-forces to set the
pressure gradient to compensate not only for the body-force but also the
extrapolated "HbyA" which provides a second-order boundary condition for
pressure. This is useful for a range a problems including impinging
flow, extrapolated inlet conditions with body-forces or for highly
viscous flows, pressure-induced separation etc. To test this boundary
condition at walls in the motorBike tutorial case set
lowerWall
{
type fixedFluxExtrapolatedPressure;
}
motorBikeGroup
{
type fixedFluxExtrapolatedPressure;
}
Currently the new extrapolated pressure boundary condition is supported
for all incompressible and sub-sonic compressible solvers except those
providing implicit and tensorial porosity support. The approach will be
extended to cover these solvers and options in the future.
Note: the extrapolated pressure boundary condition is experimental and
requires further testing to assess the range of applicability,
stability, accuracy etc.
Henry G. Weller
CFD Direct Ltd.
with optional specification of the mark/space ratio
Templated square-wave function with support for an offset level.
\f[
a square(f (t - t_0)) s + l
\f]
where
\f$ square(t) \f$ is the square-wave function in range \f$ [-1, 1] \f$
with a mark/space ratio of \f$ r \f$
\vartable
symbol | Description | Data type | Default
a | Amplitude | Function1<scalar> |
f | Frequency [1/s] | Function1<scalar> |
s | Type scale factor | Function1<Type> |
l | Type offset level | Function1<Type> |
t_0 | Start time [s] | scalar | 0
r | mark/space ratio | scalar | 1
t | Time [s] | scalar
\endvartable
Example for a scalar:
\verbatim
<entryName> square;
<entryName>Coeffs
{
frequency 10;
amplitude 0.1;
scale 2e-6;
level 2e-6;
}
\endverbatim
etc/config.sh and etc/config.csh
This structure is more convenient to add support for other shells, e.g. zsh, fish etc.
Resolves feature request to simplify support for other shells in
http://www.openfoam.org/mantisbt/view.php?id=1232
To see the different behavior of flow through and around the blockage
change D in constant/fvOptions:
// D 100; // Very little blockage
// D 200; // Some blockage but steady flow
// D 500; // Slight waviness in the far wake
D 1000; // Fully shedding behavior
Templated sine function with support for an offset level.
\f[
a sin(2 \pi f (t - t_0)) s + l
\f]
where
\vartable
symbol | Description | Data type
a | Amplitude | Function1<scalar>
f | Frequency [1/s] | Function1<scalar>
s | Type scale factor | Function1<Type>
l | Type offset level | Function1<Type>
t_0 | Start time [s] | scalar
t | Time [s] | scalar
\endvartable
Function1 is an abstract base-class of run-time selectable unary
functions which may be composed of other Function1's allowing the user
to specify complex functions of a single scalar variable, e.g. time.
The implementations need not be a simple or continuous functions;
interpolated tables and polynomials are also supported. In fact form of
mapping between a single scalar input and a single primitive type output
is supportable.
The primary application of Function1 is in time-varying boundary
conditions, it also used for other functions of time, e.g. injected mass
is spray simulations but is not limited to functions of time.
Description
Templated sine function with support for an offset level.
\f[
a sin(2 \pi f (t - t_0)) s + l
\f]
where
\vartable
a | Amplitude
f | Frequency [1/s]
s | Type scale factor
l | Type offset level
t_0 | Start time [s]
t | Time [s]
\endvartable
Example for a scalar:
\verbatim
<entryName> sine;
<entryName>Coeffs
{
frequency 10;
amplitude 0.1;
scale 2e-6;
level 2e-6;
}
\endverbatim
Example for a vector:
\verbatim
<entryName> sine;
<entryName>Coeffs
{
frequency 10;
amplitude 1;
scale (1 0.1 0);
level (10 1 0);
}
\endverbatim
PV4FoamReaders: Updated to build with ParaView-5.0.0
paraFoam: Updated to load PV4FoamReaders for ParaView-5.0.0
Currently this is experimental but if it becomes clear that ParaView-4
and ParaView-5 are and will remain consistent with respect to readers
the plan is to rename
PV4 -> PV
or
PV4 -> PV45 if it is assumed that PV6 may need to be different.
Removed inconsistent binary output.
Removed unused and IO-inconsistent functions.
Simplified the handling of backward-compatible constant value:
Removed the unnecessary CompatibilityConstant,
Updated Constant and DataEntryNew to handle constant value construction.
// Polynomial functions and interpolation do evaluate to label
// Instead evaluate a scalar and convert to label as appropriate
// makeDataEntryType(PolynomialEntry, label);
// makeDataEntryType(CSV, label);
// makeDataEntryType(Table, label);
// makeDataEntryType(TableFile, label);
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1987
If the mean velocity force is applied to a cyclic patch for parallel
runs include contributions from processorCyclic patches generated
from the decomposition of the cyclic patch
When restarting form a previous calculation, the averaging is continuous or
may be restarted using the \c restartOnRestart option.
The averaging process may be restarted after each calculation output time
using the \c restartOnOutput option or restarted periodically using the \c
periodicRestart option and setting \c restartPeriod to the required
averaging period.
Example of function object specification:
\verbatim
fieldAverage1
{
type fieldAverage;
functionObjectLibs ("libfieldFunctionObjects.so");
...
restartOnRestart false;
restartOnOutput false;
periodicRestart false;
restartPeriod 0.002;
fields
(
U
{
mean on;
prime2Mean on;
base time;
window 10.0;
windowName w1;
}
p
{
mean on;
prime2Mean on;
base time;
}
);
}
\endverbatim
\heading Function object usage
\table
Property | Description | Required | Default value
type | type name: fieldAverage | yes |
restartOnRestart | Restart the averaging on restart | no | no
restartOnOutput | Restart the averaging on output | no | no
periodicRestart | Periodically restart the averaging | no | no
restartPeriod | Periodic restart period | conditional |
fields | list of fields and averaging options | yes |
\endtable
in decomposeParDict.
This default number of processors may be overridden by the new "-np"
option to runParallel which must be specified before the application
name e.g.:
runParallel -np 4 pisoFoam
which may be optionally overridden by version-specific rules.
For example the default rules for gcc on GNU/Linux x86_64 are in the
wmake/rules/linux64Gcc directory. If there is a need to change any of
the rules for a specific version of gcc, e.g. gcc-4.8.4 the directory
wmake/rules/linux64Gcc48 may be created into which any of the language
files may be provided containing the rules to override the defaults.
This function object calculates mole-fraction fields from the mass-fraction
fields of the psi/rhoReactionThermo and caches them for output and further
post-processing.
The names of the mole-fraction fields are obtained from the corresponding
mass-fraction fields prepended by "X_"
Example of function object specification:
moleFractions
{
type psiReactionThermoMoleFractions;
}
or
moleFractions
{
type rhoReactionThermoMoleFractions;
}
depending on the thermodynamics package used in the solver.
Evaluates the contact angle as a function of the optionally specified
temperature field (defaults to T). The "theta0" function is provided as
a DataEntry currently supporting:
CompatibilityConstant
constant
csvFile
polynomial
table
tableFile
It is not clear what form an fvOptions source should take as f is not a
transported dynamic field. For the moment the fvOptions source from the
f-equation has been removed until there is a specific need which will
show what the form should be.
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1955
The Makefiles are now in the makefiles sub-directory
The "-f | -force" option in wmakeLnInclude is now "-u | -update" for
consistency with the other scripts.
The "Usage" entry in the headers is now consistently formatted in all
scripts.
wcleanPlatform is a more general and cleaner version of wcleanMachine
supporting the "-all" option to provide the equivalent of wcleanAll.
Both wcleanMachine and wcleanAll are now deprecated and will be removed
for the next major release.
Updates lnInclude directories and dep files before compilation. This is
useful to apply following a "git pull" to ensure consistency between the
source files, dep files and links.
Searches all the "src" and "application" directories of the project for
broken symbolic links for source code files and then remove all .dep
files that relate to the files that no longer exist. Must be executed
in main project source code folder: $WM_PROJECT_DIR
Patch provided by Bruno Santos
Resolves feature-request http://www.openfoam.org/mantisbt/view.php?id=1941
It will exit after removing the empty folders and it will not do the
other standard "wclean" operations. This replaces the functionality
provided by "wrmdepold".
Patch provided by Bruno Santos
Starting from an initial buffer size of 256 it is incremented in steps
of 256 upto the maximum of 4096 as required.
Based on patch provided by Bruno Santos
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1944
Drag model for gas-liquid system of Tomiyama et al.
Reference:
"Drag coefficients of single bubbles under normal and microgravity
conditions"
Tomiyama, A., Kataoka, I., Zun, I., Sakaguchi, T.
JSME International Series B, Fluids and Thermal Engineering,
Vol. 41, 1998, pp. 472-479
Provided by Alberto Passalacq
It is better to declare the namespace of each function in the C file
rather than "open" the namespace as this may lead to inconsistencies
between the declaration in the H files and definition in the C file.
fvOptions are transferred to the database on construction using
fv::options::New which returns a reference. The same function can be
use for construction and lookup so that fvOptions are now entirely
demand-driven.
The abstract base-classes for fvOptions now reside in the finiteVolume
library simplifying compilation and linkage. The concrete
implementations of fvOptions are still in the single monolithic
fvOptions library but in the future this will be separated into smaller
libraries based on application area which may be linked at run-time in
the same manner as functionObjects.
Patch provided by Timo Niemi
Resolved bug-report http://www.openfoam.org/mantisbt/view.php?id=1636
This correction corresponds to option 3 of the options proposed by Timo:
Define both ECont and EDisp to be the total emission per surface area,
apply multiplication by 4 in cloudAbsorptionEmission model (the only
place that uses EDisp?). Do not multiply E in P1 at all, divide both
ECont and EDisp in fvDOM.
Moved correctNut call from constructors to the new validate function to
avoid problems with construction order and field availability for the
calculation of nut.
To ensure nut is physical and consistent with the turbulence fields the
validate function should be called after the construction of the
turbulence model, fvOptions and any other fields that the calculation of
nut might depend on.
This is useful when applying an experimentally obtained profile as an
inlet condition:
Example of the boundary condition specification:
\verbatim
myPatch
{
type fixedProfile;
profile csvFile;
profileCoeffs
{
nHeaderLine 0; // Number of header lines
refColumn 0; // Reference column index
componentColumns (1 2 3); // Component column indices
separator ","; // Optional (defaults to ",")
mergeSeparators no; // Merge multiple separators
fileName "Uprofile.csv"; // name of csv data file
outOfBounds clamp; // Optional out-of-bounds handling
interpolationScheme linear; // Optional interpolation scheme
}
direction (0 1 0);
origin 0;
}
\endverbatim
or a simple polynomial profile:
Example setting a parabolic inlet profile for the PitzDaily case:
\verbatim
inlet
{
type fixedProfile;
profile polynomial
(
((1 0 0) (0 0 0))
((-6200 0 0) (2 0 0))
);
direction (0 1 0);
origin 0.0127;
}
\endverbatim
Based on code provided by Hassan Kassem:
http://www.openfoam.org/mantisbt/view.php?id=1922
across all the phases in an Eulerian multi-phase simulation.
Intended to be used with copiedFixedValue to ensure that phase wall
temperature are consistent:
- Set 'fixedMultiPhaseHeatFlux' boundary for one of the phases
- Use 'copiedFixedValue' for all the other phases.
Based on code provided by Juho Peltola
Provides run-time selection of buoyancy sources for compressible solvers
Replaces the built-in buoyancy sources in XiFoam, reactingFoam and
rhoReactingFoam.
e.g. in constant/fvOptions specify
momentumSource
{
type buoyancyForce;
buoyancyForceCoeffs
{
fieldNames (U);
}
}
and optionally specify the buoyancy energy source in the enthalpy
equation:
energySource
{
type buoyancyEnergy;
buoyancyEnergyCoeffs
{
fieldNames (h);
}
}
or internal energy equation
energySource
{
type buoyancyEnergy;
buoyancyEnergyCoeffs
{
fieldNames (e);
}
}
New lift model supporting near-wall damping using the new
wallDampingModels.
e.g.
lift
(
(air in water)
{
type wallDamped;
lift
{
type constantCoefficient;
Cl 0.5;
}
wallDamping
{
type linear;
Cd 0.5;
}
}
);
in which a linear near-wall damping function min(y/(Cd*d), 1) is applied to the constant
coefficient lift model. Additional wall-damping functions will be added.
to allow iteration over the energy equations to improve stability for phase-change.
Additionally if nEnergyCorrectors is set to 0 the energy equations are
not solved which may be beneficial during the startup of some cases.
Usage: createTurbulenceFields [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-fields <wordReList>
specify which turbulence fields (k, epsilon, omega, R) to
write - eg '(k omega)' or '(R)' or '(.*)'.
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
Resolves feature request http://www.openfoam.org/mantisbt/view.php?id=1912
Now solvers return solver performance information for all components
with backward compatibility provided by the "max" function which created
the scalar solverPerformance from the maximum component residuals from
the SolverPerformance<Type>.
The residuals functionObject has been upgraded to support
SolverPerformance<Type> so that now the initial residuals for all
(valid) components are tabulated, e.g. for the cavity tutorial case the
residuals for p, Ux and Uy are listed vs time.
Currently the residualControl option of pimpleControl and simpleControl
is supported in backward compatibility mode (only the maximum component
residual is considered) but in the future this will be upgraded to
support convergence control for the components individually.
This development started from patches provided by Bruno Santos, See
http://www.openfoam.org/mantisbt/view.php?id=1824
Description
Incompressible gas equation of state using the Boussinesq approximation for
the density as a function of temperature only:
\verbatim
rho = rho0*(1 - beta*(T - T0))
\endverbatim
To be used with the buoyantPimpleFoam and buoyantSimpleFoam solvers as
an alternative to using buoyantBoussinesqPimpleFoam or
buoyantBoussinesqSimpleFoam, providing consistency with all other
solvers and utilities using the thermodynamics package in OpenFOAM.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
