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. |
|||
| 295223624b |
Rationalised and standardised cell, face and point set selection controls
The keyword 'select' is now used to specify the cell, face or point set
selection method consistently across all classes requiring this functionality.
'select' replaces the inconsistently named 'regionType' and 'selectionMode'
keywords used previously but backwards-compatibility is provided for user
convenience. All configuration files and tutorials have been updated.
Examples of 'select' from the tutorial cases:
functionObjects:
cellZoneAverage
{
type volFieldValue;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
writeInterval 1;
fields (p);
select cellZone;
cellZone injection;
operation volAverage;
writeFields false;
}
#includeFunc populationBalanceSizeDistribution
(
name=numberDensity,
populationBalance=aggregates,
select=cellZone,
cellZone=outlet,
functionType=numberDensity,
coordinateType=projectedAreaDiameter,
allCoordinates=yes,
normalise=yes,
logTransform=yes
)
fvModel:
cylinderHeat
{
type heatSource;
select all;
q 5e7;
}
fvConstraint:
momentumForce
{
type meanVelocityForce;
select all;
Ubar (0.1335 0 0);
}
|
|||
| bc23162499 | tutorials: Remove unused combustionProperties files | |||
| 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. |
|||
| 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
|
