The mesh will now be written only for the write time following mesh-motion or
topology change (refinement/unrefinement, mesh-to-mesh mapping, load-balancing
etc.) and not for all subsequent time-steps as it did previously. This reduces
storage and reconstruction effort of changing mesh cases.
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 control forces writing of surfaces, even when they have no faces.
This can be useful for smoothly animating isoSurfaces that do not exist
at all write times.
It can be used to force writing of an isoSurface in the following way,
in system/controlDict:
functions
{
#includeFunc isoSurface
(
isoField=alpha.water,
isoValue=0.5,
writeEmpty=yes
)
}
On unstructured collocated meshes the Reynolds stress tends to decouple from the
velocity creating pronounced staggering patterns in the solution. This effect
is reduced or eliminated by a special coupling algorithm which replaces the
gradient diffusion component of the Reynolds stress with the equivalent compact
representation on the mesh, i.e. div-grad with Laplacian in the DivDevRhoReff function:
template<class BasicMomentumTransportModel>
template<class RhoFieldType>
Foam::tmp<Foam::fvVectorMatrix>
Foam::ReynoldsStress<BasicMomentumTransportModel>::DivDevRhoReff
(
const RhoFieldType& rho,
volVectorField& U
) const
{
tmp<volTensorField> tgradU = fvc::grad(U);
const volTensorField& gradU = tgradU();
const surfaceTensorField gradUf(fvc::interpolate(gradU));
// Interpolate Reynolds stress to the faces
// with either a stress or velocity coupling correction
const surfaceVectorField Refff
(
(this->mesh().Sf() & fvc::interpolate(R_))
// Stress coupling
+ couplingFactor_
*(this->mesh().Sf() & fvc::interpolate(this->nut()*gradU))
// or velocity gradient coupling
// + couplingFactor_
// *fvc::interpolate(this->nut())*(this->mesh().Sf() & gradUf)
- fvc::interpolate(couplingFactor_*this->nut() + this->nu())
*this->mesh().magSf()*fvc::snGrad(U)
- fvc::interpolate(this->nu())*(this->mesh().Sf() & dev2(gradUf.T()))
);
return
(
fvc::div(fvc::interpolate(this->alpha_*rho)*Refff)
- correction(fvm::laplacian(this->alpha_*rho*this->nuEff(), U))
);
}
In the above two options for the coupling term are provided, one based on the
stress correction (un-commented) and an alternative based an the velocity
gradient correction (commented). Tests run so far indicate that the stress
correction provides better coupling while minimising the error introduced.
A new tutorial case ductSecondaryFlow is provided which demonstrates the updated
coupling algorithm on the simulation of the classic secondary flow generated in
rectangular ducts.
The topology changes occur in the intermediate steps during mesh sub-division
and addition, there is no need to update meshObjects during this phase, these
are updated at the end of the redistribution by the distribute function called
for each. The distribute functions for nearWallDist and wallDist have been
updated accordingly.
Now stationary MRF regions may be embedded in moving mesh cases. While in
principle MRF regions moving with the mesh is supported by this development
there is no special handling with the MRF implementation to support the required
specification of the motion of the MRF regions.
A wall distance computation will not be correct on a disconnected
processor case. This is also more efficient.
Resolves bug report https://bugs.openfoam.org/view.php?id=3833
New interpolation and snGrad schemes to help stabilise multiphaseEulerFoam runs
on poor meshes by reverting to a bounded form when the phase-fraction
corresponding to the phase of the field argument is less than 1e-3. If this
approach proves effective and it would be useful to adjust the phase-fraction
limit it could be made a user input.
Class
Foam::phaseStabilised
Description
Phase-stabilised interpolation scheme
which applies upwind to the faces at which the upwind phase-fraction is less
than 1e-3.
Class
Foam::fv::phaseStabilisedSnGrad
Description
snGrad scheme with phase-fraction limited non-orthogonal correction.
When the phase-fraction is less than 1e-3 the non-orthogonal correction is
set to 0.
Example specification in fvSchemes:
gradSchemes
{
default Gauss linear;
limited cellLimited Gauss linear 1;
}
divSchemes
{
default none;
.
.
.
"div\(alphaRhoPhi.*,U.*\)" Gauss phaseStabilised linearUpwindV limited;
"div\(phi.*,U.*\)" Gauss phaseStabilised linearUpwindV limited;
"div\(alphaRhoPhi.*,(h|e).*\)" Gauss phaseStabilised limitedLinear 1;
"div\(alphaRhoPhi.*,K.*\)" Gauss phaseStabilised limitedLinear 1;
"div\(alphaRhoPhi.*,\(p\|thermo:rho.*\)\)" Gauss phaseStabilised limitedLinear 1;
.
.
.
}
laplacianSchemes
{
default Gauss linear limited corrected 0.33;
phaseStabilised Gauss linear phaseStabilised limited corrected 0.33;
laplacian(((alpha.air*thermo:rho.air)*nuEff.air),U.air) $phaseStabilised;
laplacian(((alpha.water*thermo:rho.water)*nuEff.water),U.water) $phaseStabilised;
laplacian((alpha.air*alphaEff),h.air) $phaseStabilised;
laplacian((alpha.water*alphaEff),e.water) $phaseStabilised;
}
PrimitivePatch is a geometry engine. Is not used, and is not designed to
be used, as an abstract interface. That function is left to
PrimitivePatch's immediate derivations, such as polyPatch and
MeshedSurface.
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)"
epsilonm is obtained by combining epsilon.gas and epsilon.liquid in a two-phase
system, each of which will apply the epsilonWallFunction at walls; the
epsilonmWallFunction propagates the resulting wall epsilonm into the near-wall
cells.
If the 0/epsilonm file is provided the epsilonmWallFunction should be specified
for walls, if the 0/epsilonm file is not provided it will be generated
automatically and the epsilonmWallFunction applied to walls for which the
epsilonWallFunction is specified in the epsilon.liquid file.
fvMesh::update() now executes at the beginning of the time-step, before time is
incremented and handles topology change, mesh to mesh mapping and redistribution
without point motion. Following each of these mesh changes fields are mapped
from the previous mesh state to new mesh state in a conservative manner. These
mesh changes not occur at most once per time-step.
fvMesh::move() is executed after time is incremented and handles point motion
mesh morphing during the time-step in an Arbitrary Lagrangian Eulerian approach
requiring the mesh motion flux to match the cell volume change. fvMesh::move()
can be called any number of times during the time-step to allow iterative update
of the coupling between the mesh motion and field solution.
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.
