"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.
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.
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.
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;
}
}
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.
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
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
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.
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
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
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
