which can be opened in ParaView, for it to interpret series of VTK files
generated by OpenFOAM post-processing. This script supercedes the
'foamSequenceVTKFiles' script which generates a directory of indexed
soft-links which is no longer needed. 'foamSequenceVTKFiles' is
nevertheless maintained for workflow backward-compatibility.
in a sequence of VTK files. Instead of loading a group of VTK which
uses their index as time, the respective .vtk.series file can be loaded
which relates each file to the correct time.
for input parameters in OpenFOAM, e.g.
+ to list available units:
foamUnits -list
+ to provide information about the [mm] unit:
foamUnits mm
+ to provide information about the [thermalConductivity] dimensions:
foamUnits -dimension thermalConductivity
+ to provide information about all units:
foamUnits -all
+ to provide information about all dimensions:
foamUnits -all -dimension
*** Note that this commit depends on a corresponding change in
ThirdParty-dev. Ensure that both repositories are up to date before
re-building OpenFOAM.
New environment variables have been added to explicitly control the
installation type of the thirdparty decomposition libraries and of the
ParaView visualiation software. These are set in the etc/bashrc and can
be overridden in a ~/.OpenFOAM/<version>/prefs.sh file or similar.
The variables relating to the decomposition libraries are SCOTCH_TYPE,
METIS_TYPE, PARMETIS_TYPE and ZOLTAN_TYPE, and they can take values of
none, system, or ThirdParty. In the case of ThirdParty, a
<library>_VERSION variable can also be specified. If the version is not
specified then the configuration will search for a source directory, and
if multiple such directories are found then the one with the highest
version number will be used.
The variable relating to ParaView is ParaView_TYPE, and this can be
similarly be set to none, system, or ThirdParty, and ParaView_VERSION
can also be specified when the type is ThirdParty. If the version is not
specified then the installation with the highest version number will be
used.
An example ~/.OpenFOAM/dev/prefs.sh file, in which all decomposition
libraries are enabled, and the Scotch and ParaView versions are
explicitly set, is as follows:
export SCOTCH_TYPE=ThirdParty
export SCOTCH_VERSION=7.0.3
export METIS_TYPE=ThirdParty
export PARMETIS_TYPE=ThirdParty
export ZOLTAN_TYPE=ThirdParty
export ParaView_TYPE=ThirdParty
export ParaView_VERSION=5.11.2
*** Note that if version numbers are not set then the configuration will
search for a decomposition source directory, but it will search for a
ParaView installation directory. This is because decomposition libraries
are built as part of OpenFOAM's ./Allwmake, but ParaView is not. This
distinction remains. If a local compilation of ParaView is needed, then
'./makeParaView -version X.XX.X' should be called explicitly in the
third party directory prior to building OpenFOAM.
The name of the third party directory can now also be independently set.
This simplifies some packaging processes in that it permits third party
to be located within the OpenFOAM installation directory and therefore
bundled into the same binary package.
The editor must be specified by configuring the EDITOR environment
variable. For example to use the 'gedit' editor, the following entry
could be added to the user's .bashrc file:
export EDITOR=gedit
by printing their contents or lines which match a search string.
Usage: ${0##*/} [OPTIONS] <filename>
options:
-a | -applications search for the file from the \$FOAM_APP directory
-d | -dir <dir> specify search directory
-f | -files find wmake 'files' file associated with searched file
-h | -help help
-i | -isearch <string> searches files for a <string>, case insensitive
-m | -modules search for the file from the \$FOAM_MODULES directory
-n | -numbers print line numbers with file output
-o | -options find wmake 'options' file associated with searched file
-p | -print print the file(s)
-s | -search <string> searches files for a <string>, case sensitive
-t | -tutorials search for the file from the \$FOAM_TUTORIALS directory
Finds one or more files in OpenFOAM and optionally processes the contents by:
+ printing the file ('-print' option);
+ printing lines within the file matching a search string ('-search' option).
With source code files, can locate the 'files' and 'options' files associated
with their compilation using 'wmake'.
By default, files are searched from the src (\$FOAM_SRC) directory.
Alternatively the '-dir' option allows the user to specify the search directory
The '-applications', '-modules' and '-tutorials' options specifically set the
search path to the \$FOAM_APP, \$FOAM_MODULES and \$FOAM_TUTORIALS directories,
respectively.
Examples:
foamFind -print wallHeatFlux.C | less
+ click space bar to scroll down
+ enter line number (after ":") to jump to line
+ enter "/text" to search for "text" (or any other string)
foamFind -applications -isearch "momentumtransport" -options fluid.C
foamFind -numbers -search laminar BirdCarreau.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
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
for consistency with fvModels and fvConstraints, to simplify code and case
maintenance and to avoid the potentially complex functions entries being
unnecessarily parsed by utilities for which functionObject evaluation is
disabled.
The functions entry in controlDict is still read if the functions file is not
present for backward-compatibility, but it is advisable to migrate cases to use
the new functions file.
This change makes multiphaseEuler more consistent with other modules and
makes its sub-libraries less inter-dependent. Some left-over references
to multiphaseEulerFoam have also been removed.
The following commands are now possible. Note that the '$' sigil on the
FOAM_TUTORIALS environment variable has been escaped with '\' to prevent
it from being expanded to nothing in the outer/interactive shell.
~/OpenFOAM/OpenFOAM-dev/bin/foamExec ls \$FOAM_TUTORIALS/*
~/OpenFOAM/OpenFOAM-dev/bin/foamExec cp -r \$FOAM_TUTORIALS/incompressibleFluid/pitzDaily .
This avoids potential hidden run-time errors caused by solvers running with
boundary conditions which are not fully specified. Note that "null-constructor"
here means the constructor from patch and internal field only, no data is
provided.
Constraint and simple BCs such as 'calculated', 'zeroGradient' and others which
do not require user input to fully specify their operation remain on the
null-constructor table for the construction of fields with for example all
'calculated' or all 'zeroGradient' BCs.
A special version of the 'inletOutlet' fvPatchField named 'zeroInletOutlet' has
been added in which the inlet value is hard-coded to zero which allows this BC
to be included on the null-constructor table. This is useful for the 'age'
functionObject to avoid the need to provide the 'age' volScalarField at time 0
unless special inlet or outlet BCs are required. Also for isothermalFilm in
which the 'alpha' field is created automatically from the 'delta' field if it is
not present and can inherit 'zeroInletOutlet' from 'delta' if appropriate. If a
specific 'inletValue' is require or other more complex BCs then the 'alpha'
field file must be provided to specify these BCs as before.
Following this improvement it will now be possible to remove the
null-constructors from all fvPatchFields not added to the null-constructor
table, which is most of them, thus reducing the amount of code and maintenance
overhead and making easier and more obvious to write new fvPatchField types.
The new general multi-region framework using the isothermalFilm and film solver
modules and executed with foamMultiRun is a much more flexible approach to the
inclusion of liquid films in simulations with the support for coupling to other
regions of various types e.g. gas flows, Lagrangian clouds, VoF, CHT etc. This
has all been achieved with a significant reduction in the number of lines of
code and significant improvements in code structure, readability and
maintainability.
