The position and direction of cone injection sites can now be specified
using Function1 to make them change in time, relative to the start of
injection.
An example specification of the relevant entries is shown below.
injectionModels
{
injection1
{
type coneInjection;
position table
(
(0 (-0.1 -0.1 0))
(0.25 (0.1 -0.1 0))
(0.5 (0.1 0.1 0))
(0.75 (-0.1 0.1 0))
(1 (-0.1 -0.1 0))
);
direction table
(
(0 (-1 -1 0))
(0.25 (1 -1 0))
(0.5 (1 1 0))
(0.75 (-1 1 0))
(1 (-1 -1 0))
);
outOfBounds repeat;
// etc ...
}
}
Sub-dictionaries can also be used if the keywords of parameters of the
two functions collide:
injectionModels
{
injection1
{
type coneInjection;
position tableFile;
positionCoeffs
{
file "constant/injection1.positions";
outOfBounds clamp;
}
direction tableFile;
directionCoeffs
{
file "constant/injection1.directions";
outOfBounds repeat;
}
// etc ...
}
}
A check is also done to determine whether a constant function is in use
on a stationary mesh, in order to prevent repeated searching for the
same position, and therefore retain approximately the efficiency of the
previous implementation in simple cases.
The energy transfer associated with phase change has been corrected in
the case that the variable being solved for is internal energy.
Patch contributed by Juho Peltola, VTT.
for consistency with WM_PROJECT. Now "etc" files are assumed to be in etc
sub-directories of WM_PROJECT_SITE and WM_PROJECT_INST_DIR allowing other files
to be stored in those directories. The search order is now:
Search for files from user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/
- ~/.OpenFOAM/
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/etc/
- $WM_PROJECT_SITE/etc/
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/etc/
- $WM_PROJECT_INST_DIR/site/etc/
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/
\return The list of full paths of all the matching files or
an empty list if the name cannot be found.
Optionally abort if the file cannot be found.
Optionally stop search after the first file has been found.
This change was proposed and agreed by the sponsors of the OpenFOAM project on
the OpenFOAM Hub, see https://openfoam.org/maintenance/
This object calculates a field of the age of fluid in the domain; i.e.,
the time taken for a fluid particle to travel to a location from an
inlet. It outputs a field, named age, with dimensions of time, and
requires a solver and a div(phi,age) scheme to be specified. A number of
corrections for the solution procedure can be set, as well as the name
of the flux and density fields.
Example specification:
age1
{
type age;
libs ("libfieldFunctionObjects.so");
nCorr 10;
phi phi;
rho rho;
}
Example usage:
postProcess -func age -fields "(phi)" -latestTime
This work was supported by Robert Secor and Lori Holmes, at 3M
The selection of the "Final" solver settings is now handled automatically within
the "<equation>.solve()" call and there is no longer any need no provide a bool
argument for specific cases. This simplifies the solution algorithm loop
structures and ensures consistency in behaviour across all solvers.
All tutorials have been updated to correspond to the now consistent rules.
Now for transient simulations "Final" solver settings are required for ALL
equations providing consistency between the solution of velocity, energy,
composition and radiation properties.
However "Final" relaxation factors are no longer required for fields or
equations and if not present the standard value for the variable will be
applied. Given that relaxation factors other than 1 are rarely required for
transient runs and hence the same for all iterations including the final one
this approach provide simpler input while still providing the flexibility to
specify a different value for the final iteration if required. For steady cases
it is usual to execute just 1 outer iteration per time-step for which the
standard relaxation factors are appropriate, and if more than one iteration is
executed it is common to use the same factors for both. In the unlikely event
of requiring different relaxation factors for the final iteration this is still
possible to specify via the now optional "Final" specification.
Description
This boundary condition provides a pressure jump condition, using
the \c cyclic condition as a base.
The jump is specified as a \c Function1 type, to enable the use of, e.g.
constant, polynomial, table values. This boundary condition can operate
in two modes - standard and backward compatibility.
In standard mode, jump is specified as a function of total volumetric
flow rate through the patch. In backward compatibility mode, the boundary
conditions serves as a direct replacement for the fanFvPatchField, where
jump is defined as a function of local velocity.
Usage
\table
Property | Description | Required | Default value
patchType | underlying patch type should be \c cyclic| yes |
fanCurve | fan curve, e.g. \c csvFile | yes |
jumpTable | jump data (backward compatibility mode) | no |
reverse | reverse jump direction | no | false
phi | flux field name | no | phi
rho | density field name | no | rho
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type fan;
patchType cyclic;
fanCurve csvFile;
csvFileCoeffs
{
hasHeaderLine 1;
refColumn 0;
componentColumns 1(1);
separator ",";
file "$FOAM_CASE/constant/pressureVsQ";
}
value uniform 0;
}
\endverbatim
The above example shows the use of a comma separated (CSV) file to specify
the jump condition.
Contributed by Daniel Jasinski
Resolves bug-report https://bugs.openfoam.org/view.php?id=3102#c10159
Includes topological point generation and optional removal of all points (and
triangles) that do not originate from mesh edges. This generates
polygons rather than triangles providing smoother surfaces and significantly
small files (~ factor of 3-4 smaller).
Contributed by Mattijs Janssens
This was not being used and had not been kept up to date. It also didn't
actually do dimension checking, so the name was misleading, and the
functionality added on top of SubField was minimal.
coneInjection has been extended to include the functionality of
coneNozzleInjection, and the latter has been removed.
Some parameters have changed names. The "positionAxis" entry from
coneInjection has been removed in preferance of coneNozzleInjection's
single "position" and "direction" entries. This means that only one
injection site is possible per model (dictionary substitutions mean that
only minimal additions are required to add further injection sites with
the same parameters). The name of the velocity magnitude has been
standardised as "Umag" and "innerDiameter" and "outerDiamater" have been
renamed "dInner" and "dOuter" for consistency with the inner and outer
spray angles.
Velocity magnitude and diameters are no longer read when they are not
required.
The randomisation has been altered so that the injections generate a
uniform distribution on an cross section normal to the direction of
injection. Previously there was an unexplained bias towards the
centreline.
An example specification with a full list of parameters is shown below.
injectionModels
{
model1
{
type coneInjection;
// Times
SOI 0;
duration 1;
// Quantities
massTotal 0; // <-- not used with these settings
parcelBasisType fixed;
parcelsPerSecond 1000000;
flowRateProfile constant 1;
nParticle 1;
// Sizes
sizeDistribution
{
type fixedValue;
fixedValueDistribution
{
value 0.0025;
}
}
// Geometry
positions (-0.15 -0.1 0);
directions (1 0 0);
thetaInner 0;
thetaOuter 45;
// - Inject at a point
injectionMethod point;
// - Or, inject over a disc:
/*
injectionMethod disc;
dInner 0;
dOuter 0.05;
*/
// Velocity
// - Inject with constant velocity
flowType constantVelocity;
Umag 1;
// - Or, inject with flow rate and discharge coefficient
// This also requires massTotal, dInner and dOuter
/*
flowType flowRateAndDischarge;
Cd 0.9;
*/
// - Or, inject at a pressure
/*
flowType pressureDrivenVelocity;
Pinj 10e5;
*/
}
model2
{
// The same as model1, but at a different position
$model1;
position (-0.15 0.1 0);
}
}
to simplify reacting case setup.
Tutorials
tutorials/combustion/chemFoam/ic8h18_TDAC
tutorials/combustion/reactingFoam/RAS/SandiaD_LTS
tutorials/combustion/reactingFoam/laminar/counterFlowFlame2DLTS_GRI_TDAC
tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D_GRI_TDAC
updated to benefit from the new configuration files.
Patch contributed by Francesco Contino
This can be used to speedup simulations that converge to a steady state
by only updating the source terms once every few iterations. The number
of iterations between each update is set in fvSolution as follows:
solvers
{
bubbles
{
sourceUpdateInterval 10;
}
// etc ...
}
By default the interval is 1, and so the sources update every time.
Based on a patch contributed by Juho Peltola, VTT.
