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.
to calculate and write the forces and moments on moving rigid bodies with
specified or calculated centre of rotation using Foam::RBD::rigidBodyMotion
respectively. The current moving centre of rotation is used in the evaluation
of the moments but does not affect the evaluation of the forces.
Class
Foam::functionObjects::movingForces
Description
Calculates the forces and moments by integrating the pressure and
skin-friction forces over a given list of patches of a moving object.
The centre of rotation (CofR) of the moving object is specified as a
Foam::Function1<vector> of time.
Member function movingForces::write() calculates the forces/moments and
writes the forces/moments into the file \<timeDir\>/movingForces.dat and bin
data (if selected) to the file \<timeDir\>/movingForces_bin.dat
Example of function object specification:
\verbatim
movingForces1
{
type movingForces;
libs ("libforces.so");
log yes;
patches (walls);
CofR
{
type sine;
amplitude (0 0.025 0);
frequency 1;
start 0;
level (0 0 0);
}
}
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | Type name: movingForces | yes |
log | Write force data to standard output | no | no
patches | Patches included in the forces calculation | yes |
p | Pressure field name | no | p
U | Velocity field name | no | U
rho | Density field name (see below) | no | rho
phase | Phase name for phase-fraction | no |
CofR | Centre of rotation Foam::Function1<vector> | yes |
directForceDensity | Force density supplied directly (see below)|no|no
fD | Name of force density field (see below) | no | fD
\endtable
Bin data is optional, but if the dictionary is present, the entries must
be defined according o
\table
nBin | number of data bins | yes |
direction | direction along which bins are defined | yes |
cumulative | bin data accumulated with increasing distance | yes |
\endtable
Note
- For incompressible cases, set \c rho to \c rhoInf and provide
a \c rhoInf value corresponding to the free-stream constant density.
- If the \c phase name is specified the corresponding phase-fraction field
\c alpha.<phase> is used to filter the surface force field
before integration.
- If the force density is supplied directly, set the \c directForceDensity
flag to 'yes', and supply the force density field using the \c
fDName entry
See also
Foam::functionObject
Foam::functionObjects::forcesBase
Foam::functionObjects::fvMeshFunctionObject
Foam::functionObjects::logFiles
Foam::functionObjects::timeControl
Foam::Function1
SourceFiles
movingForces.C
Class
Foam::functionObjects::rigidBodyForces
Description
Calculates the forces and moments by integrating the pressure and
skin-friction forces over a given list of patches of a moving rigid body.
The centre of rotation (CofR) of the moving rigid object is obtained
directly from the corresponding Foam::RBD::rigidBodyMotion of the
specified body.
Member function rigidBodyForces::write() calculates the forces/moments and
writes the forces/moments into the file \<timeDir\>/rigidBodyForces.dat
and bin data (if selected) to the file \<timeDir\>/rigidBodyForces_bin.dat
Example of function object specification:
\verbatim
rigidBodyForces1
{
type rigidBodyForces;
libs ("librigidBodyForces.so");
body (hull);
patches (walls);
log yes;
}
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | Type name: rigidBodyForces | yes |
log | Write force data to standard output | no | no
body | Name of the rigid body | yes |
patches | Patches included in the forces calculation | yes |
p | Pressure field name | no | p
U | Velocity field name | no | U
rho | Density field name (see below) | no | rho
phase | Phase name for phase-fraction | no |
directForceDensity | Force density supplied directly (see below)|no|no
fD | Name of force density field (see below) | no | fD
\endtable
Bin data is optional, but if the dictionary is present, the entries must
be defined according o
\table
nBin | number of data bins | yes |
direction | direction along which bins are defined | yes |
cumulative | bin data accumulated with increasing distance | yes |
\endtable
Note
- For incompressible cases, set \c rho to \c rhoInf and provide
a \c rhoInf value corresponding to the free-stream constant density.
- If the \c phase name is specified the corresponding phase-fraction field
\c alpha.<phase> is used to filter the surface force field
before integration.
- If the force density is supplied directly, set the \c directForceDensity
flag to 'yes', and supply the force density field using the \c
fDName entry
See also
Foam::functionObject
Foam::functionObjects::forcesBase
Foam::functionObjects::fvMeshFunctionObject
Foam::functionObjects::logFiles
Foam::functionObjects::timeControl
Foam::RBD::rigidBodyMotion
SourceFiles
rigidBodyForces.C
foamMonitor has new options to select columns of data, plot the data on
x-axis and the independent variable on y-axis, and to display a single
graph without refreshing periodically. It also now terminates cleanly,
removing the gnuplot processes behind it.
New options:
-columns | -c <cols> display specfied columns, comma-separated, e.g. 2,4
-flip | -f plot data on x-axis, independent variable on y-axis
-once | -o print a graph one time without refreshing
for the multiValveEngine fvMeshMover. This replaced the hard-coded messages
printed by the multiValveEngine class, providing automatic logging of the piston
and valve speed and position and easy user extension or replacement to provide
additional case-specific diagnostics without having to hack the core
multiValveEngine code. A functionObject configuration file is provided so that
the simple line
can be added to the system/functions file to enable this functionObject.
This utility is used as a pre-processing step for the multiValveEngine
fvMeshMover and provides two options:
-cylinderHead to generate the pointZone within the cylinder head
-pistonBowl to generate the pointZone within the piston bowl
The updated tutorials/XiFluid/kivaTest case demonstrates the application of this
utility.
This mesh mover facilitates explicit node translation based on scaled distance
functions for the providing smooth deformation of the mesh to accommodate the
motion piston and multiple valves present in IC engines. and run-time mesh-to-mesh mapping used to avoid
extreme mesh distortion and support the necessary topology changes that occur at
valve closure.
Highlighted features include:
* Piston motion based on user-defined functions, with options for standard crank
and connecting rod motion.
* Valve motion based on user-provided lift data or table.
* Support for linerPatches, slidingPatches, and frozenZones.
* Non-conformal coupled (NCC) interfaces can be used to provide better control
of the mesh-motion around valves
* Run-time mesh-to-mesh mapping used to avoid extreme mesh distortion and
support the necessary topology changes that occur at valve closure
* Control over mesh motion per moving object including motion parameters and layer
thickness.
Description from the multiValveEngine.H file:
A mesh mover using explicit node translation based on scaled distance
functions per moving object. The mover supports any number of valves
together with piston motion and following features:
- Piston motion: Function1 of user-time, may be set to
crankConnectingRodMotion for standard crank and connecting rod motion.
- Valve motion: Function1, may be set to table if the valve lift date is
provided in the form of a table.
- Smooth mesh motion between a moving object and other patches.
- linerPatches: the set of patches corresponding to the cylinder liner
Used by createEngineZones
- slidingPatches: a set of patches along which mesh is allowed
to deform. For example, on the cylinder liner, it is desired to
slide mesh nodes while piston is moving.
- frozenZones: list of pointZones the points of which are frozen,
i.e. do not move.
- Run-time clearance estimation based on patch-to-patch distances printed.
- Supports cellSet and cellZone definitions to restrict mesh motion.
- Supports domains with nonConformalCoupling (NCC) interfaces,
enabling e.g. nodes to slide along with the interface.
- Closing the valve can be achieved by meshToMesh mapping onto a new
grid with closed valve geometry at user given time.
- Mesh motion can be controlled per moving object by setting:
- patches: list of patches defining the object.
- motion: a Function1 which returns the object position
as a function of time.
- movingZones: list of pointZones the points of which move with the
object.
- maxMotionDistance: a distance away from the moving object
after nodes are not allowed to move. (Default inf.)
- movingFrozenLayerThickness: thickness of layer in which points move
with the moving object. (Default 0)
- staticFrozenLayerThickness: thickness of layer in which points
are fixed with respect to static patches (e.g. walls). (Default 0)
- cosineScaling: a switch whether nodal translation is weighted by
its distance from the moving object. The objective is to yield less
deformation near the moving object and sustain e.g. boundary layer.
(Default no, i.e. linear weighting)
- fractionalTravelInterval: fraction of the stroke travelled after
which the cached motion scaling weights are recalculated
For valve object only:
- minLift: a minimum valve lift value after considered closed.
Some of the above parameters are highlighted in a given schematic
piston-valve configuration w.r.t entries used to control piston motion.
Furthermore, an example dictionary entries are provided below.
| | | |
| | | |
| | S | |
| | T | |
| | E | |
| | M | |
/ | | \
/ | | \
/ | | \
_____________/ | | \_____________
| : | | : |
| : /``````````````` ```````````````\ : |
| : / VALVE HEAD \ : |
| L : /_____________________________________________\ : |
| I : /\ : |
| N : || staticFrozenLayerThickness : |
| E : NCC (optional) \/ (w.r.t. piston motion) : |
| R : `````````` : |
| : : |
| : : |
|........:.......................................................:........|
| : /\ : |
| : || movingFrozenLayerThickness : |
|________:_________________________\/____________________________:________|
PISTON
\verbatim
mover
{
type multiValveEngine;
libs ("libfvMeshMoversMultiValveEngine.so");
frozenZones (frozenZone1 frozenZone2);
slidingPatches
(
liner
valveStem
"nonCouple.*"
);
linerPatches (liner);
piston
{
patches (piston);
axis (0 0 1);
motion
{
type crankConnectingRodMotion;
conRodLength 1e3;
stroke 1.0;
}
// Move the points in the piston bowl with the piston
movingZones (pistonBowl);
// Optional
maxMotionDistance 1e30;
movingFrozenLayerThickness 0;
staticFrozenLayerThickness 0;
fractionalTravelInterval 0.1;
cosineScaling yes;
}
valves
{
iv
{
patches (valveHead);
axis (0 0 1);
// Optional
maxMotionDistance 1e30;
movingFrozenLayerThickness 0;
staticFrozenLayerThickness 0;
fractionalTravelInterval 0.1;
cosineScaling yes;
minLift 0.001;
motion
{
type table;
values
(
(0 0)
(480 0.1)
(720 0)
);
// For multi-cycle simulations, use repeat
outOfBounds repeat;
interpolationScheme linear;
}
}
}
}
\endverbatim
Note:
The implementation utilises pointDist objects for distance computation,
resulting distance fields do not propagate through NCC interfaces. Hence,
there should be no horizontal NCC interface separating piston from
cylinder head as it would result in potentially ill defined mesh
deformation. Due to same feature, in a schematic case setup above, valve
motion affects only cells between NCC patches even though no cellSet is
explicitly defined.
SourceFiles
multiValveEngine.C
Patch contributed by:
* Heikki Kahila, Wärtsilä Finland: Original implementation
* Bulut Tekgül, Wärtsilä Finland: Testing, cleanup, help with refactoring
* Henry Weller, CFD Direct: Refactoring, generalisation, optimisation and
merging into OpenFOAM
