b36d8fca44936739d90a8f05371b35c7341b19f9
4 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 22d2b7be26 |
fvPatchField: Added support for optional libs entry
allowing libraries containing and supporting special boundary conditions to be loaded at run-time. |
|||
| 64455c60f5 |
tutorials/modules/CHT/shellAndTubeHeatExchanger: Load the libcoupledThermophysicalTransportModels library
to ensure the thermal coupled boundary conditions are loaded before the solid solver module. |
|||
| 8d229041dd |
mappedPatchBase: Separated into mapped and mappedInternal
The mappedPatchBase has been separated into a type which maps from
another patch (still called mappedPatchBase) and one that maps from
internal cell values (mappedInternalPatchBase). This prevents the user
needing to specify settings for mapping procedures that are not being
used, and potentially don't even make sense given the context in which
they are being applied. It also removes a lot of fragile logic and error
states in the mapping engine and its derivatives regarding the mode of
operation. Mapping from any face in the boundary is no longer supported.
Most region-coupling mapping patches are generated automatically by
utilities like splitMeshRegions and extrudeToRegionMesh. Cases which
create region-coupling mapped patches in this way will likely require no
modification.
Explicitly user-specified mapping will need modifying, however. For
example, where an inlet boundary is mapped to a downstream position in
order to evolve a developed profile. Or if a multi-region simulation is
constructed manually, without using one of the region-generating
utilities.
The available mapped patch types are now as follows:
- mapped: Maps values from one patch to another. Typically used for
inlets and outlets; to map values from an outlet patch to an inlet
patch in order to evolve a developed inlet profile, or to permit
flow between regions. Example specification in blockMesh:
inlet
{
type mapped;
neighbourRegion region0; // Optional. Defaults to the same
// region as the patch.
neighbourPatch outlet;
faces ( ... );
}
Note that any transformation between the patches is now determined
automatically. Alternatively, it can be explicitly specified using
the same syntax as for cyclic patches. The "offset" and "distance"
keywords are no longer used.
- mappedWall: As mapped, but treated as a wall for the purposes of
modelling (wall distance). No transformation. Typically used for
thermally coupling different regions. Usually created automatically
by meshing utilities. Example:
fluid_to_solid
{
type mappedWall;
neighbourRegion solid;
neighbourPatch solid_to_fluid;
method intersection; // The patchToPatch method. See
// below.
faces ( ... );
}
- mappedExtrudedWall: As mapped wall, but with corrections to account
for the thickness of an extruded mesh. Used for region coupling
involving film and thermal baffle models. Almost always generated
automatically by extrudeToRegionMesh (so no example given).
- mappedInternal: Map values from internal cells to a patch. Typically
used for inlets; to map values from internal cells to the inlet in
order to evolve a developed inlet profile. Example:
inlet
{
type mappedInternal;
distance 0.05; // Normal distance from the patch
// from which to map cell values
//offset (0.05 0 0); // Offset from the patch from
// which to map cell values
faces ( ... );
}
Note that an "offsetMode" entry is no longer necessary. The mode
will be inferred from the presence of the distance or offset
entries. If both are provided, then offsetMode will also be required
to choose which setting applies.
The mapped, mappedWall and mappedExtrudedWall patches now permit
specification of a "method". This selects a patchToPatch object and
therefore determines how values are transferred or interpolated between
the patches. Valid options are:
- nearest: Copy the value from the nearest face in the neighbouring
patch.
- matching: As nearest, but with checking to make sure that the
mapping is one-to-one. This is appropriate for patches that are
identically meshed.
- inverseDistance: Inverse distance weighting from a small stencil of
nearby faces in the neighbouring patch.
- intersection: Weighting based on the overlapping areas with faces in
the neighbouring patch. Equivalent to the previous AMI-based mapping
mode.
If a method is not specfied, then the pre-existing approach will apply.
This should be equivalent to the "nearest" method (though in most such
cases, "matching" is probably more appropriate). This fallback may be
removed in the future once the patchToPatch methods have been proven
robust.
The important mapped boundary conditions are now as follows:
- mappedValue: Maps values from one patch to another, and optionally
modify the mapped values to recover a specified average. Example:
inlet
{
type mappedValue;
field U; // Optional. Defaults to the same
// as this field.
average (10 0 0); // The presence of this entry now
// enables setting of the average,
// so "setAverage" is not needed
value uniform 0.1;
}
- mappedInternalValue: Map values from cells to a patch, and
optionally specify the average as in mappedValue. Example:
inlet
{
type mappedValue;
field k; // Optional. Defaults to the same
// as this field.
interpolationScheme cell;
value uniform 0.1;
}
- mappedFlowRateVelocity: Maps the flow rate from one patch to
another, and use this to set a patch-normal velocity. Example:
inlet
{
type mappedFlowRate;
value uniform (0 0 0);
}
Of these, mappedValue and mappedInternalValue can override the
underlying mapped patch's settings by additionally specifying mapping
information (i.e., the neighbourPatch, offset, etc... settings usually
supplied for the patch). This also means these boundary condtions can be
applied to non-mapped patches. This functionality used to be provided
with a separate "mappedField" boundary condition, which has been removed
as it is no longer necessary.
Other mapped boundary conditions are either extremely niche (e.g.,
mappedVelocityFlux), are always automatically generated (e.g.,
mappedValueAndPatchInternalValue), or their usage has not changed (e.g.,
compressible::turbulentTemperatureCoupledBaffleMixed and
compressible::turbulentTemperatureRadCoupledMixed). Use foamInfo to
obtain further details about these conditions.
|
|||
| 968e60148a |
New modular solver framework for single- and multi-region simulations
in which different solver modules can be selected in each region to for complex
conjugate heat-transfer and other combined physics problems such as FSI
(fluid-structure interaction).
For single-region simulations the solver module is selected, instantiated and
executed in the PIMPLE loop in the new foamRun application.
For multi-region simulations the set of solver modules, one for each region, are
selected, instantiated and executed in the multi-region PIMPLE loop of new the
foamMultiRun application.
This provides a very general, flexible and extensible framework for complex
coupled problems by creating more solver modules, either by converting existing
solver applications or creating new ones.
The current set of solver modules provided are:
isothermalFluid
Solver module for steady or transient turbulent flow of compressible
isothermal fluids with optional mesh motion and mesh topology changes.
Created from the rhoSimpleFoam, rhoPimpleFoam and buoyantFoam solvers but
without the energy equation, hence isothermal. The buoyant pressure
formulation corresponding to the buoyantFoam solver is selected
automatically by the presence of the p_rgh pressure field in the start-time
directory.
fluid
Solver module for steady or transient turbulent flow of compressible fluids
with heat-transfer for HVAC and similar applications, with optional
mesh motion and mesh topology changes.
Derived from the isothermalFluid solver module with the addition of the
energy equation from the rhoSimpleFoam, rhoPimpleFoam and buoyantFoam
solvers, thus providing the equivalent functionality of these three solvers.
multicomponentFluid
Solver module for steady or transient turbulent flow of compressible
reacting fluids with optional mesh motion and mesh topology changes.
Derived from the isothermalFluid solver module with the addition of
multicomponent thermophysical properties energy and specie mass-fraction
equations from the reactingFoam solver, thus providing the equivalent
functionality in reactingFoam and buoyantReactingFoam. Chemical reactions
and/or combustion modelling may be optionally selected to simulate reacting
systems including fires, explosions etc.
solid
Solver module for turbulent flow of compressible fluids for conjugate heat
transfer, HVAC and similar applications, with optional mesh motion and mesh
topology changes.
The solid solver module may be selected in solid regions of a CHT case, with
either the fluid or multicomponentFluid solver module in the fluid regions
and executed with foamMultiRun to provide functionality equivalent
chtMultiRegionFoam but in a flexible and extensible framework for future
extension to more complex coupled problems.
All the usual fvModels, fvConstraints, functionObjects etc. are available with
these solver modules to support simulations including body-forces, local sources,
Lagrangian clouds, liquid films etc. etc.
Converting compressibleInterFoam and multiphaseEulerFoam into solver modules
would provide a significant enhancement to the CHT capability and incompressible
solvers like pimpleFoam run in conjunction with solidDisplacementFoam in
foamMultiRun would be useful for a range of FSI problems. Many other
combinations of existing solvers converted into solver modules could prove
useful for a very wide range of complex combined physics simulations.
All tutorials from the rhoSimpleFoam, rhoPimpleFoam, buoyantFoam, reactingFoam,
buoyantReactingFoam and chtMultiRegionFoam solver applications replaced by
solver modules have been updated and moved into the tutorials/modules directory:
modules
├── CHT
│ ├── coolingCylinder2D
│ ├── coolingSphere
│ ├── heatedDuct
│ ├── heatExchanger
│ ├── reverseBurner
│ └── shellAndTubeHeatExchanger
├── fluid
│ ├── aerofoilNACA0012
│ ├── aerofoilNACA0012Steady
│ ├── angledDuct
│ ├── angledDuctExplicitFixedCoeff
│ ├── angledDuctLTS
│ ├── annularThermalMixer
│ ├── BernardCells
│ ├── blockedChannel
│ ├── buoyantCavity
│ ├── cavity
│ ├── circuitBoardCooling
│ ├── decompressionTank
│ ├── externalCoupledCavity
│ ├── forwardStep
│ ├── helmholtzResonance
│ ├── hotRadiationRoom
│ ├── hotRadiationRoomFvDOM
│ ├── hotRoom
│ ├── hotRoomBoussinesq
│ ├── hotRoomBoussinesqSteady
│ ├── hotRoomComfort
│ ├── iglooWithFridges
│ ├── mixerVessel2DMRF
│ ├── nacaAirfoil
│ ├── pitzDaily
│ ├── prism
│ ├── shockTube
│ ├── squareBend
│ ├── squareBendLiq
│ └── squareBendLiqSteady
└── multicomponentFluid
├── aachenBomb
├── counterFlowFlame2D
├── counterFlowFlame2D_GRI
├── counterFlowFlame2D_GRI_TDAC
├── counterFlowFlame2DLTS
├── counterFlowFlame2DLTS_GRI_TDAC
├── cylinder
├── DLR_A_LTS
├── filter
├── hotBoxes
├── membrane
├── parcelInBox
├── rivuletPanel
├── SandiaD_LTS
├── simplifiedSiwek
├── smallPoolFire2D
├── smallPoolFire3D
├── splashPanel
├── verticalChannel
├── verticalChannelLTS
└── verticalChannelSteady
Also redirection scripts are provided for the replaced solvers which call
foamRun -solver <solver module name> or foamMultiRun in the case of
chtMultiRegionFoam for backward-compatibility.
Documentation for foamRun and foamMultiRun:
Application
foamRun
Description
Loads and executes an OpenFOAM solver module either specified by the
optional \c solver entry in the \c controlDict or as a command-line
argument.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Usage
\b foamRun [OPTION]
- \par -solver <name>
Solver name
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries loaded
Example usage:
- To run a \c rhoPimpleFoam case by specifying the solver on the
command line:
\verbatim
foamRun -solver fluid
\endverbatim
- To update and run a \c rhoPimpleFoam case add the following entries to
the controlDict:
\verbatim
application foamRun;
solver fluid;
\endverbatim
then execute \c foamRun
Application
foamMultiRun
Description
Loads and executes an OpenFOAM solver modules for each region of a
multiregion simulation e.g. for conjugate heat transfer.
The region solvers are specified in the \c regionSolvers dictionary entry in
\c controlDict, containing a list of pairs of region and solver names,
e.g. for a two region case with one fluid region named
liquid and one solid region named tubeWall:
\verbatim
regionSolvers
{
liquid fluid;
tubeWall solid;
}
\endverbatim
The \c regionSolvers entry is a dictionary to support name substitutions to
simplify the specification of a single solver type for a set of
regions, e.g.
\verbatim
fluidSolver fluid;
solidSolver solid;
regionSolvers
{
tube1 $fluidSolver;
tubeWall1 solid;
tube2 $fluidSolver;
tubeWall2 solid;
tube3 $fluidSolver;
tubeWall3 solid;
}
\endverbatim
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Usage
\b foamMultiRun [OPTION]
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries loaded
Example usage:
- To update and run a \c chtMultiRegion case add the following entries to
the controlDict:
\verbatim
application foamMultiRun;
regionSolvers
{
fluid fluid;
solid solid;
}
\endverbatim
then execute \c foamMultiRun
|
