This allows for more than one of these data types to be specified in a dictionary
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1652
e.g.
<entryName> csvFile;
<entryName>Coeffs
{
nHeaderLine 4;
refColumn 0; // reference column index
componentColumns (1 2 3); // component column indices
separator ","; // optional (defaults to ",")
mergeSeparators no; // merge multiple separators
fileName "fileXYZ"; // name of csv data file
outOfBounds clamp; // optional out-of-bounds handling
interpolationScheme linear; // optional interpolation scheme
}
This approach simply accumulates data outside the range of the bins into
the first or last bin which may be OK for small motions. For larger
motions it may be better if the bins are updated or operate in a
coordinate system attached to the body for solid-body motion.
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1560
This is an experimental feature demonstrating the potential of MULES to
create bounded solution which are 2nd-order in time AND space.
Crank-Nicolson may be selected on U and/or alpha but will only be fully
2nd-order if used on both within the PIMPLE-loop to converge the
interaction between the flux and phase-fraction. Note also that
Crank-Nicolson may not be used with sub-cycling but all the features of
semi-implicit MULES are available in particular MULESCorr and
alphaApplyPrevCorr.
Examples of ddt specification:
ddtSchemes
{
default Euler;
}
ddtSchemes
{
default CrankNicolson 0.9;
}
ddtSchemes
{
default none;
ddt(alpha) CrankNicolson 0.9;
ddt(rho,U) CrankNicolson 0.9;
}
ddtSchemes
{
default none;
ddt(alpha) Euler;
ddt(rho,U) CrankNicolson 0.9;
}
ddtSchemes
{
default none;
ddt(alpha) CrankNicolson 0.9;
ddt(rho,U) Euler;
}
In these examples a small amount of off-centering in used to stabilize
the Crank-Nicolson scheme. Also the specification for alpha1 is via the
generic phase-fraction name to ensure in multiphase solvers (when
Crank-Nicolson support is added) the scheme is identical for all phase
fractions.
This development is back-ported from OpenFOAM-dev:
f78d33b634
Consider a block describing a channel with two opposite walls.
Currently in order to grade the mesh towards the walls and have a
uniform region in the centre the channel would need to be spit into 3
blocks. With the new multi/sectional grading this can be achieved in a
single block e.g.
blocks
(
hex (0 1 2 3 4 5 6 7) (20 60 20)
simpleGrading
(
1
((0.2 0.3 4) (0.6 0.4 1) (0.2 0.3 0.25))
1
)
);
In this example the block is divided uniformly in the x and z -directions
and split into three grading sections in the y-direction described by
three triples: ((0.2 0.3 4) (0.6 0.4 1) (0.2 0.3 0.25)). Each of the
grading sections is described by a triple consisting of the fraction of
the block, the fraction of the divisions and the grading ratio (size of
first division/size of last division). Both the fraction of the block
and the fraction of the divisions are normalized automatically so they
can be specified scaled in anyway, e.g. as percentages:
blocks
(
hex (0 1 2 3 4 5 6 7) (20 60 20)
simpleGrading
(
1
((2 3 4) (6 4 1) (2 3 0.25))
1
)
);
and they need not sum to 1 or 100.
This is very new functionality and not well tested but backward
compatibility has been well tested so all existing blockMeshDicts should
parse correctly.
This version is very inefficient in parallel and does not provide the
-parallelSource or -parallelTarget options which will need to be
reinstanted in the future or we could revert mapFields to the
OpenFOAM-2.2 version.
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1495
