So the user specification is travelInterval rather than
fractionalTravelInterval, and with the dimensions of the distance the object
travels:
- travelInterval: part of the stroke travelled after
which the cached motion scaling weights are recalculated
Unfortunately this is a lot less convenient to specify, particularly as it is
now a dimensioned input which may have to be changed if the stroke or valve lift
table are changed but it was felt by the sponsors of the project that the
automatic method to evaluate the valve lift from the Function1 was not
sufficiently robust.
This class is no longer pure virtual, and can be constructed for any
object registry. This means it can be used as a generic physical
properties dictionary, as well as being derived into more specific
contexts (i.e., finite-volume viscosity and thermodynamic models).
Corrected according to the original reference:
Marschall, H. (2011).
Towards the numerical simulation of multi-scale two-phase flows.
PhD Thesis, TU München.
The old-time field implementation has been removed from GeometricField
and put in a separate base class. This class is now used as a base of
both GeometricField and DimensionedField, thereby adding oldTime
functionality to the latter.
Care has been taken to ensure that a GeometricField never duplicates the
old-time field by storing it in both the GeometricField and
DimensionedField classes. When a GeometricField creates an old-time
field it pushes the reference down into the DimensionedField so that the
latter does not then create its own copy of the old-times.
The writeObjects functionObject has been updated to use printToc() when an
object cannot be found and now for the incompressibleFluid/pitzDailySteady case
it prints:
--> FOAM Warning : writeObjects: object hmm not found in database. Available objects:
Cc volVectorField
Cf surfaceVectorField
GAMGAgglomeration faceAreaPair
MRFProperties dictionary
Residuals<scalar> Residuals<scalar>
Residuals<sphericalTensor> Residuals<sphericalTensor>
Residuals<symmTensor> Residuals<symmTensor>
Residuals<tensor> Residuals<tensor>
Residuals<vector> Residuals<vector>
Sf surfaceVectorField
U volVectorField
Vc volScalarField::Internal
boundary polyBoundaryMesh
cellZones cellZoneList
epsilon volScalarField
faceZones faceZoneList
faces faceCompactList
fvConstraints fvConstraints
fvModels fvModels
fvSchemes dictionary
fvSolution dictionary
k volScalarField
kEpsilon:G volScalarField::Internal
magSf surfaceScalarField
momentumTransport kEpsilon
nearWallDist nearWallDist
neighbour labelList
nu volScalarField
nut volScalarField
owner labelList
p volScalarField
phi surfaceScalarField
physicalProperties constant
pointConstraints pointConstraints
pointMesh pointMesh
pointZones pointZoneList
points vectorField
solutionControl pimpleNoLoopControl
solver incompressibleFluid
tetBasePtIs labelList
volPointInterpolate(U) pointVectorField
volPointInterpolate(k) pointScalarField
volPointInterpolate(p) pointScalarField
volPointInterpolation volPointInterpolation
Renamed names and sortedNames functions to toc and sortedToc for consistency
with HashTable and all derived containers allowing reuse of the HashTable
functions.
Now the HashTable underlying PtrListDictionary is used for zone lookup by name
which is a lot faster than the linear search method used previously if there are
a large number of zones.
Now faceZones are handled directly by the applications and the new
faceZone::topoChange function so that any face can now be in any number of
zones, significantly increasing the flexibility and usefulness of faceZones.
This completes the generalisation of cellZone, faceZone and pointZone to support
multiple zones for each cell, face or point respectively. Next step will be to
make zones polymorphic and run-time selectable so that they can alter during the
run and adapt to moving meshes for example.
For a case extruding patches left and right:
sourcePatches (left right);
if the optional zoneNames entry is also specified in extrudeMeshDict
zoneNames (leftCells rightCells);
the cells extruded from the left patch are added to the leftCells cellZone and
the cells extruded from the right patch are added to the rightCells cellZone.
Alternatively if a single zone name is specified, e.g.
zoneNames (extrudedCells);
then cells extruded from the left and right patches are added to the
extrudedCells cellZone.
If the number of patches to extrude is large it might be more convenient for
the cells extruded from each patch to be added to a cellZone named the same as
each patch, this option is selected by setting zoneNames to patchNames:
zoneNames (patchNames);
Now cellZones are handled directly by the applications and the new
cellZone::topoChange function so that any cell can now be in any number of
zones, significantly increasing the flexibility and usefulness of cellZones.
The same rationalisation and generalisation will be applied to faceZones in the
future.
