From c31a6924993fca6b23d4fcc6d617f9776762112f Mon Sep 17 00:00:00 2001 From: danielque Date: Wed, 18 Jul 2018 14:43:45 +0200 Subject: [PATCH] [DOC] formatting: limit line length --- doc/CFDEMcoupling_dicts.txt | 11 ++++-- doc/IOModel_basicIO.txt | 10 ++++- doc/IOModel_sophIO.txt | 5 ++- doc/IOModel_trackIO.txt | 5 ++- doc/averagingModel.txt | 3 +- doc/averagingModel_dense.txt | 5 ++- doc/averagingModel_dilute.txt | 12 ++++-- doc/cfdemSolverIB.txt | 37 +++++++++++++++---- doc/cfdemSolverPiso.txt | 10 ++++- doc/cfdemSolverPisoScalar.txt | 14 ++++++- doc/chemistryModel.txt | 6 ++- doc/chemistryModel_diffusionCoefficients.txt | 5 ++- doc/chemistryModel_massTransferCoeff.txt | 5 ++- doc/chemistryModel_species.txt | 6 ++- doc/clockModel.txt | 3 +- doc/clockModel_standardClock.txt | 31 ++++++++++++++-- doc/dataExchangeModel.txt | 3 +- doc/dataExchangeModel_noDataExchange.txt | 3 +- doc/dataExchangeModel_oneWayVTK.txt | 4 +- doc/dataExchangeModel_twoWayFiles.txt | 5 ++- doc/dataExchangeModel_twoWayMPI.txt | 5 ++- doc/dataExchangeModel_twoWayMany2Many.txt | 6 ++- doc/forceModel.txt | 6 ++- doc/forceModel_Archimedes.txt | 5 ++- doc/forceModel_ArchimedesIB.txt | 7 +++- doc/forceModel_DiFeliceDrag.txt | 5 ++- doc/forceModel_GidaspowDrag.txt | 7 +++- doc/forceModel_KochHillDrag.txt | 6 ++- doc/forceModel_LaEuScalarTemp.txt | 10 ++++- doc/forceModel_MeiLift.txt | 6 ++- doc/forceModel_SchillerNaumannDrag.txt | 5 ++- doc/forceModel_ShirgaonkarIB.txt | 8 +++- doc/forceModel_dSauter.txt | 3 +- doc/forceModel_fieldStore.txt | 4 +- doc/forceModel_gradPForce.txt | 6 ++- doc/forceModel_noDrag.txt | 7 +++- doc/forceModel_particleCellVolume.txt | 11 +++++- doc/forceModel_pdCorrelation.txt | 7 +++- doc/forceModel_virtualMassForce.txt | 4 +- doc/forceModel_viscForce.txt | 6 ++- doc/forceSubModel.txt | 8 +++- doc/forceSubModel_ImEx.txt | 5 ++- doc/forceSubModel_ImExCorr.txt | 4 +- doc/liggghtsCommandModel.txt | 3 +- doc/liggghtsCommandModel_execute.txt | 7 +++- doc/liggghtsCommandModel_runLiggghts.txt | 9 ++++- doc/liggghtsCommandModel_writeLiggghts.txt | 5 ++- doc/locateModel.txt | 4 +- doc/locateModel_engineSearch.txt | 6 ++- doc/locateModel_engineSearchIB.txt | 15 ++++++-- doc/locateModel_engineSearchMany2Many.txt | 3 +- doc/locateModel_standardSearch.txt | 3 +- doc/locateModel_turboEngineSearch.txt | 13 +++++-- doc/meshMotionModel.txt | 3 +- doc/momCoupleModel.txt | 35 +++++++++++++++--- doc/momCoupleModel_explicitCouple.txt | 3 +- doc/momCoupleModel_implicitCouple.txt | 3 +- doc/probeModel.txt | 6 ++- doc/regionModel.txt | 3 +- doc/smoothingModel.txt | 5 ++- doc/smoothingModel_constDiffSmoothing.txt | 11 +++++- doc/voidFractionModel.txt | 3 +- doc/voidFractionModel_GaussVoidFraction.txt | 12 ++++-- doc/voidFractionModel_IBVoidFraction.txt | 17 +++++++-- ...dFractionModel_bigParticleVoidFraction.txt | 14 +++++-- doc/voidFractionModel_centreVoidFraction.txt | 6 ++- doc/voidFractionModel_dividedVoidFraction.txt | 21 ++++++++--- 67 files changed, 426 insertions(+), 108 deletions(-) diff --git a/doc/CFDEMcoupling_dicts.txt b/doc/CFDEMcoupling_dicts.txt index 6dd87dac..a82faff0 100644 --- a/doc/CFDEMcoupling_dicts.txt +++ b/doc/CFDEMcoupling_dicts.txt @@ -60,9 +60,14 @@ exchanges. A useful procedure would be: -Set the DEM timestep in the in.xxx file according to the needs of the pure DEM problem. :olb,l -Set the "couplingInterval", which refers to the DEM timesteps. Depending on the problem you will need to have a close (small couplingInterval) or loose coupling. :l -Choose the CFD timestep in the controlDict. It must be equal to or smaller than the coupling time, otherwise you will get the error: "Error - TS bigger than coupling interval!". :l,ole +Set the DEM timestep in the LIGGGHTS input file according to the needs of the +pure DEM problem. :olb,l +Set the {couplingInterval}, which refers to the DEM timesteps. Depending on the +problem you will need to have a close (small couplingInterval) or loose +coupling. :l +Choose the CFD timestep in the controlDict. It must be equal to or smaller than +the coupling time, otherwise you will get the error: "Error - TS bigger than +coupling interval!". :l,ole Example: DEMts=0.00001s, couplingInterval=10 exchange data (=couple) will happen every 0.0001s. diff --git a/doc/IOModel_basicIO.txt b/doc/IOModel_basicIO.txt index d8e526f2..32115308 100644 --- a/doc/IOModel_basicIO.txt +++ b/doc/IOModel_basicIO.txt @@ -21,7 +21,15 @@ serialOutput; :pre [Description:] -The basic IO-model writes particle positions velocities and radii to files. The default output directory ($casePath/CFD/proc*/time/lagrangian). Using the keyword "serialOutput;" in couplingProperties the IO is serial to the directory ($casePath/CFD/lagrangian). In the latter case only the data on processor 0 is written! Data is written every write time of the CFD simulation. +The {basicIO} model writes particle positions, velocities and radii to files. +The default output directory is {$casePath/CFD/proc*/time/lagrangian}. + +Using the keyword {serialOutput;} in the +"couplingProperties"_CFDEMcoupling_dicts.html#couplingProperties dictionary, +the IO is serial to the directory {$casePath/CFD/lagrangian}. In this case +only the data on processor 0 is written! + +Data is written every write time of the CFD simulation. [Restrictions:] diff --git a/doc/IOModel_sophIO.txt b/doc/IOModel_sophIO.txt index 0db745d1..c193be2d 100644 --- a/doc/IOModel_sophIO.txt +++ b/doc/IOModel_sophIO.txt @@ -20,7 +20,10 @@ IOModel sophIO; :pre [Description:] -The sophIO-model is based on basicIO model and additionally writes voidfraction, implicit forces, explicit forces. Data is written every write time of the CFD simulation. +The {sophIO} model is based on the "basicIO"_IOModel_basicIO.html model and +additionally writes voidfraction, implicit forces and explicit forces. + +Data is written every write time of the CFD simulation. [Restrictions:] diff --git a/doc/IOModel_trackIO.txt b/doc/IOModel_trackIO.txt index 512c9c70..fcef4a94 100644 --- a/doc/IOModel_trackIO.txt +++ b/doc/IOModel_trackIO.txt @@ -20,7 +20,10 @@ IOModel trackIO; :pre [Description:] -The trackIO-model is based on sophIO model and additionally writes fields necessary to use the particleTracks utility (which needs a particleTrackProperties file in the constant dir). The particleTracks utility generates tracks of the particles and writes them to a vtk file. +The {trackIO} model is based on the "sophIO"_IOModel_sophIO.html model and +additionally writes fields necessary to use the particleTracks utility (which +needs a particleTrackProperties file in the constant dir). The particleTracks +utility generates tracks of the particles and writes them to a VTK file. [Restrictions:] diff --git a/doc/averagingModel.txt b/doc/averagingModel.txt index 8ee214c7..e474ac75 100644 --- a/doc/averagingModel.txt +++ b/doc/averagingModel.txt @@ -27,7 +27,8 @@ models in this documentation. [Description:] -The averaging model performs the Lagrangian->Eulerian mapping of data (e.g. particle velocities). +The averaging model performs the Lagrangian->Eulerian mapping of data (e.g. +particle velocities). [Restrictions:] diff --git a/doc/averagingModel_dense.txt b/doc/averagingModel_dense.txt index 5dcd41f8..f5c74160 100644 --- a/doc/averagingModel_dense.txt +++ b/doc/averagingModel_dense.txt @@ -20,7 +20,10 @@ averagingModel dense; :pre [Description:] -The averaging model performs the Lagrangian->Eulerian mapping of data (e.g. particle velocities). In the "cfdemParticle cloud" this averaging model is used to calculate the average particle velocity inside a CFD cell. The "dense" model is supposed to be applied to cases where the granular regime is rather dense. +The averaging model performs the Lagrangian->Eulerian mapping of data (e.g. +particle velocities). In the "cfdemParticle cloud" this averaging model is used +to calculate the average particle velocity inside a CFD cell. The {dense} model +is supposed to be applied to cases where the granular regime is rather dense. [Restrictions:] diff --git a/doc/averagingModel_dilute.txt b/doc/averagingModel_dilute.txt index 54dab770..47fa7dfe 100644 --- a/doc/averagingModel_dilute.txt +++ b/doc/averagingModel_dilute.txt @@ -20,12 +20,18 @@ averagingModel dilute; :pre [Description:] -The averaging model performs the Lagrangian->Eulerian mapping of data (e.g. particle velocities). -In the "cfdemParticle cloud" this averaging model is used to calculate the average particle velocity inside a CFD cell. The "dilute" model is supposed to be applied to cases where the granular regime is rather dilute. The particle velocity inside a CFD cell is evaluated from a single particle in a cell (no averaging). +The averaging model performs the Lagrangian->Eulerian mapping of data (e.g. +particle velocities). +In the "cfdemParticle cloud" this averaging model is used to calculate the +average particle velocity inside a CFD cell. The {dilute} model is supposed to +be applied to cases where the granular regime is rather dilute. The particle +velocity inside a CFD cell is evaluated from a single particle in a cell (no +averaging). [Restrictions:] -This model is computationally efficient, but should only be used when only one particle is inside one CFD cell. +This model is computationally efficient but should only be used when only one +particle is inside one CFD cell. [Related commands:] diff --git a/doc/cfdemSolverIB.txt b/doc/cfdemSolverIB.txt index 4af88842..89946232 100644 --- a/doc/cfdemSolverIB.txt +++ b/doc/cfdemSolverIB.txt @@ -9,8 +9,14 @@ cfdemSolverIB command :h3 [Description:] -"cfdemSolverIB" is a coupled CFD-DEM solver using CFDEMcoupling, an open source parallel coupled CFD-DEM framework, for calculating -the dynamics between immersed bodies and the surrounding fluid. Being an implementation of an immersed boundary method it allows tackling problems where the body diameter exceeds the maximal size of a fluid cell. Using the toolbox of OpenFOAM(R)(*) the governing equations of the fluid are computed and the corrections of velocity and pressure field with respect to the body-movement information, gained from LIGGGHTS, are incorporated. +"cfdemSolverIB" is a coupled CFD-DEM solver using CFDEMcoupling, an open source +parallel coupled CFD-DEM framework, for calculating the dynamics between +immersed bodies and the surrounding fluid. Being an implementation of an +immersed boundary method it allows tackling problems where the body diameter +exceeds the maximal size of a fluid cell. Using the toolbox of OpenFOAM(R)(*) +the governing equations of the fluid are computed and the corrections of +velocity and pressure field with respect to the body-movement information, +gained from LIGGGHTS, are incorporated. Code of this solver contributions by Alice Hager, JKU. @@ -18,17 +24,32 @@ Code of this solver contributions by Alice Hager, JKU. For each time step ... -the motion of the spheres is calculated (position, velocity, angular velocity, force...) with LIGGGHTS using the velocity and pressure-field from the previous time step (initial condition for t=0). :ulb,l -the Navier-Stokes equations are solved on the whole computational domain, disregarding the solid phase. :l -the spheres are located within the mesh: each sphere is represented by a cluster of cells, which are either totally or partially covered by the body, depending on its exact position. :l -the correction of the velocity and pressure field of the fluid phase takes place, using the information about the location of the spheres and their (angular) velocity. :l +the motion of the spheres is calculated (position, velocity, angular velocity, +force...) with LIGGGHTS using the velocity and pressure-field from the previous +time step (initial condition for t=0). :ulb,l +the Navier-Stokes equations are solved on the whole computational domain, +disregarding the solid phase. :l +the spheres are located within the mesh: each sphere is represented by a cluster +of cells, which are either totally or partially covered by the body, depending +on its exact position. :l +the correction of the velocity and pressure field of the fluid phase takes +place, using the information about the location of the spheres and their +(angular) velocity. :l :ule [Use:] -The solver is realized within the Open Source framework CFDEMcoupling. Just as for the unresolved CFD-DEM solver cfdemSolverPiso the file CFD/constant/couplingProperties contains information about the settings for the different models. While IOmodel, DataExchangeModel etc. are applicable for all CFDEMcoupling-solvers, special locate-, force- and void fraction models were designed for the present case: +The solver is realized within the Open Source framework CFDEMcoupling. Just as +for the unresolved CFD-DEM solver cfdemSolverPiso the file +CFD/constant/couplingProperties contains information about the settings for the +different models. While IOmodel, DataExchangeModel etc. are applicable for all +CFDEMcoupling-solvers, special locate-, force- and void fraction models were +designed for the present case: -"engineSearchIB"_locateModel_engineSearchIB.html, "ArchimedesIB"_forceModel_ArchimedesIB.html, "ShirgaonkarIB"_forceModel_ShirgaonkarIB.html, "IBVoidfraction"_voidFractionModel_IBVoidFraction.html +"engineSearchIB"_locateModel_engineSearchIB.html, +"ArchimedesIB"_forceModel_ArchimedesIB.html, +"ShirgaonkarIB"_forceModel_ShirgaonkarIB.html, +"IBVoidfraction"_voidFractionModel_IBVoidFraction.html [References:] diff --git a/doc/cfdemSolverPiso.txt b/doc/cfdemSolverPiso.txt index 4945c1a4..61c88fa3 100644 --- a/doc/cfdemSolverPiso.txt +++ b/doc/cfdemSolverPiso.txt @@ -9,7 +9,15 @@ cfdemSolverPiso command :h3 [Description:] -"cfdemSolverPiso" is a coupled CFD-DEM solver using CFDEMcoupling, an open source parallel coupled CFD-DEM framework. Based on pisoFoam(R)(*), a finite volume based solver for turbulent Navier-Stokes equations applying the PISO algorithm, "cfdemSolverPiso" has additional functionality for a coupling to the DEM code "LIGGGHTS". The volume averaged Navier-Stokes Equations are solved accounting for momentum exchange and volume displacement of discrete particles whose trajectories are calculated in the DEM code LIGGGHTS. +"cfdemSolverPiso" is a coupled CFD-DEM solver using CFDEMcoupling, an open +source parallel coupled CFD-DEM framework. Based on pisoFoam(R)(*), a finite +volume based solver for turbulent Navier-Stokes equations applying the PISO +algorithm, "cfdemSolverPiso" has additional functionality for a coupling to the +DEM code "LIGGGHTS". + +The volume averaged Navier-Stokes Equations are solved accounting for momentum +exchange and volume displacement of discrete particles whose trajectories are +calculated in the DEM code LIGGGHTS. see: diff --git a/doc/cfdemSolverPisoScalar.txt b/doc/cfdemSolverPisoScalar.txt index 5498f62d..5f24bf59 100644 --- a/doc/cfdemSolverPisoScalar.txt +++ b/doc/cfdemSolverPisoScalar.txt @@ -9,7 +9,19 @@ cfdemSolverPisoScalar command :h3 [Description:] -"cfdemSolverPisoScalar" is a coupled CFD-DEM solver using CFDEMcoupling, an open source parallel coupled CFD-DEM framework. Based on pisoFoam(R)(*), a finite volume based solver for turbulent Navier-Stokes equations applying PISO algorithm, "cfdemSolverPisoScalar" has additional functionality for a coupling to the DEM code "LIGGGHTS" as well as a scalar transport equation. The volume averaged Navier-Stokes Equations are solved accounting for momentum exchange and volume displacement of discrete particles, whose trajectories are calculated in the DEM code LIGGGHTS. The scalar transport equation is coupled to scalar properties of the particle phase, thus convective heat transfer in a fluid granular system can be modeled with "cfdemSolverPisoScalar". +"cfdemSolverPisoScalar" is a coupled CFD-DEM solver using CFDEMcoupling, an open +source parallel coupled CFD-DEM framework. Based on pisoFoam(R)(*), a finite +volume based solver for turbulent Navier-Stokes equations applying PISO +algorithm, "cfdemSolverPisoScalar" has additional functionality for a coupling +to the DEM code "LIGGGHTS" as well as a scalar transport equation. + +The volume averaged Navier-Stokes Equations are solved accounting for momentum +exchange and volume displacement of discrete particles, whose trajectories are +calculated in the DEM code LIGGGHTS. + +The scalar transport equation is coupled to scalar properties of the particle +phase, thus convective heat transfer in a fluid granular system can be modeled +with "cfdemSolverPisoScalar". see: diff --git a/doc/chemistryModel.txt b/doc/chemistryModel.txt index 0220ada8..4ba06f9b 100644 --- a/doc/chemistryModel.txt +++ b/doc/chemistryModel.txt @@ -31,7 +31,11 @@ chemistryModels [Description:] -The chemistry model initializes the required fields for the calculation of molar fractions, determines the diffusion coefficients of the gaseous reactants, calculates the necessary coefficients for the calculation of a mass transfer coefficient. All models are executed sequentially. These values are used in the DEM calculation of particle reduction models. +The chemistry model initializes the required fields for the calculation of molar +fractions, determines the diffusion coefficients of the gaseous reactants, +calculates the necessary coefficients for the calculation of a mass transfer +coefficient. All models are executed sequentially. These values are used in the +DEM calculation of particle reduction models. [Restrictions:] diff --git a/doc/chemistryModel_diffusionCoefficients.txt b/doc/chemistryModel_diffusionCoefficients.txt index 3c665bb8..788d0020 100644 --- a/doc/chemistryModel_diffusionCoefficients.txt +++ b/doc/chemistryModel_diffusionCoefficients.txt @@ -45,7 +45,10 @@ diffusionCoefficientsProps [Description:] -The chemistry model performs the calculation of chemical reactional effects acting on each DEM particle. The diffusionCoefficients model activates the binary molecular diffusion calculation of the reacting species using the Fuller-Schettler-Giddings correlation. +The chemistry model performs the calculation of chemical reactional effects +acting on each DEM particle. The diffusionCoefficients model activates the +binary molecular diffusion calculation of the reacting species using the +Fuller-Schettler-Giddings correlation. [Restrictions:] diff --git a/doc/chemistryModel_massTransferCoeff.txt b/doc/chemistryModel_massTransferCoeff.txt index 96f1c54b..39573ac4 100644 --- a/doc/chemistryModel_massTransferCoeff.txt +++ b/doc/chemistryModel_massTransferCoeff.txt @@ -37,7 +37,10 @@ massTransferCoeffProps [Description:] -The chemistry model performs the calculation of chemical reactional effects acting on each DEM particle. The coeffs needed to calculate the mass transfer coefficients are transferred to the DEM side, where it is used in the fix_chem_shrink_core module. +The chemistry model performs the calculation of chemical reactional effects +acting on each DEM particle. The coefficients needed to calculate the mass +transfer coefficients are transferred to the DEM side, where it is used in the +{fix chem/shrink/core} module. [Restrictions:] diff --git a/doc/chemistryModel_species.txt b/doc/chemistryModel_species.txt index c7c81ef3..3748f430 100644 --- a/doc/chemistryModel_species.txt +++ b/doc/chemistryModel_species.txt @@ -52,7 +52,11 @@ speciesProps [Description:] -The chemistry model performs the calculation of chemical reactional effects acting on each DEM particle. The species model is the model, where the specified species fields (from the foam.inp folder) are intialized, and information such as temperature, density, molar concentration and more importantly the molar fractions are transferred to DEM side. +The chemistry model performs the calculation of chemical reactional effects +acting on each DEM particle. The species model is the model, where the specified +species fields (from the foam.inp folder) are intialized, and information such +as temperature, density, molar concentration and more importantly the molar +fractions are transferred to DEM side. [Restrictions:] diff --git a/doc/clockModel.txt b/doc/clockModel.txt index 2dd916b4..3b77afb0 100644 --- a/doc/clockModel.txt +++ b/doc/clockModel.txt @@ -25,7 +25,8 @@ models in this documentation. [Description:] -The clockModel is the base class for models to examine the code/algorithm with respect to run time. +The clockModel is the base class for models to examine the code/algorithm with +respect to run time. Main parts of the clockModel classes are written by Josef Kerbl, JKU. diff --git a/doc/clockModel_standardClock.txt b/doc/clockModel_standardClock.txt index e7e2012b..596eba70 100644 --- a/doc/clockModel_standardClock.txt +++ b/doc/clockModel_standardClock.txt @@ -20,9 +20,34 @@ clockModel standardClock; :pre [Description:] -The "standardClock" model is a basic clockModel model which measures the run time between every ".start(int arrayPos,string name)" and ".stop(string name)" statement placed in the code. If a ".start(name)" is called more than once (e.g. in a loop) the accumulated times are calculated. After the simulation has finished, the data is stored in $caseDir/CFD/clockData/$startTime/*.txt . -Since the measurements are stored in an array, it is necessary to put a variable {arrayPos} (type integer) at the start command. Those do not need to be in ascending order and positions may be omitted. The standard size of this array is 30 and can be changed at the initialization of the standardClock class. If {arrayPos} is out of bounds, the array size will be doubled. The stop command does not need {arrayPos}, since the class remembers the positions. The string name is intended for easier evaluation afterwards an may be omitted like ".start(int arrayPos)" and ".stop()". The command ".stop(string name)" is a safety feature, because if the name is not equal to the started name, output will be produced for information. -After the case ran you may use the matPlot.py script located in $CFDEM_UT_DIR/vizClock/ to produce a graphical output of your measurements. The usage is like 'python < matPlot.py' and you have to be in the directory of the desired time step, where there is a file called "timeEvalFull.txt", which contains averaged and maximum data with respect to the number of processes. There is an alias called "vizClock" to run this python routine for visualizing the data. +The {standardClock} model is a basic clock model which measures the run time +between every ".start(int arrayPos,string name)" and ".stop(string name)" +statement placed in the code. If a ".start(name)" is called more than once +(e.g. in a loop) the accumulated times are calculated. + +After the simulation has finished, the data is stored in +$caseDir/CFD/clockData/$startTime/*.txt. + +Since the measurements are stored in an array, it is necessary to put a variable +{arrayPos} (type integer) at the start command. Those do not need to be in +ascending order and positions may be omitted. The standard size of this array is +30 and can be changed at the initialization of the standardClock class. If +{arrayPos} is out of bounds, the array size will be doubled. The stop command +does not need {arrayPos}, since the class remembers the positions. The string +name is intended for easier evaluation afterwards an may be omitted like +".start(int arrayPos)" and ".stop()". The command ".stop(string name)" is a +safety feature, because if the name is not equal to the started name, output +will be produced for information. + +After the case ran you may use the matPlot.py script located in +$CFDEM_UT_DIR/vizClock/ to produce a graphical output of your measurements. The +usage is like + +python < matPlot.py :pre +and you have to be in the directory of the desired time step, where there is a +file called "timeEvalFull.txt", which contains averaged and maximum data with +respect to the number of processes. There is an alias called "vizClock" to run +this python routine for visualizing the data. [Restrictions:] diff --git a/doc/dataExchangeModel.txt b/doc/dataExchangeModel.txt index 16f104fb..ee054d2f 100644 --- a/doc/dataExchangeModel.txt +++ b/doc/dataExchangeModel.txt @@ -26,7 +26,8 @@ NOTE: This examples list might not be complete - please look for other models [Description:] -The data exchange model performs the data exchange between the DEM code and the CFD code. +The data exchange model performs the data exchange between the DEM code and the +CFD code. [Restrictions:] diff --git a/doc/dataExchangeModel_noDataExchange.txt b/doc/dataExchangeModel_noDataExchange.txt index 56f15adf..676907c8 100644 --- a/doc/dataExchangeModel_noDataExchange.txt +++ b/doc/dataExchangeModel_noDataExchange.txt @@ -20,7 +20,8 @@ dataExchangeModel noDataExchange; :pre [Description:] -The data exchange model performs the data exchange between the DEM code and the CFD code. The noDataExchange model is a dummy model where no data is exchanged. +The data exchange model performs the data exchange between the DEM code and the +CFD code. The {noDataExchange} model is a dummy model where no data is exchanged. [Restrictions:] diff --git a/doc/dataExchangeModel_oneWayVTK.txt b/doc/dataExchangeModel_oneWayVTK.txt index 7a06474a..f565f0da 100644 --- a/doc/dataExchangeModel_oneWayVTK.txt +++ b/doc/dataExchangeModel_oneWayVTK.txt @@ -40,7 +40,9 @@ oneWayVTKProps [Description:] -The data exchange model performs the data exchange between the DEM code and the CFD code. The oneWayVTK model is a model that can exchange particle properties from DEM to CFD based on previously stored VTK data. +The data exchange model performs the data exchange between the DEM code and the +CFD code. The {oneWayVTK} model is a model that can exchange particle properties +from DEM to CFD based on previously stored VTK data. [Restrictions:] diff --git a/doc/dataExchangeModel_twoWayFiles.txt b/doc/dataExchangeModel_twoWayFiles.txt index 7bc53f37..9561b12d 100644 --- a/doc/dataExchangeModel_twoWayFiles.txt +++ b/doc/dataExchangeModel_twoWayFiles.txt @@ -34,7 +34,10 @@ twoWayFilesProps [Description:] -The data exchange model performs the data exchange between the DEM code and the CFD code. The twoWayFiles model is a model that can exchange particle properties from DEM to CFD and from CFD to DEM. Data is exchanged via files that are sequentially written/read by the codes. +The data exchange model performs the data exchange between the DEM code and the +CFD code. The {twoWayFiles} model is a model that can exchange particle +properties from DEM to CFD and from CFD to DEM. Data is exchanged via files that +are sequentially written/read by the codes. [Restrictions:] diff --git a/doc/dataExchangeModel_twoWayMPI.txt b/doc/dataExchangeModel_twoWayMPI.txt index aafdb5cc..5410ef1e 100644 --- a/doc/dataExchangeModel_twoWayMPI.txt +++ b/doc/dataExchangeModel_twoWayMPI.txt @@ -31,7 +31,10 @@ twoWayMPIProps [Description:] -The data exchange model performs the data exchange between the DEM code and the CFD code. The twoWayMPI model is a model that can exchange particle properties from DEM to CFD and from CFD to DEM. Data is exchanged via MPI technique. The DEM run is executed by the coupling model, via a liggghtsCommandModel object. +The data exchange model performs the data exchange between the DEM code and the +CFD code. The {twoWayMPI} model is a model that can exchange particle properties +from DEM to CFD and from CFD to DEM. Data is exchanged via MPI technique. The +DEM run is executed by the coupling model, via a {liggghtsCommandModel} object. [Restrictions:] diff --git a/doc/dataExchangeModel_twoWayMany2Many.txt b/doc/dataExchangeModel_twoWayMany2Many.txt index 155121c5..0cf4e372 100644 --- a/doc/dataExchangeModel_twoWayMany2Many.txt +++ b/doc/dataExchangeModel_twoWayMany2Many.txt @@ -31,7 +31,11 @@ twoWayMany2ManyProps [Description:] -The data exchange model performs the data exchange between the DEM code and the CFD code. The twoWayMany2Many model is a model that can exchange particle properties from DEM to CFD and from CFD to DEM. Data is exchanged via MPI technique using the many to many mapping scheme. The DEM run is executed by the coupling model, via a liggghtsCommandModel object. +The data exchange model performs the data exchange between the DEM code and the +CFD code. The {twoWayMany2Many} model is a model that can exchange particle +properties from DEM to CFD and from CFD to DEM. Data is exchanged via MPI +technique using the many to many mapping scheme. The DEM run is executed by the +coupling model, via a {liggghtsCommandModel} object. [Restrictions:] diff --git a/doc/forceModel.txt b/doc/forceModel.txt index fba0981a..4f8edeba 100644 --- a/doc/forceModel.txt +++ b/doc/forceModel.txt @@ -33,7 +33,11 @@ NOTE: This examples list might not be complete - please look for other models [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. All force models selected are executed sequentially and the forces on the particles are superposed. If the fluid density field is needed, by default a field named "rho" will be used. Via the forceSubModel an alternative field can be chosen. +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. All force models selected are +executed sequentially and the forces on the particles are superposed. If the +fluid density field is needed, by default a field named "rho" will be used. Via +the forceSubModel an alternative field can be chosen. [Restrictions:] diff --git a/doc/forceModel_Archimedes.txt b/doc/forceModel_Archimedes.txt index 8ffa8b2b..f45b886e 100644 --- a/doc/forceModel_Archimedes.txt +++ b/doc/forceModel_Archimedes.txt @@ -37,7 +37,10 @@ ArchimedesProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The Archimedes model is a model that calculates the Archimedes' volumetric lift force stemming from density difference of fluid and particle. +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {Archimedes} model is a +model that calculates the Archimedes' volumetric lift force stemming from +density difference of fluid and particle. [Restrictions:] diff --git a/doc/forceModel_ArchimedesIB.txt b/doc/forceModel_ArchimedesIB.txt index a72477e6..77a965aa 100644 --- a/doc/forceModel_ArchimedesIB.txt +++ b/doc/forceModel_ArchimedesIB.txt @@ -40,7 +40,12 @@ ArchimedesIBProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The ArchimedesIB model is a model that calculates the ArchimedesIB' volumetric lift force stemming from density difference of fluid and particle. This model is especially suited for resolved CFD-DEM simulations where the particle is represented by immersed boundary method. +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {ArchimedesIB} model is a +model that calculates the ArchimedesIB' volumetric lift force stemming from +density difference of fluid and particle. This model is especially suited for +resolved CFD-DEM simulations where the particle is represented by immersed +boundary method. [Restrictions:] diff --git a/doc/forceModel_DiFeliceDrag.txt b/doc/forceModel_DiFeliceDrag.txt index 2e863955..49198afc 100644 --- a/doc/forceModel_DiFeliceDrag.txt +++ b/doc/forceModel_DiFeliceDrag.txt @@ -40,7 +40,10 @@ DiFeliceDragProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The DiFeliceDrag model is a model that calculates the particle based drag force following the correlation of Di Felice (see Zhou et al. (2010), JFM). +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {DiFeliceDrag} model is a +model that calculates the particle based drag force following the correlation of +Di Felice (see Zhou et al. (2010), JFM). [Restrictions:] diff --git a/doc/forceModel_GidaspowDrag.txt b/doc/forceModel_GidaspowDrag.txt index d4841b6f..99118936 100644 --- a/doc/forceModel_GidaspowDrag.txt +++ b/doc/forceModel_GidaspowDrag.txt @@ -49,7 +49,12 @@ GidaspowDragProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The GidaspowDrag model is a model that calculates the particle based drag force following the correlation of Gidaspow which is a combination of Ergun (1952) and Wen & Yu (1966) (see Zhu et al. (2007): "Discrete particle simulation of particulate systems: Theoretical developments", ChemEngScience). +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {GidaspowDrag} model is a +model that calculates the particle based drag force following the correlation of +Gidaspow which is a combination of Ergun (1952) and Wen & Yu (1966) +(see Zhu et al. (2007): "Discrete particle simulation of particulate systems: +Theoretical developments", ChemEngScience). [Restrictions:] diff --git a/doc/forceModel_KochHillDrag.txt b/doc/forceModel_KochHillDrag.txt index f31a23f6..674bcc2d 100644 --- a/doc/forceModel_KochHillDrag.txt +++ b/doc/forceModel_KochHillDrag.txt @@ -44,7 +44,11 @@ KochHillDragProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The KochHillDrag model is a model that calculates the particle based drag force following the correlation of Koch & Hill (2001) (see van Buijtenen et al. (2011): "Numerical and experimental study on multiple-spout fluidized beds", ChemEngScience). +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {KochHillDrag} model is a +model that calculates the particle based drag force following the correlation of +Koch & Hill (2001) (see van Buijtenen et al. (2011): "Numerical and experimental +study on multiple-spout fluidized beds", ChemEngScience). [Restrictions:] diff --git a/doc/forceModel_LaEuScalarTemp.txt b/doc/forceModel_LaEuScalarTemp.txt index 89cbf2cc..2fe0f77e 100644 --- a/doc/forceModel_LaEuScalarTemp.txt +++ b/doc/forceModel_LaEuScalarTemp.txt @@ -59,11 +59,17 @@ LaEuScalarTempProps [Description:] -This "forceModel" does not influence the particles or the fluid flow! Using the particles' temperature a scalar field representing "particle-fluid heatflux" is calculated. The solver then uses this source field in the scalar transport equation for the temperature. The model for convective heat transfer is based on Li and Mason (2000), A computational investigation of transient heat transfer in pneumatic transport of granular particles, Pow.Tech 112 +This "force model" does not influence the particles or the fluid flow! Using the +particles' temperature a scalar field representing "particle-fluid heatflux" is +calculated. The solver then uses this source field in the scalar transport +equation for the temperature. The model for convective heat transfer is based on +Li and Mason (2000), A computational investigation of transient heat transfer in +pneumatic transport of granular particles, Pow.Tech 112 [Restrictions:] -Goes only with cfdemSolverScalar. The force model has to be the second (!!!) model in the forces list. +Goes only with cfdemSolverScalar. The force model has to be the second (!!!) +model in the forces list. [Related commands:] diff --git a/doc/forceModel_MeiLift.txt b/doc/forceModel_MeiLift.txt index 2d5703e3..4e7e9c52 100644 --- a/doc/forceModel_MeiLift.txt +++ b/doc/forceModel_MeiLift.txt @@ -46,7 +46,11 @@ MeiLiftProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The MeiLift model calculates the lift force for each particle based on Loth and Dorgan (2009). In case the keyword "useSecondOrderTerms" is not specified, this lift force model uses the expression of McLaughlin (1991, Journal of Fluid Mechanics 224:261-274). +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {MeiLift} model calculates +the lift force for each particle based on Loth and Dorgan (2009). In case the +keyword "useSecondOrderTerms" is not specified, this lift force model uses the +expression of McLaughlin (1991, J. Fluid Mech. 224:261-274). [Restrictions:] diff --git a/doc/forceModel_SchillerNaumannDrag.txt b/doc/forceModel_SchillerNaumannDrag.txt index 532ab2d1..75f41fcf 100644 --- a/doc/forceModel_SchillerNaumannDrag.txt +++ b/doc/forceModel_SchillerNaumannDrag.txt @@ -37,7 +37,10 @@ SchillerNaumannDragProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The SchillerNaumannDrag model is a model that calculates the particle based drag force following the correlation of Schiller and Naumann. +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {SchillerNaumannDrag} model +is a model that calculates the particle based drag force following the +correlation of Schiller and Naumann. [Restrictions:] diff --git a/doc/forceModel_ShirgaonkarIB.txt b/doc/forceModel_ShirgaonkarIB.txt index 42ddcb7b..a20b71bc 100644 --- a/doc/forceModel_ShirgaonkarIB.txt +++ b/doc/forceModel_ShirgaonkarIB.txt @@ -40,7 +40,13 @@ ShirgaonkarIBProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The ShirgaonkarIB model calculates the drag force (viscous and pressure force) acting on each particle in a resolved manner (see Shirgaonkar et al. (2009): "A new mathematical formulation and fast algorithm for fully resolved simulation of self-propulsion", Journal of Comp. Physics). This model is only suited for resolved CFD-DEM simulations where the particle is represented by immersed boundary method. +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {ShirgaonkarIB} model +calculates the drag force (viscous and pressure force) acting on each particle +in a resolved manner (see Shirgaonkar et al. (2009): "A new mathematical +formulation and fast algorithm for fully resolved simulation of self-propulsion", +J. Comp. Phys). This model is only suited for resolved CFD-DEM simulations where +the particle is represented by immersed boundary method. [References:] diff --git a/doc/forceModel_dSauter.txt b/doc/forceModel_dSauter.txt index bc9790e7..298d0eb7 100644 --- a/doc/forceModel_dSauter.txt +++ b/doc/forceModel_dSauter.txt @@ -30,7 +30,8 @@ whitespace, optional :ulb,l [Description:] -This "forceModel" does not influence the particles or the flow - it calculates the Sauter diameter +This "force model" does not influence the particles or the flow - it calculates +the Sauter diameter :c,image(Eqs/d32.png) . diff --git a/doc/forceModel_fieldStore.txt b/doc/forceModel_fieldStore.txt index 6d8c6068..2e8e01e8 100644 --- a/doc/forceModel_fieldStore.txt +++ b/doc/forceModel_fieldStore.txt @@ -52,7 +52,9 @@ fieldStoreProps [Description:] -This "forceModel" does not influence the particles or the flow - it is a tool to store a scalar/vector field! This is especially useful if you use a boundary condition which cannot interpreted correctly in your postporcessor (e.g. paraview). +This "force model" does not influence the particles or the flow - it is a tool +to store a scalar/vector field! This is especially useful if you use a boundary +condition which cannot interpreted correctly in your postporcessor (e.g. paraview). [Restrictions:] diff --git a/doc/forceModel_gradPForce.txt b/doc/forceModel_gradPForce.txt index c16f4895..a2fd162e 100644 --- a/doc/forceModel_gradPForce.txt +++ b/doc/forceModel_gradPForce.txt @@ -43,7 +43,11 @@ gradPForceProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The gradPForce model is a model that calculates the particle based pressure gradient force -(grad(p)) * Vparticle (see Zhou et al. (2010): "Discrete particle simulation of particle-fluid flow: model formulations and their applicability" ,JFM). +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {gradPForce} model is a +model that calculates the particle based pressure gradient force -(grad(p)) * +Vparticle (see Zhou et al. (2010): "Discrete particle simulation of +particle-fluid flow: model formulations and their applicability", J. Fluid Mech.). [Restrictions:] diff --git a/doc/forceModel_noDrag.txt b/doc/forceModel_noDrag.txt index 1ad4dffd..e122ef27 100644 --- a/doc/forceModel_noDrag.txt +++ b/doc/forceModel_noDrag.txt @@ -37,7 +37,12 @@ noDragProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The noDrag model sets the forces acting on the particle to zero. If several force models are selected and noDrag is the last model being executed, the fluid particle force will be set to zero. If the variable noDEMForce is set, then the forces communicated to the DEM solver are also set to zero. +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {noDrag} model sets the +forces acting on the particle to zero. If several force models are selected and +noDrag is the last model being executed, the fluid particle force will be set to +zero. If the variable {noDEMForce} is set, then the forces communicated to the +DEM solver are also set to zero. [Restrictions:] diff --git a/doc/forceModel_particleCellVolume.txt b/doc/forceModel_particleCellVolume.txt index 956df32d..ed5e396e 100644 --- a/doc/forceModel_particleCellVolume.txt +++ b/doc/forceModel_particleCellVolume.txt @@ -42,8 +42,15 @@ particleCellVolumeProps [Description:] -This "forceModel" does not influence the particles or the simulation - it is a postprocessing tool! The total volume of the particles as they are represented on the CFD mesh is calculated. Further the total volume of the cells particles are in is calculated. -At "writeTime" a field named particleCellVolume , where scalarField is the name of the original field, is written. This can then be probed using standard function object probes. Analogously a field named cellVolume is written. Using the verbose option a screen output is given. +This "force model" does not influence the particles or the simulation - it is a +postprocessing tool! The total volume of the particles as they are represented +on the CFD mesh is calculated. Further the total volume of the cells particles +are in is calculated. + +At "writeTime" a field named particleCellVolume, where scalarField is the name +of the original field, is written. This can then be probed using standard +function object probes. Analogously a field named cellVolume is written. Using +the {verbose} option a screen output is given. [Restrictions:] diff --git a/doc/forceModel_pdCorrelation.txt b/doc/forceModel_pdCorrelation.txt index da3832d9..dbc8ea45 100644 --- a/doc/forceModel_pdCorrelation.txt +++ b/doc/forceModel_pdCorrelation.txt @@ -38,12 +38,15 @@ pdCorrelationProps [Description:] -This "forceModel" does not influence the particles or the flow - it calculates the particle momentum-diameter correlation +This "forceModel" does not influence the particles or the flow - it calculates +the particle momentum-diameter correlation :c,image(Eqs/pdCorrelation.png) where delta is the type-specific coarsegraining factor. -This model is sensitive to additionally pulled particle type info, and can either use the type-specific densities from the dict or those pulled from LIGGGHTS. +This model is sensitive to additionally pulled particle type info, and can +either use the type-specific densities from the dictionary or those pulled from +LIGGGHTS. [Restrictions:] diff --git a/doc/forceModel_virtualMassForce.txt b/doc/forceModel_virtualMassForce.txt index 41f56b88..d0556c7e 100644 --- a/doc/forceModel_virtualMassForce.txt +++ b/doc/forceModel_virtualMassForce.txt @@ -37,7 +37,9 @@ virtualMassForceProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The virtualMassForce model calculates the virtual mass force for each particle. +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {virtualMassForce} model +calculates the virtual mass force for each particle. IMPORTANT NOTE: Model not validated! diff --git a/doc/forceModel_viscForce.txt b/doc/forceModel_viscForce.txt index 9e17ecbb..04d7ba49 100644 --- a/doc/forceModel_viscForce.txt +++ b/doc/forceModel_viscForce.txt @@ -39,7 +39,11 @@ viscForceProps [Description:] -The force model performs the calculation of forces (e.g. fluid-particle interaction forces) acting on each DEM particle. The viscForce model calculates the particle based viscous force, -(grad(tau)) * Vparticle (see Zhou et al. (2010): "Discrete particle simulation of particle-fluid flow: model formulations and their applicability", JFM). +The force model performs the calculation of forces (e.g. fluid-particle +interaction forces) acting on each DEM particle. The {viscForce} model +calculates the particle based viscous force, -(grad(tau)) * Vparticle +(see Zhou et al. (2010): "Discrete particle simulation of particle-fluid flow: +model formulations and their applicability", J. Fluid Mech.). [Restrictions:] diff --git a/doc/forceSubModel.txt b/doc/forceSubModel.txt index 2831e355..b4b0f824 100644 --- a/doc/forceSubModel.txt +++ b/doc/forceSubModel.txt @@ -9,7 +9,10 @@ forceSubModel command :h3 [Syntax:] -Defined in couplingProperties sub-dictionary of the force model in use. If no force sub-model is applied ImEx is used as default. If the keyword "forceSubModels" is provided, a choice of sub model is demanded. +Defined in "couplingProperties"_CFDEMcoupling_dicts.html#couplingProperties +sub-dictionary of the force model in use. If no force sub-model is applied, ImEx +is used as default. If the keyword "forceSubModels" is provided, a choice of +sub-model is demanded. forceSubModels ( @@ -31,7 +34,8 @@ NOTE: This examples list might not be complete - please look for other models [Description:] -The force sub model is designed to hold the settings a force model can have. For now it handles the treatExplicit, treatDEM and implDEM option. +The force sub model is designed to hold the settings a force model can have. +For now it handles the treatExplicit, treatDEM and implDEM option. [Restrictions:] diff --git a/doc/forceSubModel_ImEx.txt b/doc/forceSubModel_ImEx.txt index 60e02aea..68ccc9d0 100644 --- a/doc/forceSubModel_ImEx.txt +++ b/doc/forceSubModel_ImEx.txt @@ -31,7 +31,10 @@ treatExplicit true; // optional for some force models. :pre [Description:] - If no force sub-model is applied ImEx is used as default. If the keyword "forceSubModels" is provided, a choice of sub model is demanded. Depending on the force model different keywords are read and can therefrore be set (see the log file). If the keyword is provided, its value is used. +If no force sub-model is applied {ImEx} is used as default. If the keyword +"forceSubModels" is provided, a choice of sub model is demanded. Depending on +the force model different keywords are read and can therefrore be set +(see the log file). If the keyword is provided, its value is used. [Restrictions:] diff --git a/doc/forceSubModel_ImExCorr.txt b/doc/forceSubModel_ImExCorr.txt index 9fd3f583..85f6645c 100644 --- a/doc/forceSubModel_ImExCorr.txt +++ b/doc/forceSubModel_ImExCorr.txt @@ -31,7 +31,9 @@ treatExplicit true; // optional for some force models. :pre [Description:] - Same as ImEx, but it additionally reads "explicitInterpCorr" to correct the error steming from interpolation of Ufluid and averaging of Uparticles. +Same as "ImEx"_forceSubModel_ImEx.html, but it additionally reads +"explicitInterpCorr" to correct the error steming from interpolation of Ufluid +and averaging of Uparticles. [Restrictions:] diff --git a/doc/liggghtsCommandModel.txt b/doc/liggghtsCommandModel.txt index 5b6063ec..958eefed 100644 --- a/doc/liggghtsCommandModel.txt +++ b/doc/liggghtsCommandModel.txt @@ -33,7 +33,8 @@ NOTE: This examples list might not be complete - please look for other models [Description:] -The liggghtsCommandModel is the base class to execute DEM commands within a CFD run. +The liggghtsCommandModel is the base class to execute DEM commands within a CFD +run. [Restrictions:] diff --git a/doc/liggghtsCommandModel_execute.txt b/doc/liggghtsCommandModel_execute.txt index d4e77392..e008f7a9 100644 --- a/doc/liggghtsCommandModel_execute.txt +++ b/doc/liggghtsCommandModel_execute.txt @@ -77,7 +77,12 @@ executeProps1 [Description:] -The execute liggghtsCommand Model can be used to execute a LIGGGHTS command during a CFD run. In above example execute_0 for instance executes "run $couplingInterval" every coupling step. $couplingInterval is automatically replaced by the correct number of DEM steps. Additionally execute_1 executes "write_restart ../DEM/liggghts.restart_$timeStamp" every writing step, where $timeStamp is automatically set. +The {execute} liggghtsCommand Model can be used to execute a LIGGGHTS command +during a CFD run. In above example {execute_0} for instance executes +"run $couplingInterval" every coupling step. {$couplingInterval} is automatically +replaced by the correct number of DEM steps. Additionally, {execute_1} executes +"write_restart ../DEM/liggghts.restart_$timeStamp" every writing step, where +{$timeStamp} is automatically set. NOTE: These rather complex execute commands can be replaced by the {runLiggghts} and {writeLiggghts} commands! diff --git a/doc/liggghtsCommandModel_runLiggghts.txt b/doc/liggghtsCommandModel_runLiggghts.txt index fb1694d6..a69c2e1a 100644 --- a/doc/liggghtsCommandModel_runLiggghts.txt +++ b/doc/liggghtsCommandModel_runLiggghts.txt @@ -32,7 +32,14 @@ liggghtsCommandModels [Description:] -The liggghtsCommand models can be used to execute a LIGGGHTS command during a CFD run. The "runLiggghts" command executes the command "run $nrDEMsteps", where $nrDEMsteps is automatically set according to the coupling intervals, every coupling step. Optionally a dictionary called runLiggghtsProps can be specified where the "preNo" switch can be set, which uses the command "run $nrDEMsteps pre no" for every time step except the first. +The liggghtsCommand models can be used to execute a LIGGGHTS command during a +CFD run. The {runLiggghts} command executes the command "run $nrDEMsteps", where +$nrDEMsteps is automatically set according to the coupling intervals, every +coupling step. + +Optionally a dictionary called runLiggghtsProps can be specified where the +"preNo" switch can be set, which uses the command "run $nrDEMsteps pre no" for +every time step except the first. [Restrictions:] diff --git a/doc/liggghtsCommandModel_writeLiggghts.txt b/doc/liggghtsCommandModel_writeLiggghts.txt index ec6a7319..f3f2f05b 100644 --- a/doc/liggghtsCommandModel_writeLiggghts.txt +++ b/doc/liggghtsCommandModel_writeLiggghts.txt @@ -41,7 +41,10 @@ liggghtsCommandModels [Description:] -The liggghtsCommand models can be used to execute a LIGGGHTS command during a CFD write. The "writeLiggghts" command executes the command "write_restart $name", where $name is the name of the restart file, every write step. +The liggghtsCommand models can be used to execute a LIGGGHTS command during a +CFD write. The {writeLiggghts} command executes the command +"write_restart $name" - where $name is the name of the restart file - every +write step. [Restrictions:] diff --git a/doc/locateModel.txt b/doc/locateModel.txt index 4edfa459..ca02400b 100644 --- a/doc/locateModel.txt +++ b/doc/locateModel.txt @@ -25,7 +25,9 @@ NOTE: This examples list might not be complete - please look for other models [Description:] -The locateModel is the base class for models which search for the CFD cell and cellID corresponding to a position. In general it is used to find the cell a particle is located in. +The locateModel is the base class for models which search for the CFD cell and +cellID corresponding to a position. In general it is used to find the cell a +particle is located in. [Restrictions:] diff --git a/doc/locateModel_engineSearch.txt b/doc/locateModel_engineSearch.txt index 206ba1a8..7c13f1e8 100644 --- a/doc/locateModel_engineSearch.txt +++ b/doc/locateModel_engineSearch.txt @@ -31,8 +31,10 @@ engineProps [Description:] -The locateModel "engine" locates the CFD cell and cellID corresponding to a given position. -The engineSearch locate Model can be used with different settings to use different algorithms: +The locateModel {engine} locates the CFD cell and cellID corresponding to a +given position. +The {engine} locate Model can be used with different settings to use different +algorithms: treeSearch false; will execute some geometric (linear) search using the last known cellID :ulb,l treeSearch true; will use a recursive tree structure to find the cell (recommended). :l diff --git a/doc/locateModel_engineSearchIB.txt b/doc/locateModel_engineSearchIB.txt index c426e576..b8736d25 100644 --- a/doc/locateModel_engineSearchIB.txt +++ b/doc/locateModel_engineSearchIB.txt @@ -43,15 +43,24 @@ engineIBProps [Description:] -The locateModel "engine" locates the CFD cell and cellID corresponding to a given position. This locate model is especially designed for parallel immersed boundary method. Each particle is represented by "satellite points" if it is distributed over several processors. +The locateModel {engineIB} locates the CFD cell and cellID corresponding to a +given position. This locate model is especially designed for parallel immersed +boundary method. Each particle is represented by "satellite points" if it is +distributed over several processors. -The engineSearchIB locate Model can be used with different settings to use different algorithms: +The {engineIB} locate Model can be used with different settings to use different +algorithms: treeSearch false; will execute some geometric (linear) search using the last known cellID (recommended) :ulb,l treeSearch true; will use a recursive tree structure to find the cell. :l :ule -This model is a modification of the engine search model. Instead of using the centre-cell as starting point for the engine search, further satellite points located on the surface of the sphere are checked. This ensures that (parts of) spheres can be located even when their centre is on another processor. This is especially important for parallel computations, when a sphere is about to move from one processor to another. +This model is a modification of the {engine} search model. Instead of using the +centre-cell as starting point for the engine search, further satellite points +located on the surface of the sphere are checked. This ensures that (parts of) +spheres can be located even when their centre is on another processor. This is +especially important for parallel computations, when a sphere is about to move +from one processor to another. [Restrictions:] diff --git a/doc/locateModel_engineSearchMany2Many.txt b/doc/locateModel_engineSearchMany2Many.txt index 4456656c..d1abe119 100644 --- a/doc/locateModel_engineSearchMany2Many.txt +++ b/doc/locateModel_engineSearchMany2Many.txt @@ -37,7 +37,8 @@ engineSearchMany2ManyProps [Description:] -The locateModel "engine" locates the CFD cell and cellID corresponding to a given position. This model is a dummy for the "twoWayMany2Many" dataExchangeModel which locates using the specified "engine" during coupling. Using this model with any other dataExchangeModel will cause problems. +The locateModel "engine" locates the CFD cell and cellID corresponding to a +given position. The engineSearchMany2Many locateModel can be used with different settings to use different algorithms: diff --git a/doc/locateModel_standardSearch.txt b/doc/locateModel_standardSearch.txt index aa705bc2..3afd6324 100644 --- a/doc/locateModel_standardSearch.txt +++ b/doc/locateModel_standardSearch.txt @@ -20,7 +20,8 @@ locateModel standard; :pre [Description:] -The locateModel "standard" locates the CFD cell and cellID corresponding to a given position. A very straight-forward (robust!) locate algorithm is used. +The locateModel {standard} locates the CFD cell and cellID corresponding to a +given position. A very straight-forward (robust!) locate algorithm is used. [Restrictions:] diff --git a/doc/locateModel_turboEngineSearch.txt b/doc/locateModel_turboEngineSearch.txt index c7b4dfad..73836d85 100644 --- a/doc/locateModel_turboEngineSearch.txt +++ b/doc/locateModel_turboEngineSearch.txt @@ -31,12 +31,17 @@ turboEngineProps [Description:] -The locateModel "turboEngine" locates the CFD cell and cellID corresponding to a given position. The algorithm is improved compared to engine search to show better parallel performance. +The locateModel {turboEngine} locates the CFD cell and cellID corresponding to a +given position. The algorithm is improved compared to engine search to show +better parallel performance. -The turboEngineSearch locate Model can be used with different settings to use different algorithms: +The turboEngineSearch locate Model can be used with different settings to use +different algorithms: -faceDecomp false; treeSearch false; will execute some geometric (linear) search using the last known cellID :ulb,l -faceDecomp false; treeSearch true; will use a recursive tree structure to find the cell. (recommended):l +faceDecomp false; treeSearch false; will execute some geometric (linear) search +using the last known cellID :ulb,l +faceDecomp false; treeSearch true; will use a recursive tree structure to find +the cell. (recommended) :l :ule [Restrictions:] diff --git a/doc/meshMotionModel.txt b/doc/meshMotionModel.txt index c2b672fe..569870d6 100644 --- a/doc/meshMotionModel.txt +++ b/doc/meshMotionModel.txt @@ -25,7 +25,8 @@ NOTE: This examples list might not be complete - please look for other models [Description:] -The meshMotionModel is the base class for models which manipulate the CFD mesh according to the DEM mesh motion. +The {meshMotionModel} is the base class for models which manipulate the CFD mesh +according to the DEM mesh motion. [Restrictions:] diff --git a/doc/momCoupleModel.txt b/doc/momCoupleModel.txt index 9789c286..a8ff48da 100644 --- a/doc/momCoupleModel.txt +++ b/doc/momCoupleModel.txt @@ -29,14 +29,37 @@ momCoupleModels NOTE: This examples list might not be complete - please look for other models (momCoupleModel XY) in this documentation. -Forces can be coupled in an implicit way to the fluid solver (i.e., when solving the Navier-Stokes equations, the fluid velocity at the new time will be considered for the coupling force). This implicit coupling is typically done for the drag forces (look for "impForces()" in the implementation of the drag model). Implicit coupling is more stable (especially important for dense flows), but conflicts Newton's third law. Explicit forces are imposed on the flow solver in an explicit fashion (look for "expForces()" in the implementation of the drag model), which is less stable, but does not conflict Newton's third law. - -Note that the variable "imExSplitFactor" can be set in the couplingProperties in order to treat implicitly defined forces (in the implementation of the force model) as explicit ones. "imExSplitFactor 1.0;" is set by default, meaning that all implicit forces will be considered implicitly, whereas "imExSplitFactor 0.0;" would mean that implicitly defined forces will be treated in an explicit fashion. - -Note that the switch "treatVoidCellsAsExplicitForce true;" can be set in the couplingProperties in order to change the treatment of cells which are void of particles. This is only relevant if (i) smoothing is used, and (ii) implicit force coupling is performed. By default, the particle veloctiy field (Us) will be smoothed to obtain a meaningful reference quantity for the implicit force coupling. In case "treatVoidCellsAsExplicitForce true;" is set, however, Us will not be smoothed and implicit forces (after the smoothing has been performed) in cells void of particles be treated as explicit ones. This avoids the problem of defining Us in cells that are void of particles, but for which an implicit coupling force is obtained in the smoothing process. [Description:] -The momCoupleModel is the base class for momentum exchange between DEM and CFD simulation. +Forces can be coupled in an implicit way to the fluid solver (i.e., when solving +the Navier-Stokes equations, the fluid velocity at the new time will be +considered for the coupling force). This implicit coupling is typically done for +the drag forces (look for "impForces()" in the implementation of the drag model). +Implicit coupling is more stable (especially important for dense flows), but +conflicts Newton's third law. Explicit forces are imposed on the flow solver in +an explicit fashion (look for "expForces()" in the implementation of the drag +model), which is less stable, but does not conflict Newton's third law. + +Note that the variable {imExSplitFactor} can be set in the couplingProperties in +order to treat implicitly defined forces (in the implementation of the force +model) as explicit ones. {imExSplitFactor 1.0;} is set by default, meaning that +all implicit forces will be considered implicitly, whereas +{imExSplitFactor 0.0;} would mean that implicitly defined forces will be treated +in an explicit fashion. + +Note that the switch {treatVoidCellsAsExplicitForce true;} can be set in the +couplingProperties in order to change the treatment of cells which are void of +particles. This is only relevant if (i) smoothing is used, and (ii) implicit +force coupling is performed. By default, the particle veloctiy field (Us) will +be smoothed to obtain a meaningful reference quantity for the implicit force +coupling. In case {treatVoidCellsAsExplicitForce true;} is set, however, Us will +not be smoothed and implicit forces (after the smoothing has been performed) in +cells void of particles be treated as explicit ones. This avoids the problem of +defining Us in cells that are void of particles, but for which an implicit +coupling force is obtained in the smoothing process. + +The {momCoupleModel} is the base class for momentum exchange between DEM and CFD +simulation. [Restrictions:] diff --git a/doc/momCoupleModel_explicitCouple.txt b/doc/momCoupleModel_explicitCouple.txt index 05491988..4a3fe422 100644 --- a/doc/momCoupleModel_explicitCouple.txt +++ b/doc/momCoupleModel_explicitCouple.txt @@ -37,7 +37,8 @@ explicitCoupleProps [Description:] -The explicitCouple-model is a momCoupleModel model providing an explicit momentum source term for the CFD solver. +The {explicitCouple} model is a momCoupleModel model providing an explicit +momentum source term for the CFD solver. [Restrictions:] diff --git a/doc/momCoupleModel_implicitCouple.txt b/doc/momCoupleModel_implicitCouple.txt index 4e2bd997..ea4573e5 100644 --- a/doc/momCoupleModel_implicitCouple.txt +++ b/doc/momCoupleModel_implicitCouple.txt @@ -45,7 +45,8 @@ implicitCoupleProps [Description:] -The implicitCouple-model is a momCoupleModel model providing an implicit momentum source term for the CFD solver. +The {implicitCouple} model is a momCoupleModel model providing an implicit +momentum source term for the CFD solver. [Restrictions:] diff --git a/doc/probeModel.txt b/doc/probeModel.txt index e9ce503e..75882da1 100644 --- a/doc/probeModel.txt +++ b/doc/probeModel.txt @@ -28,7 +28,11 @@ of probe models that can perform particle probing. [Description:] -The probeModel feature allows to implement various probing features in CFDEM. Currently, only the "particleProbe"_probeModel_particleProbe.html model is implemented, that performs probing of particle forces. +The {probeModel} feature allows to implement various probing features in CFDEM. +Currently, only the "particleProbe"_probeModel_particleProbe.html model is +implemented, that performs probing of particle forces. + +Use probe model {off} to disable this feature. [Restrictions:] diff --git a/doc/regionModel.txt b/doc/regionModel.txt index b1a1204c..880d09f3 100644 --- a/doc/regionModel.txt +++ b/doc/regionModel.txt @@ -27,7 +27,8 @@ NOTE: This examples list might not be complete - please look for other models [Description:] -The regionModel is the base class for region models to select a certain region for coupled simulation. +The {regionModel} is the base class for region models to select a certain region +for coupled simulation. [Restrictions:] diff --git a/doc/smoothingModel.txt b/doc/smoothingModel.txt index dfe1f6a0..4714c017 100644 --- a/doc/smoothingModel.txt +++ b/doc/smoothingModel.txt @@ -32,7 +32,10 @@ an error. [Description:] -The smoothingModel is the base class for models that smoothen the exchange fields (i.e., voidfraction and the Ksl field in case of implicit force coupling). This is relevant in case one uses a small grid resolution compared to the local particle diameter (or parcel diameter in case one uses a parcel approach). +The {smoothingModel} is the base class for models that smoothen the exchange +fields (i.e., voidfraction and the Ksl field in case of implicit force coupling). +This is relevant in case one uses a small grid resolution compared to the local +particle diameter (or parcel diameter in case one uses a parcel approach). [Restrictions:] diff --git a/doc/smoothingModel_constDiffSmoothing.txt b/doc/smoothingModel_constDiffSmoothing.txt index 9abad593..c6d83f2e 100644 --- a/doc/smoothingModel_constDiffSmoothing.txt +++ b/doc/smoothingModel_constDiffSmoothing.txt @@ -39,8 +39,15 @@ constDiffSmoothingProps [Description:] -The "constDiffSmoothing" model is a basic smoothingModel model which reads a smoothing length scale being used for smoothing the exchange fields (voidfraction, Ksl, f if present). This model can be used for smoothing explicit force coupling fields, as well as implicit force coupling algorithms. -Smoothing for reference fields is performed to "fill in" values in cells in which these reference fields are not specified. Values calculated in the cells (via Lagrangian-To-Euler mapping) are NOT changed! These reference fields are, e.g., the average particle velocity, which are not specified in all cells in case the flow is rather dilute. +The {constDiffSmoothing} model is a basic smoothingModel model which reads a +smoothing length scale being used for smoothing the exchange fields +(voidfraction, Ksl, f if present). This model can be used for smoothing explicit +force coupling fields, as well as implicit force coupling algorithms. +Smoothing for reference fields is performed to "fill in" values in cells in +which these reference fields are not specified. Values calculated in the cells +(via Lagrangian-To-Euler mapping) are NOT changed! These reference fields are, +e.g. the average particle velocity, which are not specified in all cells in case +the flow is rather dilute. [Restrictions:] diff --git a/doc/voidFractionModel.txt b/doc/voidFractionModel.txt index 06d0af5b..b7975131 100644 --- a/doc/voidFractionModel.txt +++ b/doc/voidFractionModel.txt @@ -25,7 +25,8 @@ NOTE: This examples list might not be complete - please look for other models [Description:] -The voidfractionModel is the base class for models to represent the DEM particle's volume in the CFD domain via a voidfraction field. +The {voidfractionModel} is the base class for models to represent the DEM +particle's volume in the CFD domain via a void fraction field. [Restrictions:] diff --git a/doc/voidFractionModel_GaussVoidFraction.txt b/doc/voidFractionModel_GaussVoidFraction.txt index 44dc9af7..f382bd06 100644 --- a/doc/voidFractionModel_GaussVoidFraction.txt +++ b/doc/voidFractionModel_GaussVoidFraction.txt @@ -40,11 +40,17 @@ GaussProps [Description:] -The Gauss voidFraction model is supposed to be used when a particle (or its representation) is bigger than a CFD cell. The voidfraction field is set in those cell whose centres are inside the particle. The volume is here distributed according to a Gaussian distribution. +The {Gauss} voidFraction model is supposed to be used when a particle (or its +representation) is bigger than a CFD cell. The voidfraction field is set in +those cell whose centres are inside the particle. The volume is here distributed +according to a Gaussian distribution. -The region of influence of a particle can be increased artificially by "porosity", which blows up the particles, but keeps their volume (for voidfraction calculation) constant. +The region of influence of a particle can be increased artificially by +"porosity", which blows up the particles, but keeps their volume (for +voidfraction calculation) constant. -The particle volume occupied in the CFD domain can be adjusted by the parameter "weight", using Vparticle=dsphere^3*pi/6*weight. +The particle volume occupied in the CFD domain can be adjusted by the parameter +"weight", using Vparticle=dsphere^3*pi/6*weight. [Restrictions:] diff --git a/doc/voidFractionModel_IBVoidFraction.txt b/doc/voidFractionModel_IBVoidFraction.txt index b8ed6fda..d732488a 100644 --- a/doc/voidFractionModel_IBVoidFraction.txt +++ b/doc/voidFractionModel_IBVoidFraction.txt @@ -20,9 +20,11 @@ IBProps scaleUpVol number3; \} :pre -{number1} = maximum number of cells covered by a particle (search will fail when more than {number1} cells are covered by the particle) :ulb,l +{number1} = maximum number of cells covered by a particle (search will fail when +more than {number1} cells are covered by the particle) :ulb,l {number2} = minimum limit for voidfraction :l -{number3} = diameter of the particle's representation is artificially increased according to {number3} * Vparticle, volume remains unaltered! :l +{number3} = diameter of the particle's representation is artificially increased +according to {number3} * Vparticle, volume remains unaltered! :l :ule [Examples:] @@ -37,9 +39,16 @@ IBProps [Description:] -The IB voidFraction model is supposed to be used when a particle (or its representation) is bigger than a CFD cell. The voidfraction field is set in those cell whose centres are inside the particle. The model is specially designed for cfdemSolverIB and creates a smooth transition of the voidfraction at the particle surface. Cells which are only partially covered by solid are marked by voidfraction values between 0 and 1 respectively. +The {IB} voidFraction model is supposed to be used when a particle (or its +representation) is bigger than a CFD cell. The voidfraction field is set in +those cell whose centres are inside the particle. The model is specially +designed for cfdemSolverIB and creates a smooth transition of the voidfraction +at the particle surface. Cells which are only partially covered by solid are +marked by voidfraction values between 0 and 1 respectively. -The region of influence of a particle can be increased artificially by "scaleUpVol", which blows up the particles, but keeps their volume (for voidfraction calculation) constant. +The region of influence of a particle can be increased artificially by +"scaleUpVol", which blows up the particles, but keeps their volume (for +voidfraction calculation) constant. Code of this sub-model contributed by Alice Hager, JKU. diff --git a/doc/voidFractionModel_bigParticleVoidFraction.txt b/doc/voidFractionModel_bigParticleVoidFraction.txt index 8eefc44d..37e5490b 100644 --- a/doc/voidFractionModel_bigParticleVoidFraction.txt +++ b/doc/voidFractionModel_bigParticleVoidFraction.txt @@ -40,11 +40,19 @@ bigParticleProps [Description:] -The bigParticle voidFraction model is supposed to be used when a particle (or its representation) is bigger than a CFD cell. The voidfraction field is set in those cell whose centres are inside the particle which results in a stairstep representation of the bodies within the mesh (i.e. voidfraction is either 1 (fluid) of zero (solid)). For archiving accurate results, approx. 8 cells per particle diameter are necessary. +The {bigParticle} voidFraction model is supposed to be used when a particle (or +its representation) is bigger than a CFD cell. The voidfraction field is set in +those cell whose centres are inside the particle which results in a stairstep +representation of the bodies within the mesh (i.e. voidfraction is either 1 +(fluid) of zero (solid)). For archiving accurate results, approx. 8 cells per +particle diameter are necessary. -The region of influence of a particle can be increased artificially by "porosity", which blows up the particles, but keeps their volume (for voidfraction calculation) constant. +The region of influence of a particle can be increased artificially by +"porosity", which blows up the particles, but keeps their volume (for +voidfraction calculation) constant. -The particle volume occupied in the CFD domain can be adjusted by the parameter "weight", using Vparticle=dsphere^3*pi/6*weight. +The particle volume occupied in the CFD domain can be adjusted by the parameter +"weight", using Vparticle=dsphere^3*pi/6*weight. Parts of this sub-model contributed by Alice Hager, JKU. diff --git a/doc/voidFractionModel_centreVoidFraction.txt b/doc/voidFractionModel_centreVoidFraction.txt index c2be19fb..e33ce64d 100644 --- a/doc/voidFractionModel_centreVoidFraction.txt +++ b/doc/voidFractionModel_centreVoidFraction.txt @@ -34,9 +34,11 @@ centreProps [Description:] -The centre voidFraction model calculates the voidfraction in a CFD cell accounting for the volume of the particles whose centres are inside the cell. +The {centre} voidFraction model calculates the voidfraction in a CFD cell +accounting for the volume of the particles whose centres are inside the cell. -The particle volume occupied in the CFD domain can be adjusted by the parameter "weight", using Vparticle=dsphere^3*pi/6*weight. +The particle volume occupied in the CFD domain can be adjusted by the parameter +"weight", using Vparticle=dsphere^3*pi/6*weight. [Restrictions:] diff --git a/doc/voidFractionModel_dividedVoidFraction.txt b/doc/voidFractionModel_dividedVoidFraction.txt index 69659d19..d87cda43 100644 --- a/doc/voidFractionModel_dividedVoidFraction.txt +++ b/doc/voidFractionModel_dividedVoidFraction.txt @@ -37,14 +37,25 @@ dividedProps [Description:] -The divided voidFraction model is supposed to be used when a particle (or its representation) is in the size range of a CFD cell. Satellite points are used to divide the particle's volume to the touched cells. +The {divided} voidFraction model is supposed to be used when a particle (or its +representation) is in the size range of a CFD cell. Satellite points are used to +divide the particle's volume to the touched cells. -The region of influence of a particle can be increased artificially by "porosity", which blows up the particles, but keeps their volume (for voidfraction calculation) constant. +The region of influence of a particle can be increased artificially by +"porosity", which blows up the particles, but keeps their volume (for +voidfraction calculation) constant. -The particle volume occupied in the CFD domain can be adjusted by the parameter "weight", using Vparticle=dsphere^3*pi/6*weight. +The particle volume occupied in the CFD domain can be adjusted by the parameter +"weight", using Vparticle=dsphere^3*pi/6*weight. -In the basic implementation of solvers, the void fraction is calculated based on all particles. Depending on the solver used, the void fraction calculation is also performed for a certain type of particles. -The void fraction calculation is based on a three-step approach (reset, set and interpolate), i.e., the void fraction is time interpolated from a previous and a next void fraction field. Appropriate names for these fields have to be specified in the sub-dictionaries voidFracFieldNamesPrev and voidFracFieldNamesNext in the couplingProperties dictionary. +In the basic implementation of solvers, the void fraction is calculated based on +all particles. Depending on the solver used, the void fraction calculation is +also performed for a certain type of particles. +The void fraction calculation is based on a three-step approach (reset, set and +interpolate), i.e. the void fraction is time interpolated from a previous and a +next void fraction field. Appropriate names for these fields have to be +specified in the sub-dictionaries voidFracFieldNamesPrev and +voidFracFieldNamesNext in the couplingProperties dictionary. [Restrictions:]