The editor must be specified by configuring the EDITOR environment
variable. For example to use the 'gedit' editor, the following entry
could be added to the user's .bashrc file:
export EDITOR=gedit
by printing their contents or lines which match a search string.
Usage: ${0##*/} [OPTIONS] <filename>
options:
-a | -applications search for the file from the \$FOAM_APP directory
-d | -dir <dir> specify search directory
-f | -files find wmake 'files' file associated with searched file
-h | -help help
-i | -isearch <string> searches files for a <string>, case insensitive
-m | -modules search for the file from the \$FOAM_MODULES directory
-n | -numbers print line numbers with file output
-o | -options find wmake 'options' file associated with searched file
-p | -print print the file(s)
-s | -search <string> searches files for a <string>, case sensitive
-t | -tutorials search for the file from the \$FOAM_TUTORIALS directory
Finds one or more files in OpenFOAM and optionally processes the contents by:
+ printing the file ('-print' option);
+ printing lines within the file matching a search string ('-search' option).
With source code files, can locate the 'files' and 'options' files associated
with their compilation using 'wmake'.
By default, files are searched from the src (\$FOAM_SRC) directory.
Alternatively the '-dir' option allows the user to specify the search directory
The '-applications', '-modules' and '-tutorials' options specifically set the
search path to the \$FOAM_APP, \$FOAM_MODULES and \$FOAM_TUTORIALS directories,
respectively.
Examples:
foamFind -print wallHeatFlux.C | less
+ click space bar to scroll down
+ enter line number (after ":") to jump to line
+ enter "/text" to search for "text" (or any other string)
foamFind -applications -isearch "momentumtransport" -options fluid.C
foamFind -numbers -search laminar BirdCarreau.C
For a case extruding patches left and right:
sourcePatches (left right);
if the optional zoneNames entry is also specified in extrudeMeshDict
zoneNames (leftCells rightCells);
the cells extruded from the left patch are added to the leftCells cellZone and
the cells extruded from the right patch are added to the rightCells cellZone.
Alternatively if a single zone name is specified, e.g.
zoneNames (extrudedCells);
then cells extruded from the left and right patches are added to the
extrudedCells cellZone.
If the number of patches to extrude is large it might be more convenient for
the cells extruded from each patch to be added to a cellZone named the same as
each patch, this option is selected by setting zoneNames to patchNames:
zoneNames (patchNames);
This utility is superseded by the much more general transformPoints. A
rotation between vectors (0 1 0) and (0.707107 0.707107 0), and a
corresponding transformation of all vector and tensor fields, can be
achieved with the following call to transformPoints:
transformPoints "rotate=((0 1 0) (0.707107 0.707107 0))" -rotateFields
This function can now be run interactively using the following command:
foamPostProcess -func "cylindrical(origin=(0 0 0), axis=(0 0 1), U)"
Or it can be executed at run time by adding the following entry in the
system/functions file:
#includeFunc cylindrical(origin=(0 0 0), axis=(0 0 1), U)
for the multiValveEngine fvMeshMover. This replaced the hard-coded messages
printed by the multiValveEngine class, providing automatic logging of the piston
and valve speed and position and easy user extension or replacement to provide
additional case-specific diagnostics without having to hack the core
multiValveEngine code. A functionObject configuration file is provided so that
the simple line
can be added to the system/functions file to enable this functionObject.
A new nonConformalMappedWall patch type has been added which can couple
between different regions of a multi-region simulation. This patch type
uses the same intersection algorithm as the nonConformalCyclic patch,
which is used for coupling sections of a mesh within the same region.
The nonConformalMappedWall provides some advantages over the existing
mappedWall patches:
- The connection it creates is not interpolative. It creates a pair of
coupled finite-volume faces wherever two opposing faces overlap.
There is therefore no interpolation error associated with mapping
values across the coupling.
- Faces (or parts of faces) which do not overlap are not normalised
away by an interpolation or averaging process. Instead, they are
assigned an alternative boundary condition; e.g., an external
constraint, or even another non-conformal cyclic or mapped wall.
This makes the system able to construct partially-overlapping
couplings.
- The direct non-interpolative transfer of values between the patches
makes the method equivalent to a conformal coupling. Properties of
the solution algorithm, such as conservation and boundedness, are
retained regardless of the non-conformance of the boundary meshes.
- All constructed finite volume faces have accurate centre points.
This makes the method second order accurate in space.
Usage:
Non-conformal mapped wall couplings are constructed as the last stage of
a multi-region meshing process. First, a multi-region mesh is
constructed in one of the usual ways, but with the boundaries specified
as standard non-coupled walls instead of a special mapped type. Then,
createNonConformalCouples is called to construct non-conformal mapped
patches that couple overlapping parts of these non-coupled walls. This
process is very similar to the construction of non-conformal cyclics.
createNonConformalCouples requires a
system/createNonConformalCouplesDict in order to construct non-conformal
mapped walls. Each coupling is specified in its own sub-dictionary, and
a "regions" entry is used to specify the pair of regions that the
non-conformal mapped wall will couple. Non-conformal cyclics can also be
created using the same dictionary, and will be assumed if the two
specified regions are the same, or if a single "region" entry is
specified. For example:
// Do not modify the fields
fields no;
// List of non-conformal couplings
nonConformalCouples
{
// Non-conformal cyclic interface. Only one region is specified.
fluidFluid
{
region fluid;
originalPatches (nonCoupleRotating nonCoupleStationary);
}
// Non-conformal mapped wall interface. Two different regions
// have been specified.
fluidSolid
{
regions (fluid solid);
originalPatches (nonCoupleRotating nonCoupleStationary);
}
}
After this step, a case should execute with foamMultiRun and decompose
and reconstruct and post-process normally.
One additional restriction for parallelised workflows is that
decomposition and reconstruction must be done with the -allRegions
option, so that the both sides of the coupling are available to the
decomposition/reconstruction algorithm.
Tutorials:
Two tutorials have been added to demonstrate use of this new
functionality:
- The multiRegion/CHT/misalignedDuct case provides a simple visual
confirmation that the patches are working (the exposed corners of
the solid will be hot if the non-conformal mapped walls are active),
and it demonstrates createNonConformalCouples's ability to add
boundary conditions to existing fields.
- The multiRegion/CHT/notchedRoller case demonstrates use of
non-conformal mapped walls with a moving mesh, and also provides an
example of parallelised usage.
Notes for Developers:
A coupled boundary condition now uses a new class,
mappedFvPatchBaseBase, in order to perform a transfer of values to or
from the neighbouring patch. For example:
// Cast the patch type to it's underlying mapping engine
const mappedFvPatchBaseBase& mapper =
mappedFvPatchBaseBase::getMap(patch());
// Lookup a field on the neighbouring patch
const fvPatchScalarField& nbrTn =
mapper.nbrFvPatch().lookupPatchField<volScalarField, scalar>("T");
// Map the values to this patch
const scalarField Tn(mapper.fromNeighbour(nbrTn));
For this to work, the fvPatch should be of an appropriate mapped type
which derives from mappedFvPatchBaseBase. This mappedFvPatchBaseBase
class provides an interface to to both conformal/interpolative and
non-conformal mapping procedures. This means that a coupled boundary
condition implemented in the manner above will work with either
conformal/interpolative or non-conformal mapped patch types.
Previously, coupled boundary conditions would access a mappedPatchBase
base class of the associated polyPatch, and use that to transfer values
between the patches. This direct dependence on the polyPatch's mapping
engine meant that only conformal/interpolative fvPatch fields that
corresponded to the polyPatch's geometry could be mapped.
for consistency with fvModels and fvConstraints, to simplify code and case
maintenance and to avoid the potentially complex functions entries being
unnecessarily parsed by utilities for which functionObject evaluation is
disabled.
The functions entry in controlDict is still read if the functions file is not
present for backward-compatibility, but it is advisable to migrate cases to use
the new functions file.
Coded functionality now supports basic un-typed substitutions from the
surrounding dictionary. For example:
value 1.2345;
#codeExecute
{
scalar s = $value;
...
};
It also now supports the more functional typed substitutions, such as:
direction (1 0 0);
#codeExecute
{
vector v = $<vector>direction;
...
};
These substitutions are now possible in all code blocks. Blocks with
access to the dictionary (e.g., #codeRead) will do a lookup which will
not require re-compilation if the value is changed. Blocks without
access to the dictionary will have the value directly substituted, and
will require recompilation when the value is changed.
The mergePatchPairs functionality in blockMesh also now uses patchIntersection.
The new mergePatchPairs and patchIntersection replaces the old, fragile and
practically unusable polyTopoChanger::slidingInterface functionality the removal
of which has allowed the deletion of a lot of other ancient and otherwise unused
clutter including polyTopoChanger, polyMeshModifier, polyTopoChange::setAction
and associated addObject/*, modifyObject/* and removeObject/*. This
rationalisation paves the way for the completion of the update of zone handling
allowing mesh points, faces and cells to exist in multiple zones which is
currently not supported with mesh topology change.
Application
stitchMesh
Description
Utility to stitch or conform pairs of patches,
converting the patch faces either into internal faces
or conformal faces or another patch.
Usage
\b stitchMesh (\<list of patch pairs\>)
E.g. to stitch patches \c top1 to \c top2 and \c bottom1 to \c bottom2
stitchMesh "((top1 top2) (bottom1 bottom2))"
Options:
- \par -overwrite \n
Replace the old mesh with the new one, rather than writing the new one
into a separate time directory
- \par -region \<name\>
Specify an alternative mesh region.
- \par -fields
Update vol and point fields
- \par -tol
Merge tolerance relative to local edge length (default 1e-4)
See also
Foam::mergePatchPairs
The boundary condition applied to pressure at open boundaries and outlets is switched
from totalPressure to entrainmentPressure. The latter boundary condition is more robust
since it calculates the pressure for inflow using (velocity) fluxes rather than velocity
on the patch.
This function has been changed to volume average, making it appropriate
to use on layered meshes in which the cells have non-uniform geometry
within their layers. A 'weightFields' (or 'weightField') control has
also been added, so that mass or phase weighted averages can be
performed within the layers.
This prevents spurious factors of 1000 from being introduced in
thermodynamic models. It also generalises the system further with
respect to alternative unit sets.
The legacy fvMeshTopoChangersMovingCone removed, replaced by the more general
mesh mapping approach, see tutorials incompressibleFluid/movingCone and
shockFluid/movingCone.
The patch-specific mapper interfaces, fvPatchFieldMapper and
pointPatchFieldMapper, have been removed as they did not do anything.
Patch mapping constructors and functions now take a basic fieldMapper
reference.
An fvPatchFieldMapper.H header has been provided to aid backwards
compatability so that existing custom boundary conditions continue to
compile.
The fact that these names create sources in their associated transport
equations is clear in context, so the name does not need to contain
'Source'.
Having 'Source' in the name is a historic convention that dates back to
when fvModels and fvConstraints were combined in a single fvOptions
interface. In this interface, disambiguation between sources and
constraints was necessary.
The full set of name changes is as follows:
accelerationSource -> acceleration
actuationDiskSource -> actuationDisk
effectivenessHeatExchangerSource -> effectivenessHeatExchanger
explicitPorositySource -> porosityForce
radialActuationDiskSource -> radialActuationDisk
rotorDiskSource -> rotorDisk
sixDoFAccelerationSource -> sixDoFAcceleration
solidEquilibriumEnergySource -> solidThermalEquilibrium
solidificationMeltingSource -> solidificationMelting
volumeFractionSource -> volumeBlockage
interRegionExplicitPorositySource -> interRegionPorosityForce
VoFSolidificationMeltingSource -> VoFSolidificationMelting
The old names are still available for backwards compatibility.
The fact that these names refer to constraints is clear in context, so
the name does not need to contain 'Constraint'.
Having 'Constraint' in the name is a historic convention that dates back
to when fvConstraints and fvModels were combined in a single fvOptions
interface. In this interface, disambiguation between sources and
constraints was necessary.
This change has been applied to the 'fixedValue' and 'fixedTemperature'
constraints, which were formerly named 'fixedValueConstraint' and
'fixedTemperatureConstraint', respectively.
The old names are still available for backwards compatibility.
The interface for fvModels has been modified to improve its application
to "proxy" equations. That is, equations that are not straightforward
statements of conservation laws in OpenFOAM's usual convention.
A standard conservation law typically takes the following form:
fvMatrix<scalar> psiEqn
(
fvm::ddt(alpha, rho, psi)
+ <fluxes>
==
<sources>
);
A proxy equation, on the other hand, may be a derivation or
rearrangement of a law like this, and may be linearised in terms of a
different variable.
The pressure equation is the most common example of a proxy equation. It
represents a statement of the conservation of volume or mass, but it is
a rearrangement of the original continuity equation, and it has been
linearised in terms of a different variable; the pressure. Another
example is that in the pre-predictor of a VoF solver the
phase-continuity equation is constructed, but it is linearised in terms
of volume fraction rather than density.
In these situations, fvModels sources are now applied by calling:
fvModels().sourceProxy(<conserved-fields ...>, <equation-field>)
Where <conserved-fields ...> are (alpha, rho, psi), (rho, psi), just
(psi), or are omitted entirely (for volume continuity), and the
<equation-field> is the field associated with the proxy equation. This
produces a source term identical in value to the following call:
fvModels().source(<conserved-fields ...>)
It is only the linearisation in terms of <equation-field> that differs
between these two calls.
This change permits much greater flexibility in the handling of mass and
volume sources than the previous name-based system did. All the relevant
fields are available, dimensions can be used in the logic to determine
what sources are being constructed, and sources relating to a given
conservation law all share the same function.
This commit adds the functionality for injection-type sources in the
compressibleVoF solver. A following commit will add a volume source
model for use in incompressible solvers.
This change makes multiphaseEuler more consistent with other modules and
makes its sub-libraries less inter-dependent. Some left-over references
to multiphaseEulerFoam have also been removed.
Population balance size-group fraction 'f<index>.<phase>' fields are now
read from an 'fDefault.<phase>' field if they are not provided
explicitly. This is the same process as is applied to species fractions
or fvDOM rays. The sum-of-fs field 'f.<phase>' is no longer required.
The value of a fraction field and its boundary conditions must now be
specified in the corresponding field file. Value entries are no longer
given in the size group dictionaries in the constant/phaseProperties
file, and an error message will be generated if a value entry is found.
The fraction fields are now numbered programatically, rather than being
named. So, the size-group dictionaries do not require a name any more.
All of the above is also true for any 'kappa<index>.<phase>' fields that
are constructed and solved for as part of a fractal shape model.
The following is an example of a specification of a population balance
with two phases in it:
populationBalances (bubbles);
air1
{
type pureIsothermalPhaseModel;
diameterModel velocityGroup;
velocityGroupCoeffs
{
populationBalance bubbles;
shapeModel spherical;
sizeGroups
(
{ dSph 1e-3; } // Size-group #0: Fraction field f0.air1
{ dSph 2e-3; } // ...
{ dSph 3e-3; }
{ dSph 4e-3; }
{ dSph 5e-3; }
);
}
residualAlpha 1e-6;
}
air2
{
type pureIsothermalPhaseModel;
diameterModel velocityGroup;
velocityGroupCoeffs
{
populationBalance bubbles;
shapeModel spherical;
sizeGroups
(
{ dSph 6e-3; } // Size-group #5: Fraction field f5.air2
{ dSph 7e-3; } // ...
{ dSph 8e-3; }
{ dSph 9e-3; }
{ dSph 10e-3; }
{ dSph 11e-3; }
{ dSph 12e-3; }
);
}
residualAlpha 1e-6;
}
Previously a fraction field was constructed automatically using the
boundary condition types from the sum-of-fs field, and the value of both
the internal and boundary field was then overridden by the value setting
provided for the size-group. This procedure doesn't generalise to
boundary conditions other than basic types that store no additional
data, like zeroGradient and fixedValue. More complex boundary conditions
such as inletOutlet and uniformFixedValue are incompatible with this
approach.
This is arguably less convenient than the previous specification, where
the sizes and fractions appeared together in a table-like list in the
sizeGroups entry. In the event that a substantial proportion of the
size-groups have a non-zero initial fraction, writing out all the field
files manually is extremely tedious. To mitigate this somewhat, a
packaged function has been added to initialise the fields given a file
containing a size distribution (see the pipeBend tutorial for an example
of its usage). This function has the same limitations as the previous
code in that it requires all boundary conditions to be default
constructable.
Ultimately, the "correct" fix for the issue of how to set the boundary
conditions conveniently is to create customised inlet-outlet boundary
conditions that determine their field's position within the population
balance and evaluate a distribution to determine the appropriate inlet
value. This work is pending funding.
Both argument and value dimensions can be set for inline-constructable
function1-s. For example, this inline table function:
massFlowRate table [CAD] [g/s]
(
(0 0.46)
(0.17 1.9)
(0.31 4.8)
);
Is equivalent to this dictionary specification:
massFlowRate
{
type table;
xDimensions [CAD];
dimensions [g/s];
values
(
(0 0.46)
(0.17 1.9)
(0.31 4.8)
);
}
In the inline form, the argument/x-dimensions come first, and the value
dimensions second. If there only one dimension set provided, then this
is assumed to be the value dimensions.
The functionality necessary to write in a different unit set has been
removed. This was excessivelty complex, never used in practice, and of
little practical usage. Output numeric data, in general, is not designed
to be conveniently user-readable, so it is not important what unit
system it is written in.
