40bcabf79f2d2a286fafaecc9efaf853cb94c19d
14 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 476bb42b04 |
unitConversion: Unit conversions on all input parameters
The majority of input parameters now support automatic unit conversion.
Units are specified within square brackets, either before or after the
value. Primitive parameters (e.g., scalars, vectors, tensors, ...),
dimensioned types, fields, Function1-s and Function2-s all support unit
conversion in this way.
Unit conversion occurs on input only. OpenFOAM writes out all fields and
parameters in standard units. It is recommended to use '.orig' files in
the 0 directory to preserve user-readable input if those files are being
modified by pre-processing applications (e.g., setFields).
For example, to specify a volumetric flow rate inlet boundary in litres
per second [l/s], rather than metres-cubed per second [m^3/s], in 0/U:
boundaryField
{
inlet
{
type flowRateInletVelocity;
volumetricFlowRate 0.1 [l/s];
value $internalField;
}
...
}
Or, to specify the pressure field in bar, in 0/p:
internalField uniform 1 [bar];
Or, to convert the parameters of an Arrhenius reaction rate from a
cm-mol-kcal unit system, in constant/chemistryProperties:
reactions
{
methaneReaction
{
type irreversibleArrhenius;
reaction "CH4^0.2 + 2O2^1.3 = CO2 + 2H2O";
A 6.7e12 [(mol/cm^3)^-0.5/s];
beta 0;
Ea 48.4 [kcal/mol];
}
}
Or, to define a time-varying outlet pressure using a CSV file in which
the pressure column is in mega-pascals [MPa], in 0/p:
boundaryField
{
outlet
{
type uniformFixedValue;
value
{
type table;
format csv;
nHeaderLine 1;
units ([s] [MPa]); // <-- new units entry
columns (0 1);
mergeSeparators no;
file "data/pressure.csv";
outOfBounds clamp;
interpolationScheme linear;
}
}
...
}
(Note also that a new 'columns' entry replaces the old 'refColumn' and
'componentColumns'. This is is considered to be more intuitive, and has
a consistent syntax with the new 'units' entry. 'columns' and
'componentColumns' have been retained for backwards compatibility and
will continue to work for the time being.)
Unit definitions can be added in the global or case controlDict files.
See UnitConversions in $WM_PROJECT_DIR/etc/controlDict for examples.
Currently available units include:
Standard: kg m s K kmol A Cd
Derived: Hz N Pa J W g um mm cm km l ml us ms min hr mol
rpm bar atm kPa MPa cal kcal cSt cP % rad rot deg
A user-time unit is also provided if user-time is in operation. This
allows it to be specified locally whether a parameter relates to
real-time or to user-time. For example, to define a mass source that
ramps up from a given engine-time (in crank-angle-degrees [CAD]) over a
duration in real-time, in constant/fvModels:
massSource1
{
type massSource;
points ((1 2 3));
massFlowRate
{
type scale;
scale linearRamp;
start 20 [CAD];
duration 50 [ms];
value 0.1 [g/s];
}
}
Specified units will be checked against the parameter's dimensions where
possible, and an error generated if they are not consistent. For the
dimensions to be available for this check, the code requires
modification, and work propagating this change across OpenFOAM is
ongoing. Unit conversions are still possible without these changes, but
the validity of such conversions will not be checked.
Units are no longer permitted in 'dimensions' entries in field files.
These 'dimensions' entries can now, instead, take the names of
dimensions. The names of the available dimensions are:
Standard: mass length time temperature
moles current luminousIntensity
Derived: area volume rate velocity momentum acceleration density
force energy power pressure kinematicPressure
compressibility gasConstant specificHeatCapacity
kinematicViscosity dynamicViscosity thermalConductivity
volumetricFlux massFlux
So, for example, a 0/epsilon file might specify the dimensions as
follows:
dimensions [energy/mass/time];
And a 0/alphat file might have:
dimensions [thermalConductivity/specificHeatCapacity];
*** Development Notes ***
A unit conversion can construct trivially from a dimension set,
resulting in a "standard" unit with a conversion factor of one. This
means the functions which perform unit conversion on read can be
provided dimension sets or unit conversion objects interchangeably.
A basic `dict.lookup<vector>("Umean")` call will do unit conversion, but
it does not know the parameter's dimensions, so it cannot check the
validity of the supplied units. A corresponding lookup function has been
added in which the dimensions or units can be provided; in this case the
corresponding call would be `dict.lookup<vector>("Umean", dimVelocity)`.
This function enables additional checking and should be used wherever
possible.
Function1-s and Function2-s have had their constructors and selectors
changed so that dimensions/units must be specified by calling code. In
the case of Function1, two unit arguments must be given; one for the
x-axis and one for the value-axis. For Function2-s, three must be
provided.
In some cases, it is desirable (or at least established practice), that
a given non-standard unit be used in the absence of specific
user-defined units. Commonly this includes reading angles in degrees
(rather than radians) and reading times in user-time (rather than
real-time). The primitive lookup functions and Function1 and Function2
selectors both support specifying a non-standard default unit. For
example, `theta_ = dict.lookup<scalar>("theta", unitDegrees)` will read
an angle in degrees by default. If this is done within a model which
also supports writing then the write call must be modified accordingly
so that the data is also written out in degrees. Overloads of writeEntry
have been created for this purpose. In this case, the angle theta should
be written out with `writeEntry(os, "theta", unitDegrees, theta_)`.
Function1-s and Function2-s behave similarly, but with greater numbers
of dimensions/units arguments as before.
The non-standard user-time unit can be accessed by a `userUnits()`
method that has been added to Time. Use of this user-time unit in the
construction of Function1-s should prevent the need for explicit
user-time conversion in boundary conditions and sub-models and similar.
Some models might contain non-typed stream-based lookups of the form
`dict.lookup("p0") >> p0_` (e.g., in a re-read method), or
`Umean_(dict.lookup("Umean"))` (e.g., in an initialiser list). These
calls cannot facilitate unit conversion and are therefore discouraged.
They should be replaced with
`p0_ = dict.lookup<scalar>("p0", dimPressure)` and
`Umean_(dict.lookup<vector>("Umean", dimVelocity))` and similar whenever
they are found.
|
|||
| ea5c2cb496 |
multiValveEngine: Removed the normalisation of the fractionalTravelInterval
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.
|
|||
| 8b67521d49 |
fvMeshMovers::multiValveEngine: Added support for pointZones frozen with respect specific moving object
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;
}
|
|||
| 6b96650436 |
kivaTest: Updated system/functions
Resolves bug-report https://bugs.openfoam.org/view.php?id=4053 |
|||
| 9753b67f30 |
multiValveEngineState: New functionObject to print and log the piston and valve motion
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. |
|||
| 7d65e66b86 |
multiValveEngine: New fvMeshMover for multi-valve IC engine mesh motion
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
|
|||
| 8331934c8c | tutorials: removed blank lines left over from transferring the functions entry to the functions file | |||
| a1eb8898d6 | tutorials: Moved the functions entry from controlDict into a functions file | |||
| ec8e9b6e6e |
tutorials/XiFluid/kivaTest: Reverted dynamicMeshDict
Resolves bug-report https://bugs.openfoam.org/view.php?id=4036 |
|||
| 836ce9a302 |
solutionControl: Added finalIteration function to replace the data class
The final iteration state is now available from the solutionControl class via the new finalIteration() static function, replacing the old data class from which fvMesh was derived. This approach is simpler, more reliable and easier to extend and reduces the clutter associated with fvMesh. |
|||
| 87ff44aeb8 | tutorials: Simplified dimensionless specification from [0 0 0 0 0 0 0] -> [] | |||
| 66188fac7a |
XiFluid, PDRFoam: Updated so that coefficients can be specified without dimensions
All associated combustion tutorials have been simplified using this functionality. |
|||
| a37b646e3d | tutorials: Fix cloneMesh paths and use foamRun instead of forwarding scripts | |||
| e744fdb5f1 |
Modular solvers: Reorganised directory structure of applications and tutorials
The new flexible and extensible modular solvers structure already provides most
of the simulation functionality needed for single phase, multiphase,
multicomponent etc. fluid flow problems as well as a very effective method of
combining these with solid heat transfer, solid stress, surface film to solve
complex multi-region, multi-physics problems and are now the primary mechanism
for the further development of OpenFOAM simulation capability in future. To
emphasis this for both users and developers the applications/solvers directory
has been separated into applications/modules containing all the solver modules:
├── modules
│ ├── compressibleMultiphaseVoF
│ ├── compressibleVoF
│ ├── film
│ ├── fluid
│ ├── fluidSolver
│ ├── functions
│ ├── incompressibleDenseParticleFluid
│ ├── incompressibleDriftFlux
│ ├── incompressibleFluid
│ ├── incompressibleMultiphaseVoF
│ ├── incompressibleVoF
│ ├── isothermalFilm
│ ├── isothermalFluid
│ ├── movingMesh
│ ├── multicomponentFluid
│ ├── multiphaseEuler
│ ├── multiphaseVoFSolver
│ ├── shockFluid
│ ├── solid
│ ├── solidDisplacement
│ ├── twoPhaseSolver
│ ├── twoPhaseVoFSolver
│ ├── VoFSolver
│ └── XiFluid
applications/solvers containing the foamRun and foamMultiRun solver applications
which instantiate and execute the chosen solver modules and also standalone
solver applications for special initialisation and test activities:
├── solvers
│ ├── boundaryFoam
│ ├── chemFoam
│ ├── foamMultiRun
│ ├── foamRun
│ └── potentialFoam
and applications/legacy containing legacy solver applications which are not
currently being actively developed but the functionality of which will be merged
into the solver modules or form the basis of new solver modules as the need
arises:
├── legacy
│ ├── basic
│ │ ├── financialFoam
│ │ └── laplacianFoam
│ ├── combustion
│ │ └── PDRFoam
│ ├── compressible
│ │ └── rhoPorousSimpleFoam
│ ├── electromagnetics
│ │ ├── electrostaticFoam
│ │ ├── magneticFoam
│ │ └── mhdFoam
│ ├── incompressible
│ │ ├── adjointShapeOptimisationFoam
│ │ ├── dnsFoam
│ │ ├── icoFoam
│ │ ├── porousSimpleFoam
│ │ └── shallowWaterFoam
│ └── lagrangian
│ ├── dsmcFoam
│ ├── mdEquilibrationFoam
│ └── mdFoam
Correspondingly the tutorials directory structure has been reorganised with the
modular solver directories at the top level with names that make it easier for
users to find example cases relating to their particular requirements and a
legacy sub-directory containing cases corresponding to the legacy solver
applications listed above:
├── compressibleMultiphaseVoF
│ └── damBreak4phaseLaminar
├── compressibleVoF
│ ├── ballValve
│ ├── climbingRod
│ ├── damBreak
│ ├── depthCharge2D
│ ├── depthCharge3D
│ ├── sloshingTank2D
│ └── throttle
├── film
│ └── rivuletPanel
├── fluid
│ ├── aerofoilNACA0012
│ ├── aerofoilNACA0012Steady
│ ├── angledDuct
│ ├── angledDuctExplicitFixedCoeff
│ ├── angledDuctLTS
│ ├── annularThermalMixer
│ ├── BernardCells
│ ├── blockedChannel
│ ├── buoyantCavity
│ ├── cavity
│ ├── decompressionTank
│ ├── externalCoupledCavity
│ ├── forwardStep
│ ├── helmholtzResonance
│ ├── hotRadiationRoom
│ ├── hotRadiationRoomFvDOM
│ ├── hotRoom
│ ├── hotRoomBoussinesq
│ ├── hotRoomBoussinesqSteady
│ ├── hotRoomComfort
│ ├── iglooWithFridges
│ ├── mixerVessel2DMRF
│ ├── nacaAirfoil
│ ├── pitzDaily
│ ├── prism
│ ├── shockTube
│ ├── squareBend
│ ├── squareBendLiq
│ └── squareBendLiqSteady
├── incompressibleDenseParticleFluid
│ ├── column
│ ├── cyclone
│ ├── Goldschmidt
│ ├── GoldschmidtMPPIC
│ └── injectionChannel
├── incompressibleDriftFlux
│ ├── dahl
│ ├── mixerVessel2DMRF
│ └── tank3D
├── incompressibleFluid
│ ├── airFoil2D
│ ├── ballValve
│ ├── blockedChannel
│ ├── cavity
│ ├── cavityCoupledU
│ ├── channel395
│ ├── drivaerFastback
│ ├── ductSecondaryFlow
│ ├── elipsekkLOmega
│ ├── flowWithOpenBoundary
│ ├── hopperParticles
│ ├── impeller
│ ├── mixerSRF
│ ├── mixerVessel2D
│ ├── mixerVessel2DMRF
│ ├── mixerVesselHorizontal2DParticles
│ ├── motorBike
│ ├── motorBikeSteady
│ ├── movingCone
│ ├── offsetCylinder
│ ├── oscillatingInlet
│ ├── pipeCyclic
│ ├── pitzDaily
│ ├── pitzDailyLES
│ ├── pitzDailyLESDevelopedInlet
│ ├── pitzDailyLTS
│ ├── pitzDailyPulse
│ ├── pitzDailyScalarTransport
│ ├── pitzDailySteady
│ ├── pitzDailySteadyExperimentalInlet
│ ├── pitzDailySteadyMappedToPart
│ ├── pitzDailySteadyMappedToRefined
│ ├── planarContraction
│ ├── planarCouette
│ ├── planarPoiseuille
│ ├── porousBlockage
│ ├── propeller
│ ├── roomResidenceTime
│ ├── rotor2DRotating
│ ├── rotor2DSRF
│ ├── rotorDisk
│ ├── T3A
│ ├── TJunction
│ ├── TJunctionFan
│ ├── turbineSiting
│ ├── waveSubSurface
│ ├── windAroundBuildings
│ └── wingMotion
├── incompressibleMultiphaseVoF
│ ├── damBreak4phase
│ ├── damBreak4phaseFineLaminar
│ ├── damBreak4phaseLaminar
│ └── mixerVessel2DMRF
├── incompressibleVoF
│ ├── angledDuct
│ ├── capillaryRise
│ ├── cavitatingBullet
│ ├── climbingRod
│ ├── containerDischarge2D
│ ├── damBreak
│ ├── damBreakLaminar
│ ├── damBreakPorousBaffle
│ ├── damBreakWithObstacle
│ ├── DTCHull
│ ├── DTCHullMoving
│ ├── DTCHullWave
│ ├── floatingObject
│ ├── floatingObjectWaves
│ ├── forcedUpstreamWave
│ ├── mixerVessel
│ ├── mixerVessel2DMRF
│ ├── mixerVesselHorizontal2D
│ ├── nozzleFlow2D
│ ├── planingHullW3
│ ├── propeller
│ ├── sloshingCylinder
│ ├── sloshingTank2D
│ ├── sloshingTank2D3DoF
│ ├── sloshingTank3D
│ ├── sloshingTank3D3DoF
│ ├── sloshingTank3D6DoF
│ ├── testTubeMixer
│ ├── waterChannel
│ ├── wave
│ ├── wave3D
│ └── weirOverflow
├── isothermalFilm
│ └── rivuletPanel
├── isothermalFluid
│ ├── potentialFreeSurfaceMovingOscillatingBox
│ └── potentialFreeSurfaceOscillatingBox
├── legacy
│ ├── basic
│ │ ├── financialFoam
│ │ │ └── europeanCall
│ │ └── laplacianFoam
│ │ └── flange
│ ├── combustion
│ │ └── PDRFoam
│ │ └── flamePropagationWithObstacles
│ ├── compressible
│ │ └── rhoPorousSimpleFoam
│ │ ├── angledDuctExplicit
│ │ └── angledDuctImplicit
│ ├── electromagnetics
│ │ ├── electrostaticFoam
│ │ │ └── chargedWire
│ │ └── mhdFoam
│ │ └── hartmann
│ ├── incompressible
│ │ ├── adjointShapeOptimisationFoam
│ │ │ └── pitzDaily
│ │ ├── dnsFoam
│ │ │ └── boxTurb16
│ │ ├── icoFoam
│ │ │ ├── cavity
│ │ │ └── elbow
│ │ ├── porousSimpleFoam
│ │ │ ├── angledDuctExplicit
│ │ │ └── angledDuctImplicit
│ │ └── shallowWaterFoam
│ │ └── squareBump
│ ├── lagrangian
│ │ ├── dsmcFoam
│ │ │ ├── freeSpacePeriodic
│ │ │ ├── freeSpaceStream
│ │ │ ├── supersonicCorner
│ │ │ └── wedge15Ma5
│ │ ├── mdEquilibrationFoam
│ │ │ ├── periodicCubeArgon
│ │ │ └── periodicCubeWater
│ │ └── mdFoam
│ │ └── nanoNozzle
├── mesh
│ ├── blockMesh
│ │ ├── pipe
│ │ ├── sphere
│ │ ├── sphere7
│ │ └── sphere7ProjectedEdges
│ ├── refineMesh
│ │ └── refineFieldDirs
│ └── snappyHexMesh
│ ├── flange
│ └── pipe
├── movingMesh
│ └── SnakeRiverCanyon
├── multicomponentFluid
│ ├── aachenBomb
│ ├── counterFlowFlame2D
│ ├── counterFlowFlame2D_GRI
│ ├── counterFlowFlame2D_GRI_TDAC
│ ├── counterFlowFlame2DLTS
│ ├── counterFlowFlame2DLTS_GRI_TDAC
│ ├── DLR_A_LTS
│ ├── filter
│ ├── lockExchange
│ ├── membrane
│ ├── nc7h16
│ ├── parcelInBox
│ ├── SandiaD_LTS
│ ├── simplifiedSiwek
│ ├── smallPoolFire2D
│ ├── smallPoolFire3D
│ ├── verticalChannel
│ ├── verticalChannelLTS
│ └── verticalChannelSteady
├── multiphaseEuler
│ ├── bed
│ ├── bubbleColumn
│ ├── bubbleColumnEvaporating
│ ├── bubbleColumnEvaporatingDissolving
│ ├── bubbleColumnEvaporatingReacting
│ ├── bubbleColumnIATE
│ ├── bubbleColumnLaminar
│ ├── bubbleColumnLES
│ ├── bubblePipe
│ ├── damBreak4phase
│ ├── fluidisedBed
│ ├── fluidisedBedLaminar
│ ├── Grossetete
│ ├── hydrofoil
│ ├── injection
│ ├── LBend
│ ├── mixerVessel2D
│ ├── mixerVessel2DMRF
│ ├── pipeBend
│ ├── steamInjection
│ ├── titaniaSynthesis
│ ├── titaniaSynthesisSurface
│ ├── wallBoilingIATE
│ ├── wallBoilingPolydisperse
│ └── wallBoilingPolydisperseTwoGroups
├── multiRegion
│ ├── CHT
│ │ ├── circuitBoardCooling
│ │ ├── coolingCylinder2D
│ │ ├── coolingSphere
│ │ ├── heatedDuct
│ │ ├── heatExchanger
│ │ ├── multiphaseCoolingCylinder2D
│ │ ├── reverseBurner
│ │ ├── shellAndTubeHeatExchanger
│ │ ├── VoFcoolingCylinder2D
│ │ └── wallBoiling
│ └── film
│ ├── cylinder
│ ├── cylinderDripping
│ ├── cylinderVoF
│ ├── hotBoxes
│ ├── rivuletBox
│ ├── rivuletPanel
│ ├── splashPanel
│ └── VoFToFilm
├── potentialFoam
│ ├── cylinder
│ └── pitzDaily
├── resources
│ ├── blockMesh
│ ├── geometry
│ └── thermoData
├── shockFluid
│ ├── biconic25-55Run35
│ ├── forwardStep
│ ├── LadenburgJet60psi
│ ├── movingCone
│ ├── obliqueShock
│ ├── shockTube
│ └── wedge15Ma5
├── solidDisplacement
│ ├── beamEndLoad
│ └── plateHole
└── XiFluid
├── kivaTest
└── moriyoshiHomogeneous
|
