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.
Qdot is only relevant for reacting cases, and even then it is only
written out for post-processing purposes. It has been removed from
chtMultiRegionFoam as this solvers' typical usage is for non-reacting
simulations.
If it is desired to obtain Qdot from a chtMultiRegionFoam simulation,
then a better way would be to implement a function object to look up the
reaction model and write it out.
Commit 674bff40 was in the right direction, but pressure dependence also
has to be corrected for, whether the phase is pure or not. The phase now
always updates the thermo whilst maintaining a constant temperature.
An isothermal phase still needs to trigger a thermo update in it's base
classes, primarily to ensure that any inert species fractions get
updated. This will not trigger an actual update of the thermodynamics,
as that is done in AnisothermalPhaseModel.
This is a model for the diameter of vapour bubbles. It calculates the
diameter as a linear function of the liquid sub-cooling.
Also removed the correct method from diameterModel, as it wasn't really
doing anything except facilitating the update of diameter fields to be
written out. Derived sub-models can control this locally without
polluting the base interface.
Based on patch contributed by by Juho Peltola, VTT.
By default the prefix is no longer added to the field names but the previous
behaviour can be reproduced by setting the optional "prefix" entry to "on" or
"yes".
to avoid the need to evaluate departure functions and simplify evaluation of the
temperature. In general it makes more sense to use and e/Cv based
thermodynamics when solving for internal energy rather than h/Cp and have
convert between the energy forms.
All related tutorials and test cases have also been updated.
