b51aaf0464f7f4c0f7396d31a23c8a005134b92d
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 0d2fd78864 |
lagrangian: InjectionModel: New uniformParcelSize control
Lagrangian injections now have a 'uniformParcelSize' control, which specifies what size of the parcels is kept uniform during a given time step. This control can be set to 'nParticles', 'surfaceArea' or 'volume'. The particle sizes, by contrast, are specified by the size distribution. For example, if 'uniformParcelSize nParticles;' is specified then all parcels introduced at a given time will have the same number of particles. Every particle in a parcel has the same properties, including diameter. So, in this configuration, the larger diameter parcels contain a much larger fraction of the total particulate volume than the smaller diameter ones. This may be undesirable as the effect of a parcel on the simulation might be more in proportion with its volume than with the number of particles it represents. It might be preferable to create a greater proportion of large diameter parcels so that their more significant effect is represented by a finer Lagrangian discretisation. This can be achieved by setting 'uniformParcelSize volume;'. A setting of 'uniformParcelSize surfaceArea;' might be appropriate if the limiting effect of a Lagrangian element scales with its surface area; interfacial evaporation, for example. Previously, this control was provided by 'parcelBasisType'. However, this control also effectively specified the size exponent of the supplied distribution. This interdependence was not documented and was problematic in that it coupled physical and numerical controls. 'parcelBasisType' has been removed, and the size exponent of the distribution is now specified independently of the new 'uniformParcelSize' control along with the rest of the distribution coefficients or data. See the previous commit for details. It is still possible to specify a fixed number of particles per parcel using the 'nParticle' control. The presence of this control is used to determine whether or not the number of particles per parcel is fixed, so a 'fixed' basis type is no longer needed. A number of bugs have been fixed with regards to lack of interoperability between the various settings in the injection models. 'uniformParcelSize' can be changed freely and the number of parcels and amount of mass that an injector introduces will not change (this was not true of 'parcelBasisType'). Redundant settings are no longer read by the injection models; e.g., mass is not read if the number of particles per parcel is fixed, duration is not specified for steady tracking, etc... The 'inflationInjection' model has been removed as there are no examples of its usage, its purpose was not clearly documented, and it was not obvious how it should be updated as a result of these changes. |
|||
| 87a0b8a515 |
basicThermo: Renamed thermo:psi -> psi, thermo:mu -> mu and thermo:kappa -> kappa
The basic thermophysical properties are now considered fundamental and complex models like kineticTheoryModel using these names for some other purpose must disambiguate using typedName to prepend the model name to the field name. This change standardises, rationalises and simplifies the specification of fvSchemes and boundary conditions. thermo:rho will also be renamed rho in a subsequent commit to complete this rationalisation. |
|||
| 6cf099fd40 |
lagrangian: Mesh change hooks and usability improvements
The clouds fvModel and all the clouds it creates now contain a full set
of mesh change hooks. Some of these ultimately result in
"NotImplemented" errors, but this is an area under active development
and support may be added in the near future.
In addition, the list of cloud names is now specified from within the
fvModel, using a "clouds" entry. If this entry is omitted then a single
cloud named "cloud" is assumed as before. An example fvModel
specification for multiple clouds might be as follows:
clouds
{
type clouds;
libs ("liblagrangianParcel.so" "liblagrangianParcelTurbulence.so");
clouds (coalCloud limestoneCloud); // <-- New entry. Replaces
// the constant/clouds
// file.
}
Lagrangian solvers that construct clouds explicitly now do so via a new
"parcelClouds" mesh object. This ensures that they, too, are correctly
modified as a result of mesh changes.
Neither mechanism now permits no clouds. If there is not a "clouds"
entry (clouds fvModel), or a constant/clouds file (lagrangian solvers),
and there is not a constant/cloudProperties file for the default cloud,
then an error will be generated. Previously the code executed the solver
with no clouds. Intentional usage of the fvModel or lagrangian solvers
without clouds is considered highly unlikely.
|
|||
| 7fdde885fe |
fvCellSet: The selectionMode entry is now optional
Description
General cell set selection class for models that apply to sub-sets
of the mesh.
Currently supports cell selection from a set of points, a specified cellSet
or cellZone or all of the cells. The selection method can either be
specified explicitly using the \c selectionMode entry or inferred from the
presence of either a \c cellSet, \c cellZone or \c points entry. The \c
selectionMode entry is required to select \c all cells.
Usage
Examples:
\verbatim
// Apply everywhere
selectionMode all;
// Apply within a given cellSet
selectionMode cellSet; // Optional
cellSet rotor;
// Apply within a given cellZone
selectionMode cellZone; // Optional
cellSet rotor;
// Apply in cells containing a list of points
selectionMode points; // Optional
points
(
(2.25 0.5 0)
(2.75 0.5 0)
);
\endverbatim
All tutorials updated and simplified.
|
|||
| 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
|
