ParMETIS is a parallel version of METIS and can be used as an alternative to
ptScotch or Zoltan, supporting multi-constraints and redistribution:
Description
ParMetis redistribution in parallel
Note: parMetis methods do not support serial operation.
Parameters
- Method of decomposition
- kWay: multilevel k-way
- geomKway: combined coordinate-based and multi-level k-way
- adaptiveRepart: balances the work load of a graph
- Options
- options[0]: The specified options are used if options[0] = 1
- options[1]: Specifies the level of information to be returned during
the execution of the algorithm. Timing information can be obtained by
setting this to 1. Additional options for this parameter can be obtained
by looking at parmetis.h. Default: 0.
- options[2]: Random number seed for the routine
- options[3]: Specifies whether the sub-domains and processors are coupled
or un-coupled. If the number of sub-domains desired (i.e., nparts) and
the number of processors that are being used is not the same, then these
must be un-coupled. However, if nparts equals the number of processors,
these can either be coupled or de-coupled. If sub-domains and processors
are coupled, then the initial partitioning will be obtained implicitly
from the graph distribution. However, if sub-domains are un-coupled from
processors, then the initial partitioning needs to be obtained from the
initial values assigned to the part array.
- itr: Parameter which describes the ratio of inter-processor communication
time compared to data redistribution time. Should be set between 0.000001
and 1000000.0. If set high, a repartitioning with a low edge-cut will be
computed. If it is set low, a repartitioning that requires little data
redistribution will be computed. Good values for this parameter can be
obtained by dividing inter-processor communication time by data
redistribution time. Otherwise, a value of 1000.0 is recommended.
Default: 1000.
The ParMETIS sources can be downloaded and compiled in ThirdParty-dev using the
link in the README file and the compilation commands in Allwmake.
Note the specific license under which ParMETIS is released:
Copyright & License Notice
--------------------------
The ParMETIS package is copyrighted by the Regents of the
University of Minnesota. It can be freely used for educational and
research purposes by non-profit institutions and US government
agencies only. Other organizations are allowed to use ParMETIS
only for evaluation purposes, and any further uses will require prior
approval. The software may not be sold or redistributed without prior
approval. One may make copies of the software for their use provided
that the copies, are not sold or distributed, are used under the same
terms and conditions.
As unestablished research software, this code is provided on an
``as is'' basis without warranty of any kind, either expressed or
implied. The downloading, or executing any part of this software
constitutes an implicit agreement to these terms. These terms and
conditions are subject to change at any time without prior notice.
to ensure the values on the patch are consistent with the boundary condition
specification and to avoid the need to specify a potentially inconsistent
"value" entry.
Optional CPU load caching can be switched-on for Lagrangian cloud tracking
and/or chemistry integration using the new cpuLoad switch in the cloudProperties
or chemistryProperties dictionary files respectively and used for
multi-constraint load-balancing by the fvMeshDistributorsLoadBalancer specified
in the dynamicMeshDict file
distributor
{
type loadBalancer;
libs ("libfvMeshDistributors.so");
multiConstraint true;
redistributionInterval 10;
}
which used the distributor specified in the decomposeParDict file, e.g.
numberOfSubdomains 12;
decomposer simple;
distributor zoltan;
libs ("libzoltanDecomp.so");
simpleCoeffs
{
n (2 2 3);
}
zoltanCoeffs
{
lb_method rcb;
}
The incompressibleDenseParticleFluid/cyclone case has been updated to
demonstrate this new functionality and shows a speedup ~50% using the Zoltan RCB
multi-constraint distributor. The multicomponentFluid/counterFlowFlame2D_GRI
case has also been updated to use the new cpuLoad switch.
The majority of input parameters now support automatic unit conversion.
Units are specified within square brackets, either before or after the
value. Primitive parameters (e.g., scalars, vectors, tensors, ...),
dimensioned types, fields, Function1-s and Function2-s all support unit
conversion in this way.
Unit conversion occurs on input only. OpenFOAM writes out all fields and
parameters in standard units. It is recommended to use '.orig' files in
the 0 directory to preserve user-readable input if those files are being
modified by pre-processing applications (e.g., setFields).
For example, to specify a volumetric flow rate inlet boundary in litres
per second [l/s], rather than metres-cubed per second [m^3/s], in 0/U:
boundaryField
{
inlet
{
type flowRateInletVelocity;
volumetricFlowRate 0.1 [l/s];
value $internalField;
}
...
}
Or, to specify the pressure field in bar, in 0/p:
internalField uniform 1 [bar];
Or, to convert the parameters of an Arrhenius reaction rate from a
cm-mol-kcal unit system, in constant/chemistryProperties:
reactions
{
methaneReaction
{
type irreversibleArrhenius;
reaction "CH4^0.2 + 2O2^1.3 = CO2 + 2H2O";
A 6.7e12 [(mol/cm^3)^-0.5/s];
beta 0;
Ea 48.4 [kcal/mol];
}
}
Or, to define a time-varying outlet pressure using a CSV file in which
the pressure column is in mega-pascals [MPa], in 0/p:
boundaryField
{
outlet
{
type uniformFixedValue;
value
{
type table;
format csv;
nHeaderLine 1;
units ([s] [MPa]); // <-- new units entry
columns (0 1);
mergeSeparators no;
file "data/pressure.csv";
outOfBounds clamp;
interpolationScheme linear;
}
}
...
}
(Note also that a new 'columns' entry replaces the old 'refColumn' and
'componentColumns'. This is is considered to be more intuitive, and has
a consistent syntax with the new 'units' entry. 'columns' and
'componentColumns' have been retained for backwards compatibility and
will continue to work for the time being.)
Unit definitions can be added in the global or case controlDict files.
See UnitConversions in $WM_PROJECT_DIR/etc/controlDict for examples.
Currently available units include:
Standard: kg m s K kmol A Cd
Derived: Hz N Pa J W g um mm cm km l ml us ms min hr mol
rpm bar atm kPa MPa cal kcal cSt cP % rad rot deg
A user-time unit is also provided if user-time is in operation. This
allows it to be specified locally whether a parameter relates to
real-time or to user-time. For example, to define a mass source that
ramps up from a given engine-time (in crank-angle-degrees [CAD]) over a
duration in real-time, in constant/fvModels:
massSource1
{
type massSource;
points ((1 2 3));
massFlowRate
{
type scale;
scale linearRamp;
start 20 [CAD];
duration 50 [ms];
value 0.1 [g/s];
}
}
Specified units will be checked against the parameter's dimensions where
possible, and an error generated if they are not consistent. For the
dimensions to be available for this check, the code requires
modification, and work propagating this change across OpenFOAM is
ongoing. Unit conversions are still possible without these changes, but
the validity of such conversions will not be checked.
Units are no longer permitted in 'dimensions' entries in field files.
These 'dimensions' entries can now, instead, take the names of
dimensions. The names of the available dimensions are:
Standard: mass length time temperature
moles current luminousIntensity
Derived: area volume rate velocity momentum acceleration density
force energy power pressure kinematicPressure
compressibility gasConstant specificHeatCapacity
kinematicViscosity dynamicViscosity thermalConductivity
volumetricFlux massFlux
So, for example, a 0/epsilon file might specify the dimensions as
follows:
dimensions [energy/mass/time];
And a 0/alphat file might have:
dimensions [thermalConductivity/specificHeatCapacity];
*** Development Notes ***
A unit conversion can construct trivially from a dimension set,
resulting in a "standard" unit with a conversion factor of one. This
means the functions which perform unit conversion on read can be
provided dimension sets or unit conversion objects interchangeably.
A basic `dict.lookup<vector>("Umean")` call will do unit conversion, but
it does not know the parameter's dimensions, so it cannot check the
validity of the supplied units. A corresponding lookup function has been
added in which the dimensions or units can be provided; in this case the
corresponding call would be `dict.lookup<vector>("Umean", dimVelocity)`.
This function enables additional checking and should be used wherever
possible.
Function1-s and Function2-s have had their constructors and selectors
changed so that dimensions/units must be specified by calling code. In
the case of Function1, two unit arguments must be given; one for the
x-axis and one for the value-axis. For Function2-s, three must be
provided.
In some cases, it is desirable (or at least established practice), that
a given non-standard unit be used in the absence of specific
user-defined units. Commonly this includes reading angles in degrees
(rather than radians) and reading times in user-time (rather than
real-time). The primitive lookup functions and Function1 and Function2
selectors both support specifying a non-standard default unit. For
example, `theta_ = dict.lookup<scalar>("theta", unitDegrees)` will read
an angle in degrees by default. If this is done within a model which
also supports writing then the write call must be modified accordingly
so that the data is also written out in degrees. Overloads of writeEntry
have been created for this purpose. In this case, the angle theta should
be written out with `writeEntry(os, "theta", unitDegrees, theta_)`.
Function1-s and Function2-s behave similarly, but with greater numbers
of dimensions/units arguments as before.
The non-standard user-time unit can be accessed by a `userUnits()`
method that has been added to Time. Use of this user-time unit in the
construction of Function1-s should prevent the need for explicit
user-time conversion in boundary conditions and sub-models and similar.
Some models might contain non-typed stream-based lookups of the form
`dict.lookup("p0") >> p0_` (e.g., in a re-read method), or
`Umean_(dict.lookup("Umean"))` (e.g., in an initialiser list). These
calls cannot facilitate unit conversion and are therefore discouraged.
They should be replaced with
`p0_ = dict.lookup<scalar>("p0", dimPressure)` and
`Umean_(dict.lookup<vector>("Umean", dimVelocity))` and similar whenever
they are found.
The alpha equation in this model has been changed to a d2dt2 scheme,
rather than a hard-coded correction on a ddt scheme that relies on the
old-time value remaining unchanged from the previous timestep. This
modification makes the model compatible with some forms of mesh change.
The 'featureAngle' control defines the included angle between faces
above which layer extrusion is prevented. Its use within snappyHexMesh
was incorrect in that the cosine was not being taken before being
compared to dot products of face normals. This has now been corrected.
Existing 'featureAngle' settings may need changing to recover equivalent
behaviour. Any angle previously set to 58 degrees or above previously
resulted in no reduction of layer coverage. A large angle between 90 and
180 degrees is likely to be an appropriate replacement for cases such as
this. Angles previously set to 57 degrees and below can be equivalently
replaced by a value of (180/pi)*arccos(<angle>*(pi/180)).
Note that changing the feature angle also affects the slip feature
angle. The slip feature angle is taken to be half the feature angle if a
'slipFeatureAngle' is not specified.
The coefficients in the polynomial are now specified in order of
increasing exponent, starting from the constant coefficient (i.e., zero
exponent). Exponents are no longer specified. This better fits the
definition of a polynomial, and it prevents the strange scenario when if
exponents are given as a vector or tensor or similar then the units of
the coefficients are not the same across the different components.
For example, polynomial y = -1 + x^2 + 2x^3 can be specified as:
<name> polynomial (-1 0 1 2);
Or, alternatively:
<name>
{
type polynomial;
coeffs (-1 0 1 2);
}
So the user specification is travelInterval rather than
fractionalTravelInterval, and with the dimensions of the distance the object
travels:
- travelInterval: part of the stroke travelled after
which the cached motion scaling weights are recalculated
Unfortunately this is a lot less convenient to specify, particularly as it is
now a dimensioned input which may have to be changed if the stroke or valve lift
table are changed but it was felt by the sponsors of the project that the
automatic method to evaluate the valve lift from the Function1 was not
sufficiently robust.
Now cellZones are handled directly by the applications and the new
cellZone::topoChange function so that any cell can now be in any number of
zones, significantly increasing the flexibility and usefulness of cellZones.
The same rationalisation and generalisation will be applied to faceZones in the
future.
This boundary condition provides a cyclic condition for p_rgh. It applies
corrections to the value and gradient on both sides of the cyclic to
account for the non-cylicity of the gravitational force.
This condition is only needed when the cyclic patches have a transformation
and a normal component in the direction of gravity. If the cyclic patches
are orthogonal to the direction gravity, then a normal cyclic boundary
condition can be used instead.
Care must be taken when using this boundary condition that the simulation
is actually cyclic. The following constraints apply:
- Both cyclic patches must be oriented in the same way with respect to
gravity. In practice this means that applicability is limited to cyclics
with translational transformations.
- The model cannot have any dependence on the absolute value of the
pressure field. The absolute value of the pressure, in reality, varies
between each repetition of the geometry; it is not actually formally
cyclic. Only the gradient of the pressure field can be truly cyclic. This
model is therefore only valid if the absolute value of the pressure is
arbitrary, and only the gradient has an effect on the solution. This is
the case for incompressible multiphase solutions or incompressible
Boussinesq-like models of density variation. It is not true if (for
example) a compressible thermodynamic model is being used.
Specification is as follows. A "patchType" entry must be provided to
indicate that this condition overrides the underlying cyclic constraint,
and a "rhoInf" entry is needed (by the owner patch only) to specify the
density of the far-field environment. For example:
cyclicA
{
type prghCyclicPressure;
patchType cyclic;
rhoInf 1; // [kg/m^3]
}
cyclicB
{
type prghCyclicPressure;
patchType cyclic;
}
A tutorial, incompressibleVoF/trayedPipe, has been added to demonstrate
usage of this boundary condition.
The syntax of this model has changed to permit transfers of species in
either direction. A list of transferring species is now given for each
phase, rather than identifying a single reacting phase. For example:
phaseTransfer
(
vapour_particles
{
type reactionDriven;
// TiO2 and TiO2_s are created by reactions in the vapour
// and are then transferred to the particles
species.vapour (TiO2 TiO2_s);
// H2O is created by reactions in the particles and is then
// transferred to the vapour
species.particles (H2O);
}
);
for example it is now possible to freeze the cylinder head points with respect
to the piston motion but still move with respect to the valve motion by
specifying the cylinderHead pointZone only in the piston specification, e.g.:
piston
{
patches (piston);
axis (0 0 1);
motion
{
type crankConnectingRodMotion;
conRodLength 0.147;
stroke 0.08423;
}
// Move the points in the piston bowl with the piston
movingZones (pistonBowl);
// Freeze the points in the cylinder head
frozenZones (cylinderHead);
// There is no need to update the motion weights
fractionalTravelInterval 1;
}
to calculate and write the forces and moments on moving rigid bodies with
specified or calculated centre of rotation using Foam::RBD::rigidBodyMotion
respectively. The current moving centre of rotation is used in the evaluation
of the moments but does not affect the evaluation of the forces.
Class
Foam::functionObjects::movingForces
Description
Calculates the forces and moments by integrating the pressure and
skin-friction forces over a given list of patches of a moving object.
The centre of rotation (CofR) of the moving object is specified as a
Foam::Function1<vector> of time.
Member function movingForces::write() calculates the forces/moments and
writes the forces/moments into the file \<timeDir\>/movingForces.dat and bin
data (if selected) to the file \<timeDir\>/movingForces_bin.dat
Example of function object specification:
\verbatim
movingForces1
{
type movingForces;
libs ("libforces.so");
log yes;
patches (walls);
CofR
{
type sine;
amplitude (0 0.025 0);
frequency 1;
start 0;
level (0 0 0);
}
}
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | Type name: movingForces | yes |
log | Write force data to standard output | no | no
patches | Patches included in the forces calculation | yes |
p | Pressure field name | no | p
U | Velocity field name | no | U
rho | Density field name (see below) | no | rho
phase | Phase name for phase-fraction | no |
CofR | Centre of rotation Foam::Function1<vector> | yes |
directForceDensity | Force density supplied directly (see below)|no|no
fD | Name of force density field (see below) | no | fD
\endtable
Bin data is optional, but if the dictionary is present, the entries must
be defined according o
\table
nBin | number of data bins | yes |
direction | direction along which bins are defined | yes |
cumulative | bin data accumulated with increasing distance | yes |
\endtable
Note
- For incompressible cases, set \c rho to \c rhoInf and provide
a \c rhoInf value corresponding to the free-stream constant density.
- If the \c phase name is specified the corresponding phase-fraction field
\c alpha.<phase> is used to filter the surface force field
before integration.
- If the force density is supplied directly, set the \c directForceDensity
flag to 'yes', and supply the force density field using the \c
fDName entry
See also
Foam::functionObject
Foam::functionObjects::forcesBase
Foam::functionObjects::fvMeshFunctionObject
Foam::functionObjects::logFiles
Foam::functionObjects::timeControl
Foam::Function1
SourceFiles
movingForces.C
Class
Foam::functionObjects::rigidBodyForces
Description
Calculates the forces and moments by integrating the pressure and
skin-friction forces over a given list of patches of a moving rigid body.
The centre of rotation (CofR) of the moving rigid object is obtained
directly from the corresponding Foam::RBD::rigidBodyMotion of the
specified body.
Member function rigidBodyForces::write() calculates the forces/moments and
writes the forces/moments into the file \<timeDir\>/rigidBodyForces.dat
and bin data (if selected) to the file \<timeDir\>/rigidBodyForces_bin.dat
Example of function object specification:
\verbatim
rigidBodyForces1
{
type rigidBodyForces;
libs ("librigidBodyForces.so");
body (hull);
patches (walls);
log yes;
}
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | Type name: rigidBodyForces | yes |
log | Write force data to standard output | no | no
body | Name of the rigid body | yes |
patches | Patches included in the forces calculation | yes |
p | Pressure field name | no | p
U | Velocity field name | no | U
rho | Density field name (see below) | no | rho
phase | Phase name for phase-fraction | no |
directForceDensity | Force density supplied directly (see below)|no|no
fD | Name of force density field (see below) | no | fD
\endtable
Bin data is optional, but if the dictionary is present, the entries must
be defined according o
\table
nBin | number of data bins | yes |
direction | direction along which bins are defined | yes |
cumulative | bin data accumulated with increasing distance | yes |
\endtable
Note
- For incompressible cases, set \c rho to \c rhoInf and provide
a \c rhoInf value corresponding to the free-stream constant density.
- If the \c phase name is specified the corresponding phase-fraction field
\c alpha.<phase> is used to filter the surface force field
before integration.
- If the force density is supplied directly, set the \c directForceDensity
flag to 'yes', and supply the force density field using the \c
fDName entry
See also
Foam::functionObject
Foam::functionObjects::forcesBase
Foam::functionObjects::fvMeshFunctionObject
Foam::functionObjects::logFiles
Foam::functionObjects::timeControl
Foam::RBD::rigidBodyMotion
SourceFiles
rigidBodyForces.C
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.
This mesh mover facilitates explicit node translation based on scaled distance
functions for the providing smooth deformation of the mesh to accommodate the
motion piston and multiple valves present in IC engines. and run-time mesh-to-mesh mapping used to avoid
extreme mesh distortion and support the necessary topology changes that occur at
valve closure.
Highlighted features include:
* Piston motion based on user-defined functions, with options for standard crank
and connecting rod motion.
* Valve motion based on user-provided lift data or table.
* Support for linerPatches, slidingPatches, and frozenZones.
* Non-conformal coupled (NCC) interfaces can be used to provide better control
of the mesh-motion around valves
* Run-time mesh-to-mesh mapping used to avoid extreme mesh distortion and
support the necessary topology changes that occur at valve closure
* Control over mesh motion per moving object including motion parameters and layer
thickness.
Description from the multiValveEngine.H file:
A mesh mover using explicit node translation based on scaled distance
functions per moving object. The mover supports any number of valves
together with piston motion and following features:
- Piston motion: Function1 of user-time, may be set to
crankConnectingRodMotion for standard crank and connecting rod motion.
- Valve motion: Function1, may be set to table if the valve lift date is
provided in the form of a table.
- Smooth mesh motion between a moving object and other patches.
- linerPatches: the set of patches corresponding to the cylinder liner
Used by createEngineZones
- slidingPatches: a set of patches along which mesh is allowed
to deform. For example, on the cylinder liner, it is desired to
slide mesh nodes while piston is moving.
- frozenZones: list of pointZones the points of which are frozen,
i.e. do not move.
- Run-time clearance estimation based on patch-to-patch distances printed.
- Supports cellSet and cellZone definitions to restrict mesh motion.
- Supports domains with nonConformalCoupling (NCC) interfaces,
enabling e.g. nodes to slide along with the interface.
- Closing the valve can be achieved by meshToMesh mapping onto a new
grid with closed valve geometry at user given time.
- Mesh motion can be controlled per moving object by setting:
- patches: list of patches defining the object.
- motion: a Function1 which returns the object position
as a function of time.
- movingZones: list of pointZones the points of which move with the
object.
- maxMotionDistance: a distance away from the moving object
after nodes are not allowed to move. (Default inf.)
- movingFrozenLayerThickness: thickness of layer in which points move
with the moving object. (Default 0)
- staticFrozenLayerThickness: thickness of layer in which points
are fixed with respect to static patches (e.g. walls). (Default 0)
- cosineScaling: a switch whether nodal translation is weighted by
its distance from the moving object. The objective is to yield less
deformation near the moving object and sustain e.g. boundary layer.
(Default no, i.e. linear weighting)
- fractionalTravelInterval: fraction of the stroke travelled after
which the cached motion scaling weights are recalculated
For valve object only:
- minLift: a minimum valve lift value after considered closed.
Some of the above parameters are highlighted in a given schematic
piston-valve configuration w.r.t entries used to control piston motion.
Furthermore, an example dictionary entries are provided below.
| | | |
| | | |
| | S | |
| | T | |
| | E | |
| | M | |
/ | | \
/ | | \
/ | | \
_____________/ | | \_____________
| : | | : |
| : /``````````````` ```````````````\ : |
| : / VALVE HEAD \ : |
| L : /_____________________________________________\ : |
| I : /\ : |
| N : || staticFrozenLayerThickness : |
| E : NCC (optional) \/ (w.r.t. piston motion) : |
| R : `````````` : |
| : : |
| : : |
|........:.......................................................:........|
| : /\ : |
| : || movingFrozenLayerThickness : |
|________:_________________________\/____________________________:________|
PISTON
\verbatim
mover
{
type multiValveEngine;
libs ("libfvMeshMoversMultiValveEngine.so");
frozenZones (frozenZone1 frozenZone2);
slidingPatches
(
liner
valveStem
"nonCouple.*"
);
linerPatches (liner);
piston
{
patches (piston);
axis (0 0 1);
motion
{
type crankConnectingRodMotion;
conRodLength 1e3;
stroke 1.0;
}
// Move the points in the piston bowl with the piston
movingZones (pistonBowl);
// Optional
maxMotionDistance 1e30;
movingFrozenLayerThickness 0;
staticFrozenLayerThickness 0;
fractionalTravelInterval 0.1;
cosineScaling yes;
}
valves
{
iv
{
patches (valveHead);
axis (0 0 1);
// Optional
maxMotionDistance 1e30;
movingFrozenLayerThickness 0;
staticFrozenLayerThickness 0;
fractionalTravelInterval 0.1;
cosineScaling yes;
minLift 0.001;
motion
{
type table;
values
(
(0 0)
(480 0.1)
(720 0)
);
// For multi-cycle simulations, use repeat
outOfBounds repeat;
interpolationScheme linear;
}
}
}
}
\endverbatim
Note:
The implementation utilises pointDist objects for distance computation,
resulting distance fields do not propagate through NCC interfaces. Hence,
there should be no horizontal NCC interface separating piston from
cylinder head as it would result in potentially ill defined mesh
deformation. Due to same feature, in a schematic case setup above, valve
motion affects only cells between NCC patches even though no cellSet is
explicitly defined.
SourceFiles
multiValveEngine.C
Patch contributed by:
* Heikki Kahila, Wärtsilä Finland: Original implementation
* Bulut Tekgül, Wärtsilä Finland: Testing, cleanup, help with refactoring
* Henry Weller, CFD Direct: Refactoring, generalisation, optimisation and
merging into OpenFOAM
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.
This prevents spurious factors of 1000 from being introduced in
thermodynamic models. It also generalises the system further with
respect to alternative unit sets.
This function now looks up an alphaPhi field by default and exits with
an error if the field cannot be found. In order to solve for alphaPhi a
new 'solveAlphaPhi' switch has to be set.
The documentation has been updated to reflect the fact that the VoF
solvers now store all the alphaPhi fluxes necessary for a in-phase
equation to be constructed.
The phaseScalarTransport function has been added to the damBreakLaminar
tutorial.
The final iteration state is now available from the solutionControl class via
the new finalIteration() static function, replacing the old data class from
which fvMesh was derived. This approach is simpler, more reliable and easier to
extend and reduces the clutter associated with fvMesh.
This lets calling code determine the difference between a polyMesh
topology change and a re-stitch. This prevents unnecessary
post-processing output in a few cases when using NCC; most notably the
generation of cellProc fields by reconstructPar.
A number of fixes have been made in order to make non-conformal cyclic
patches compatible with run-time distribution.
A tutorial case, incompressibleVoF/rotatingCube, has been added which
demonstrates simultaneous usage of motion, non-conformal couplings,
adaptive refinement and load-balancing.
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.
When an fvModel source introduces fluid into a simulation it should also
create a corresponding source term for all properties transported into
the domain by that injection. The source is, effectively, an alternative
form of inlet boundary, on which all transported properties need an
inlet value specified.
These values are now specified in the property field files. The
following is an example of a 0/U file in which the velocity of fluid
introduced by a fvModel source called "injection1" is set to a fixed
value of (-1 0 0):
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
#includeEtc "caseDicts/setConstraintTypes"
wall
{
type noSlip;
}
atmosphere
{
type pressureInletOutletVelocity;
value $internalField;
}
}
// *** NEW ***
sources
{
injection1
{
type uniformFixedValue;
uniformValue (-1 0 0);
}
}
And the following entry in the 0/k file specifies the turbulent kinetic
energy introduced as a fraction of the mean flow kinetic energy:
sources
{
injection1
{
type turbulentIntensityKineticEnergy;
intensity 0.05;
}
}
The specification is directly analogous to boundary conditions. The
conditions are run-time selectable and can be concisely implemented.
They can access each other and be inter-dependent (e.g., the above,
where turbulent kinetic energy depends on velocity). The syntax keeps
field data localised and makes the source model (e.g., massSource,
volumeSource, ...) specification independent from what other models and
fields are present in the simulation. The 'fieldValues' entry previously
required by source models is now no longer required.
If source values need specifying and no source condition has been
supplied in the relevant field file then an error will be generated.
This error is similar to that generated for missing boundary conditions.
This replaces the behaviour where sources such as these would introduce
a value of zero, either silently or with a warning. This is now
considered unacceptable. Zero might be a tolerable default for certain
fields (U, k), but is wholly inappropriate for others (T, epsilon, rho).
This change additionally makes it possible to inject fluid into a
multicomponent solver with a specified temperature. Previously, it was
not possible to do this as there was no means of evaluating the energy
of fluid with the injected composition.
for thermophysical transport within stationary solid phases. This provides a
consistent interface to heat transport within solids for single and now
multiphase solvers so that for example the wallHeatFlux functionObject can now
be used with multiphaseEuler, see tutorials/multiphaseEuler/boilingBed.
Also this development supports anisotropic thermal conductivity within the
stationary solid regions which was not possible previously.
The tutorials/multiphaseEuler/bed and tutorials/multiphaseEuler/boilingBed
tutorial cases have been updated for phaseSolidThermophysicalTransportModel by
changing the thermo type in physicalProperties.solid to heSolidThermo. This
change will need to be made to all multiphaseEuler cases involving stationary
phases.
