Two boundary conditions for the modelling of semi-permeable baffles have
been added. These baffles are permeable to a number of species within
the flow, and are impermeable to others. The flux of a given species is
calculated as a constant multipled by the drop in mass fraction across
the baffle.
The species mass-fraction condition requires the transfer constant and
the name of the patch on the other side of the baffle:
boundaryField
{
// ...
membraneA
{
type semiPermeableBaffleMassFraction;
samplePatch membranePipe;
c 0.1;
value uniform 0;
}
membraneB
{
type semiPermeableBaffleMassFraction;
samplePatch membraneSleeve;
c 0.1;
value uniform 1;
}
}
If the value of c is omitted, or set to zero, then the patch is
considered impermeable to the species in question. The samplePatch entry
can also be omitted in this case.
The velocity condition does not require any special input:
boundaryField
{
// ...
membraneA
{
type semiPermeableBaffleVelocity;
value uniform (0 0 0);
}
membraneB
{
type semiPermeableBaffleVelocity;
value uniform (0 0 0);
}
}
These two boundary conditions must be used in conjunction, and the
mass-fraction condition must be applied to all species in the
simulation. The calculation will fail with an error message if either is
used in isolation.
A tutorial, combustion/reactingFoam/RAS/membrane, has been added which
demonstrates this transfer process.
This work was done with support from Stefan Lipp, at BASF.
The forces function object, when specified with a full coordinate
system, previously wrote forces and moments out in the following format:
time-0 forces-0 moments-0
time-0 localForces-0 localMoments-0
time-1 forces-1 moments-1
time-1 localForces-1 localMoments-1
# etc ...
There are two rows of values per time. This complicates the definition
of the table and means that filtering has to be done before the data
series can be visualised. The format has now been changed to the
following form:
time-0 forces-0 moments-0 localForces-0 localMoments-0
time-1 forces-1 moments-1 localForces-1 localMoments-1
# etc ...
There is one row per time, and each column is therefore a continuous
series of one variable that can be plotted.
To disable face correspondence checking set
checkFaceCorrespondence off;
in blockMeshDict. This is necessary in the rare cases where adjacent block
faces do not need to correspond because they are geometrically collapsed,
e.g. to form a pole/axis.
Resolves bug-report https://bugs.openfoam.org/view.php?id=2711
A wavePressure boundary condition has been added, and the Airy-type wave
models have been extended to generate the unsteady pressure field. This
provides another option for specifying wave motion at a boundary.
If a waveVelocity condition is used in isolation, then any outlet flow
will be extrapolated and scaled to match the required flow rate. This is
similar to how a flowRateOutletVelocity condition works.
0/U:
<patchName>
{
type waveVelocity;
// wave parameters ...
}
0/p_rgh:
<patchName>
{
type fixedFluxPressure;
}
If a waveVelocity is used in conjunction with the new wavePressure
condition, then one will set the value and the other the gradient, as
appropriate for the direction of the flow.
0/U:
<patchName>
{
type waveVelocity;
// wave parameters ...
p p_rgh;
}
0/p_rgh:
<patchName>
{
type wavePressure;
}
This new pressure-velocity formulation is less stable, but generates
more accurate waveforms on patches where the velocity reverses. It is
also necessary for sub-surface cases where fixing the velocity around
the entire domain generates a continuity error.
This work was supported by Alice Gillespie, on behalf of M3 Wave
Removed templating from integration schemes, improved the name
convention, and optimised the utilisation so that the virtual call is
only made once per integration in the KinematicParcel and the
ThermoParcel.
The integration of force and heat transfer onto the particle is
facilitated by a run-time-selectable integration scheme. These schemes
were written to generate the value at the end of an intregration step
and also an average value over the step from which the total transfer
was computed.
The average value in the Euler scheme was implemented incorrectly, which
resulted in the momentum and heat transfer processes being
non-conservative. Implementing the average correctly, however, would
have inteoduced a number of trancendental functions which would have
negated the purpose of the Euler scheme as the cheap and stable option.
The schemes have been rewritten to generate changes over the step,
rather than the final value. This change is then used to calculate the
transfers. Regardless of the scheme, this formulation is guaranteed to
be conservative, and the Euler scheme remains computationally
inexpensive.
This change was made with help from Timo Niemi, VTT
This resolves bug report https://bugs.openfoam.org/view.php?id=2666
XiEngineFoam is a premixed/partially-premixed combustion engine solver which
exclusively uses the Xi flamelet combustion model.
engineFoam is a general engine solver for inhomogeneous combustion with or
without spray supporting run-time selection of the chemistry-based combustion
model.
Standard crank-connecting rod and the new free-piston kinematics motion options
are provides, others can easily be added.
Contributed by Francesco Contino and Nicolas Bourgeois, BURN Research Group.
The 4.x tracking enforces reduced dimensionality on the parcels by
moving them to the centre of the mesh at the start of each track,
without considering the topology. This can leave the parcel outside it's
associated tetrahedron.
The barycentric algorithm isn't tolerant to incorrect topology, so
instead of changing position, it was written to track to the mesh
centre. This worked, but effectively doubled the number of tracking
calls. This additional cost has now been removed by absorbing the
constraint displacement into the existing motion track, so that the same
number of tracking steps are performed as before.
Partially resolves bug report https://bugs.openfoam.org/view.php?id=2688
The splash kinetic energy has been changed to depend upon the velocity
of the parcel normal to the wall, rather than the absolute velocity, in
accordance with the original reference.
This patch was contributed by Stefan Hildenbrand at Pfinder
Resolves bug report https://bugs.openfoam.org/view.php?id=2682
Interpolated continuous phase data is only needed during a track and
therefore shouldn't be stored on the parcel. The continuous velocity,
density and viscosity have been moved from the kinematic parcel to the
kinematic parcel tracking data. This reduces the memory usage of the
kinematic layer by about one third. The thermo and reacting layers still
require the same treatment.
