The base jump cyclic patch now no longer assumes that the jump applies
equally to both sides. The jump() method for a field now returns the
jump appropriate for a transfer to the field in question; the base patch
no longer has to do any explicit negation. This provides the opportunity
to create alternative types of jump.
The derived classes are now well defined in terms of their construction.
No conditions require a "value" entry. Whether or not a "jump" entry
is required depends on whether the condition can re-calculate the jump
field without reference to other fields or boundary conditions. The
presence or otherwise of a jump or value entry should no longer result in
lookup failures or floating point errors or similar.
The concept of cell and face inflation proved unworkable in general and has been
replaced by the more flexible and robust cell-splitting combined with
conservative interpolative mapping and mesh morphing as appropriate.
The concept of cell inflation from faces or points proved unworkable in general
and has been replaced by the more flexible and robust cell-splitting combined
with conservative interpolative mapping and mesh morphing as appropriate.
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);
}
);
This function can now be run interactively using the following command:
foamPostProcess -func "cylindrical(origin=(0 0 0), axis=(0 0 1), U)"
Or it can be executed at run time by adding the following entry in the
system/functions file:
#includeFunc cylindrical(origin=(0 0 0), axis=(0 0 1), U)
Needed to support overlapping faceZones with topology change
//- Return the list of flips for the facei
// for each of the face zones in faceiZones
boolList zonesFlipFace
(
const label facei,
const labelList& faceiZones
);
//- Given a global object index, return the list of zones it is in
labelList whichZones(const label objectIndex) const;
which will replace the original whichZone function
//- Given a global object index, return the zone it is in.
// If object does not belong to any zones, return -1
// *** This will be replaced by whichZones
label whichZone(const label objectIndex) const;
so that cells, faces and points can exist in any number of zones.
This is an alternative, approximate parameterisation of the JONSWAP
spectrum, in which the significant wave height and period are specified
instead of the wind speed and fetch.
Example specification, in constant/waveProperties:
waves
(
irregular
{
spectrum GodaJONSWAP;
Hs 2; // <- significant wave height [m]
Ts 6; // <- significant wave period [s]
n 12; // <- number of samples []
angle 0;
}
);
Constructing the fields in patch order is logical, and preferable to
using the potentially arbitrary order in which the fields are specified
in the field dictionary. It also resolves the issue that the
construction of jump cyclics can fail if the patch fields are not
specified in the same order as the patches.
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;
}
The FV patches don't hold any data that requires updating. If they did,
then they would require a full set of mesh change hooks (i.e.,
topoChange, distribute, and mesh mapping, as well as move). The poly
patches currently hold all of this sort of data, and have a complete
system of methods to handle mesh changes.
