This mode uses the patchToPatch system (the same one used by NCC) for
coupling two patches. It can be selected for a patch (e.g., in a
blockMeshDict) in the following way:
fluid_to_solid
{
type mappedWall;
sampleMode patchToPatch;
sampleRegion solid;
samplePatch solid_to_fluid;
patchToPatchMode intersection;
faces
(
(0 1 2 3)
...
);
}
The "patchToPatchMode" can be one of the following:
"intersection": Values obtained by weighting contributions from
sampled faces with the intersected area between the faces.
Equivalent to the nearestPatchFaceAMI sampleMode (which will be
removed in a future commit).
"inverseDistance": Values obtained by inverse-distance weighting
between a small stencil of nearby sampled faces.
"nearest": Take the value from the nearest sampled face.
"matching": As nearest, but with checks to ensure that the mapping
is one-to-one. To be used for mapping between identical patches.
The intention is that patchToPatch will become the only sampleMode, and
the four options above will become the options which determine how
mapping is performed. Cell-to-patch mapping will be transferred into a
separate class as its use cases essentially never intersect with those
of patch-to-patch mapping.
An extruded region is now contiguous even when specified with multiple
face zones. Edges that border faces in different zones now extrude into
internal faces, rather than a pair of boundary faces. Different zones
now result only in different mapped patches in the extruded and primary
meshes. This means a mesh can be created for a single contiguous
extruded region spanning multiple patches. This might be necessary if,
for example, a film region is needed across multiple walls with
differing thermal boundary conditions.
Disconnected extruded regions can still be constructed by running the
extrudeToRegionMesh utility muiliple times.
The mapped patches created to couple the extruded regions now have
symmetric names similar to those created by splitMeshRegions. For
example, if the mapped patch in the primary region is called
"region0_to_extrudedRegion_f0", then the corresponding patch in the
extruded region is called "extrudedRegion_to_region0_f0" (f0, in this
example is the face zone from which the region was extruded).
Offsetting of the top patch is now handled automatically by a new
mappedExtrudedWallPolyPatch. This refers to the bottom patch and
automatically calculates the sampling offsets by doing a wave across the
extruded mesh layers. This prevents the need to store the offsets in the
patch itself, and makes it possible for the patch to undergo mesh
changes without adding additional functions to the polyPatch (mapping
constructors, autoMap and rmap methods, etc ...).
If a "patch" selection is made for a cyclic patch, surfaceFieldValue now
also selects faces on any associated processor cyclic patches. This
ensures that the serial and parallel operations are equivalent.
The schemesField option:
- To employ the same numerical schemes as another field set
the \c schemesField entry,
works to set discretisation schemes and a standard linear solver and settings
but not MULES for which an entry in fvSolution under the actual field name is
required.
Many functionObjects operate on fvMesh objects, in particular vol and surface
fields and they cannot be updated in polyMesh as they depend on fvMesh data
which is updated after polyMesh.
If the sequence of meshes are decomposed independently the number, order and
potentially type of processor patches is likely to change. Thus the processor
patches and patch fields must be replaced with those of the new mesh.
The functionality provided by 'cyclicACMI' and 'cyclicRepeatAMI' has
been entirely superseded by non-conformal coupled (NCC). All references
to 'cyclicACMI' and 'cyclicRepeatAMI' have therefore been removed.
See previous commits 569fa31d and 420866cf for more explanation,
instructions on updating, and relevant tutorial cases.
This major development provides coupling of patches which are
non-conformal, i.e. where the faces of one patch do not match the faces
of the other. The coupling is fully conservative and second order
accurate in space, unlike the Arbitrary Mesh Interface (AMI) and
associated ACMI and Repeat AMI methods which NCC replaces.
Description:
A non-conformal couple is a connection between a pair of boundary
patches formed by projecting one patch onto the other in a way that
fills the space between them. The intersection between the projected
surface and patch forms new faces that are incorporated into the finite
volume mesh. These new faces are created identically on both sides of
the couple, and therefore become equivalent to internal faces within the
mesh. The affected cells remain closed, meaning that the area vectors
sum to zero for all the faces of each cell. Consequently, the main
benefits of the finite volume method, i.e. conservation and accuracy,
are not undermined by the coupling.
A couple connects parts of mesh that are otherwise disconnected and can
be used in the following ways:
+ to simulate rotating geometries, e.g. a propeller or stirrer, in which
a part of the mesh rotates with the geometry and connects to a
surrounding mesh which is not moving;
+ to connect meshes that are generated separately, which do not conform
at their boundaries;
+ to connect patches which only partially overlap, in which the
non-overlapped section forms another boundary, e.g. a wall;
+ to simulate a case with a geometry which is periodically repeating by
creating multiple couples with different transformations between
patches.
The capability for simulating partial overlaps replaces the ACMI
functionality, currently provided by the 'cyclicACMI' patch type, and
which is unreliable unless the couple is perfectly flat. The capability
for simulating periodically repeating geometry replaces the Repeat AMI
functionality currently provided by the 'cyclicRepeatAMI' patch type.
Usage:
The process of meshing for NCC is very similar to existing processes for
meshing for AMI. Typically, a mesh is generated with an identifiable set
of internal faces which coincide with the surface through which the mesh
will be coupled. These faces are then duplicated by running the
'createBaffles' utility to create two boundary patches. The points are
then split using 'splitBaffles' in order to permit independent motion of
the patches.
In AMI, these patches are assigned the 'cyclicAMI' patch type, which
couples them using AMI interpolation methods.
With NCC, the patches remain non-coupled, e.g. a 'wall' type. Coupling
is instead achieved by running the new 'createNonConformalCouples'
utility, which creates additional coupled patches of type
'nonConformalCyclic'. These appear in the 'constant/polyMesh/boundary'
file with zero faces; they are populated with faces in the finite volume
mesh during the connection process in NCC.
For a single couple, such as that which separates the rotating and
stationary sections of a mesh, the utility can be called using the
non-coupled patch names as arguments, e.g.
createNonConformalCouples -overwrite rotatingZoneInner rotatingZoneOuter
where 'rotatingZoneInner' and 'rotatingZoneOuter' are the names of the
patches.
For multiple couples, and/or couples with transformations,
'createNonConformalCouples' should be run without arguments. Settings
will then be read from a configuration file named
'system/createNonConformalCouplesDict'. See
'$FOAM_ETC/caseDicts/annotated/createNonConformalCouplesDict' for
examples.
Boundary conditions must be specified for the non-coupled patches. For a
couple where the patches fully overlap, boundary conditions
corresponding to a slip wall are typically applied to fields, i.e
'movingWallSlipVelocity' (or 'slip' if the mesh is stationary) for
velocity U, 'zeroGradient' or 'fixedFluxPressure' for pressure p, and
'zeroGradient' for other fields. For a couple with
partially-overlapping patches, boundary conditions are applied which
physically represent the non-overlapped region, e.g. a no-slip wall.
Boundary conditions also need to be specified for the
'nonConformalCyclic' patches created by 'createNonConformalCouples'. It
is generally recommended that this is done by including the
'$FOAM_ETC/caseDicts/setConstraintTypes' file in the 'boundaryField'
section of each of the field files, e.g.
boundaryField
{
#includeEtc "caseDicts/setConstraintTypes"
inlet
{
...
}
...
}
For moving mesh cases, it may be necessary to correct the mesh fluxes
that are changed as a result of the connection procedure. If the
connected patches do not conform perfectly to the mesh motion, then
failure to correct the fluxes can result in noise in the pressure
solution.
Correction for the mesh fluxes is enabled by the 'correctMeshPhi' switch
in the 'PIMPLE' (or equivalent) section of 'system/fvSolution'. When it
is enabled, solver settings are required for 'MeshPhi'. The solution
just needs to distribute the error enough to dissipate the noise. A
smooth solver with a loose tolerance is typically sufficient, e.g. the
settings in 'system/fvSolution' shown below:
solvers
{
MeshPhi
{
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-2;
relTol 0;
}
...
}
PIMPLE
{
correctMeshPhi yes;
...
}
The solution of 'MeshPhi' is an inexpensive computation since it is
applied only to a small subset of the mesh adjacent to the
couple. Conservation is maintained whether or not the mesh flux
correction is enabled, and regardless of the solution tolerance for
'MeshPhi'.
Advantages of NCC:
+ NCC maintains conservation which is required for many numerical
schemes and algorithms to operate effectively, in particular those
designed to maintain boundedness of a solution.
+ Closed-volume systems no longer suffer from accumulation or loss of
mass, poor convergence of the pressure equation, and/or concentration
of error in the reference cell.
+ Partially overlapped simulations are now possible on surfaces that are
not perfectly flat. The projection fills space so no overlaps or
spaces are generated inside contiguously overlapping sections, even if
those sections have sharp angles.
+ The finite volume faces created by NCC have geometrically accurate
centres. This makes the method second order accurate in space.
+ The polyhedral mesh no longer requires duplicate boundary faces to be
generated in order to run a partially overlapped simulation.
+ Lagrangian elements can now transfer across non-conformal couplings in
parallel.
+ Once the intersection has been computed and applied to the finite
volume mesh, it can use standard cyclic or processor cyclic finite
volume boundary conditions, with no need for additional patch types or
matrix interfaces.
+ Parallel communication is done using the standard
processor-patch-field system. This is more efficient than alternative
systems since it has been carefully optimised for use within the
linear solvers.
+ Coupled patches are disconnected prior to mesh motion and topology
change and reconnected afterwards. This simplifies the boundary
condition specification for mesh motion fields.
Resolved Bug Reports:
+ https://bugs.openfoam.org/view.php?id=663
+ https://bugs.openfoam.org/view.php?id=883
+ https://bugs.openfoam.org/view.php?id=887
+ https://bugs.openfoam.org/view.php?id=1337
+ https://bugs.openfoam.org/view.php?id=1388
+ https://bugs.openfoam.org/view.php?id=1422
+ https://bugs.openfoam.org/view.php?id=1829
+ https://bugs.openfoam.org/view.php?id=1841
+ https://bugs.openfoam.org/view.php?id=2274
+ https://bugs.openfoam.org/view.php?id=2561
+ https://bugs.openfoam.org/view.php?id=3817
Deprecation:
NCC replaces the functionality provided by AMI, ACMI and Repeat AMI.
ACMI and Repeat AMI are insufficiently reliable to warrant further
maintenance so are removed in an accompanying commit to OpenFOAM-dev.
AMI is more widely used so will be retained alongside NCC for the next
version release of OpenFOAM and then subsequently removed from
OpenFOAM-dev.
This change means this function is determining the sequence in which
points are plotted topologically. This makes it possible to plot a layer
average along a pipe that goes through many changes of direction.
Previously, the function determined the order by means of a geometric
sort in the plot direction. This only worked when the layers were
perpendicular to one of the coordinate axes.
This is a simple function that provides a convenient way for a user to
call fvc::reconstruct for the purposes of post-processing flux fields;
e.g., to construct a cell velocity from a face flux.
It can be used to generate output during a run by adding the following
settings to a case's controlDict:
functions
{
#includeFunc reconstruct(phi)
}
Or it can be executed as a postProcessing step by calling:
postProcess -func "reconstruct(phi)"
With fvMeshTopoChangers::meshToMesh it is now possible to map the solution to a
specified sequence of pre-generated meshes at run-time to support arbitrary mesh
changes, refinements, un-refinements, changes in region topology, geometry,
etc. Additionally mesh-motion between the sequence of meshes is supported to
allow for e.g. piston and valve motion in engines.
The tutorials/incompressible/pimpleFoam/laminar/movingCone case has been updated
to provide a demonstration of the advantages of this run-time mesh-mapping by
mapping to meshes that are finer behind the cone and coarser in front of the
cone as the cone approaches the end of the domain, thus maintaining good
resolution while avoiding excessive cell aspect ratio as the mesh is squeezed.
The dynamicMeshDict for the movingCone case is;
mover
{
type motionSolver;
libs ("libfvMeshMovers.so" "libfvMotionSolvers.so");
motionSolver velocityComponentLaplacian;
component x;
diffusivity directional (1 200 0);
}
topoChanger
{
type meshToMesh;
libs ("libmeshToMeshTopoChanger.so");
times (0.0015 0.003);
timeDelta 1e-6;
}
which lists the mesh mapping times 0.0015s 0.003s and meshes for these times in
directories constant/meshToMesh_0.0015 and constant/meshToMesh_0.003 are
generated in the Allrun script before the pimpleFoam run:
runApplication -a blockMesh -dict blockMeshDict.2
rm -rf constant/meshToMesh_0.0015
mkdir constant/meshToMesh_0.0015
mv constant/polyMesh constant/meshToMesh_0.0015
runApplication -a blockMesh -dict blockMeshDict.3
rm -rf constant/meshToMesh_0.003
mkdir constant/meshToMesh_0.003
mv constant/polyMesh constant/meshToMesh_0.003
runApplication -a blockMesh -dict blockMeshDict.1
runApplication $application
Note: This functionality is experimental and has only undergone basic testing.
It is likely that it does not yet work with all functionObject, fvModels
etc. which will need updating to support this form of mesh topology change.
This new mapping structure is designed to support run-time mesh-to-mesh mapping
to allow arbitrary changes to the mesh structure, for example during extreme
motion requiring significant topology change including region disconnection etc.
The polyTopoChangeMap is the map specifically relating to polyMesh topological
changes generated by polyTopoChange and used to update and map mesh related
types and fields following the topo-change.
This is a map data structure rather than a class or function which performs the
mapping operation so polyMeshDistributionMap is more logical and comprehensible
than mapDistributePolyMesh.
fvMesh is no longer derived from fvSchemes and fvSolution, these are now
demand-driven and accessed by the member functions schemes() and solution()
respectively. This means that the system/fvSchemes and system/fvSolution files
are no longer required during fvMesh constructions simplifying the mesh
generation and manipulation phase; theses files are read on the first call of
their access functions.
The fvSchemes member function names have also been simplified taking advantage
of the context in which they are called, for example
mesh.ddtScheme(fieldName) -> mesh.schemes().ddt(fieldName)
Replaces the local definition of the omega function in
functionObjects::turbulenceFields.
Will also be used in interfacial transfers and coupling in multiphase turbulence
modelling where different turbulence models are used in different phases.
This function generates plots of fields averaged over the layers in the
mesh. It is a generalised replacement for the postChannel utility, which
has been removed. An example of this function's usage is as follows:
layerAverage1
{
type layerAverage;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
setFormat raw;
// Patches and/or zones from which layers extrude
patches (bottom);
zones (quarterPlane threeQuartersPlane);
// Spatial component against which to plot
component y;
// Is the geometry symmetric around the centre layer?
symmetric true;
// Fields to average and plot
fields (pMean pPrime2Mean UMean UPrime2Mean k);
}
Sampled sets and streamlines now write all their fields to the same
file. This prevents excessive duplication of the geometry and makes
post-processing tasks more convenient.
"axis" entries are now optional in sampled sets and streamlines. When
omitted, a default entry will be used, which is chosen appropriately for
the coordinate set and the write format. Some combinations are not
supported. For example, a scalar ("x", "y", "z" or "distance") axis
cannot be used to write in the vtk format, as vtk requires 3D locations
with which to associate data. Similarly, a point ("xyz") axis cannot be
used with the gnuplot format, as gnuplot needs a single scalar to
associate with the x-axis.
Streamlines can now write out fields of any type, not just scalars and
vectors, and there is no longer a strict requirement for velocity to be
one of the fields.
Streamlines now output to postProcessing/<functionName>/time/<file> in
the same way as other functions. The additional "sets" subdirectory has
been removed.
The raw set writer now aligns columns correctly.
The handling of segments in coordSet and sampledSet has been
fixed/completed. Segments mean that a coordinate set can represent a
number of contiguous lines, disconnected points, or some combination
thereof. This works in parallel; segments remain contiguous across
processor boundaries. Set writers now only need one write method, as the
previous "writeTracks" functionality is now handled by streamlines
providing the writer with the appropriate segment structure.
Coordinate sets and set writers now have a convenient programmatic
interface. To write a graph of A and B against some coordinate X, in
gnuplot format, we can call the following:
setWriter::New("gnuplot")->write
(
directoryName,
graphName,
coordSet(true, "X", X), // <-- "true" indicates a contiguous
"A", // line, "false" would mean
A, // disconnected points
"B",
B
);
This write function is variadic. It supports any number of
field-name-field pairs, and they can be of any primitive type.
Support for Jplot and Xmgrace formats has been removed. Raw, CSV,
Gnuplot, VTK and Ensight formats are all still available.
The old "graph" functionality has been removed from the code, with the
exception of the randomProcesses library and associated applications
(noise, DNSFoam and boxTurb). The intention is that these should also
eventually be converted to use the setWriters. For now, so that it is
clear that the "graph" functionality is not to be used elsewhere, it has
been moved into a subdirectory of the randomProcesses library.
wallHeatFlux can now be used to calculate the phase wall heat-flux in
multiphase systems, e.g.
multiphaseEulerFoam -postProcess -func 'wallHeatFlux(phase=water)' -latestTime
wallShearStress can now be used to calculate the phase wall shear-stress in
multiphase systems, e.g.
multiphaseEulerFoam -postProcess -func 'wallShearStress(phase=water)' -latestTime
By default a streamline now stops at the cyclic and starts again at the
coupled location on the opposite cyclic.
There is also now an "outside" option that can be passed to the
streamlines function. This changes the default behaviour so that the
streamline continues outside of the mesh when it encounters a cyclic
patch. The following postProcess command uses the "outside" option in
this way:
postProcess -latestTime -func "
streamlinesPatch
(
patch=inlet,
nPoints=50,
outside=true,
fields=(p U)
)"
This prevents excessive duplication of surface geometry and makes
post-processing tasks in paraview more convenient.
The Nastran and Star-CD surface formats were found not to work, so
support for these output types has been removed. Raw, VTK, Foam and
Ensight formats are all still available.
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,
- The \c diffusivity entry can be set to \c none, \c constant, \c viscosity
- A constant diffusivity is specified with the \c D entry,
- If a momentum transport model is available and the \c viscosity
diffusivety option specified an effective diffusivity may be constructed
from the laminar and turbulent viscosities using the diffusivity
coefficients \c alphal and \c alphat:
\verbatim
D = alphal*nu + alphat*nut
\endverbatim
Example:
\verbatim
#includeFunc scalarTransport(T, alphaD=1, alphaDt=1)
\endverbatim
For incompressible flow the passive scalar may optionally be solved with the
MULES limiter and sub-cycling or semi-implicit in order to maintain
boundedness, particularly if a compressive, PLIC or MPLIC convection
scheme is used.
Example:
\verbatim
#includeFunc scalarTransport(tracer, diffusion=none)
with scheme specification:
div(phi,tracer) Gauss interfaceCompression vanLeer 1;
and solver specification:
tracer
{
nCorr 1;
nSubCycles 3;
MULESCorr no;
nLimiterIter 5;
applyPrevCorr yes;
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-8;
relTol 0;
diffusion
{
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-8;
relTol 0;
}
}
\endverbatim
With this change each functionObject provides the list of fields required so
that the postProcess utility can pre-load them before executing the list of
functionObjects. This provides a more convenient interface than using the
-field or -fields command-line options to postProcess which are now redundant.
replacing the virtual functions overridden in engineTime.
Now the userTime conversion function in Time is specified in system/controlDict
such that the solver as well as all pre- and post-processing tools also operate
correctly with the chosen user-time.
For example the user-time and rpm in the tutorials/combustion/XiEngineFoam/kivaTest case are
now specified in system/controlDict:
userTime
{
type engine;
rpm 1500;
}
The default specification is real-time:
userTime
{
type real;
}
but this entry can be omitted as the real-time class is instantiated
automatically if the userTime entry is not present in system/controlDict.
