openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2020-12-07T09:37:33Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/396Feature recycle particles2020-12-07T09:37:33ZAndrew HeatherFeature recycle particles### Summary
Added a new `recycleInteraction` lagrangian `patchInteractionModel`. This can be used to recycle/re-inject particles that would otherwise exit the domain.
### Details of new models (If applicable)
Example input in the `<...### Summary
Added a new `recycleInteraction` lagrangian `patchInteractionModel`. This can be used to recycle/re-inject particles that would otherwise exit the domain.
### Details of new models (If applicable)
Example input in the `<constant>/reactingCloud1Properties` file:
```
multiInteractionCoeffs
{
oneInteractionOnly no;
model2
{
patchInteractionModel recycleInteraction;
recycleInteractionCoeffs
{
recyclePatches ((outlet inlet2));
recycleFraction 0.8;
}
}
model1
{
patchInteractionModel standardWallInteraction;
standardWallInteractionCoeffs
{
type rebound;
}
writeToFile yes;
}
}
```
Here the `multiInteraction` model serves as a wrapper, whereby the a `standardWallInteraction` model is used for particle/wall interactions and the new `recycleInteraction` model to reinject particles that exit via the `outlet` patch back into the domain via `inlet2`.
When recycling the particles, the `recycleFraction` entry can be used to retain a certain amount of mass. In the example above, 80% of the mass of particles is reintroduced.
Example case: `$FOAM_SRC/lagrangian/reactingParcelFoam/recycleParticles`
### Risks
Low risk - modular extensionv2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/395BUG: atm wall functions: fix double "value" entry issue2020-12-08T09:38:07ZKutalmış BerçinBUG: atm wall functions: fix double "value" entry issueSTYLE: atm wall functions: use auto and bool types wherever possible
TUT: atmosphericModels: changes for style consistencySTYLE: atm wall functions: use auto and bool types wherever possible
TUT: atmosphericModels: changes for style consistencyAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/394Updated surface handling2020-12-15T20:46:22ZMark OLESENUpdated surface handlingAdds more handling for abaqus formats, sampling on multiple patches/faceZone, handling of multiple weight fields.Adds more handling for abaqus formats, sampling on multiple patches/faceZone, handling of multiple weight fields.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/393ENH: BilgerMixtureFraction: New function object2020-12-15T08:55:31ZKutalmış BerçinENH: BilgerMixtureFraction: New function object### Summary
A contribution by a community member, @g3.
See https://develop.openfoam.com/Development/openfoam/-/issues/1915
### Details of new models (If applicable)
See https://develop.openfoam.com/Development/openfoam/-/issues/1915...### Summary
A contribution by a community member, @g3.
See https://develop.openfoam.com/Development/openfoam/-/issues/1915
### Details of new models (If applicable)
See https://develop.openfoam.com/Development/openfoam/-/issues/1915#note_49598
### Risks
N/A
### ~~WIP issues~~
- ~~The FO needs info from `specieComposition()`: see [the line](https://develop.openfoam.com/Development/openfoam/-/blob/feature-Bilger-mixture-fraction-fo/src/thermophysicalModels/reactionThermo/functionObjects/BilgerMixtureFraction/BilgerMixtureFraction.C#L278)~~
- ~~The function can be called through `ThermoType` (i.e. `thermoPhysicsTypes.H`), but there are too many template-template classes thereat. This would create a very long and thus annoyingly redundant piece of repeating code.~~
- ~~Instead, `ReactionThermo` could be used. But `ReactionThermo` does not have access to the info. Even in `TDACChemistryModel`, `specieComposition` was fetched through `ThermoType`.~~
- ~~Note that if `ReactionThermo` is used, some solvers may not run the FO.~~
[Bat-signal](https://en.wikipedia.org/wiki/Bat-Signal): @andy @Sergiov2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/392Draft: Feature ep1364 fan curve clipping2020-12-16T17:13:16ZMark OLESENDraft: Feature ep1364 fan curve clippinghttps://develop.openfoam.com/Development/openfoam/-/merge_requests/391corrections and improvements for Function12020-11-20T15:18:27ZMark OLESENcorrections and improvements for Function1- easier support for non-mandatory functions.
- support for compatibility lookups
- support frequency or period for Sine/Cosine/Square Function1- easier support for non-mandatory functions.
- support for compatibility lookups
- support frequency or period for Sine/Cosine/Square Function1v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/390draft: Feature streams2023-08-29T11:07:00ZMark OLESENdraft: Feature streamsAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/389Feature rationalize mpi configs2020-11-12T17:25:09ZMark OLESENFeature rationalize mpi configsThe configuration files, user preferences and wmake rules for MPI had become rather confusing and cumbersome. This is especially noticeable when trying to add in minor differences for handling system-level openmpi2 vs openmpit4 etc. Usin...The configuration files, user preferences and wmake rules for MPI had become rather confusing and cumbersome. This is especially noticeable when trying to add in minor differences for handling system-level openmpi2 vs openmpit4 etc. Using a single directory name 'openmpi-system' makes it difficult (impossible) to properly handle different major openmpi versions on the same system.
And additional problem was posed by the choice of preference names. An 'etc/config.sh/mpi' handles all MPI-related dispatch, whereas `etc/config.sh/openmpi` handles ThirdParty adjustments only. Thus make preferences clearly marked with a "prefs." prefix.
Reorganized MPI make rules for more commonality.
Incompatibility name change for advanced user:
- "openmpi-system" -> prefs.sys-openmpi
- "openmpi" -> prefs.openmpi
Prefix system-related mpi with `sys-`, for sorting and consistency.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/388add outer region to PDRblockMesh.2020-12-11T20:24:48ZMark OLESENadd outer region to PDRblockMesh.- adds treatment for outer expansions- adds treatment for outer expansionsv2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/387Miscellaneous code changes - Nov 202020-11-13T09:22:38ZKutalmış BerçinMiscellaneous code changes - Nov 20PS: approval/feedback please @mark @Sergio @andy @Prashant
heatTransferCoeff -> @SergioPS: approval/feedback please @mark @Sergio @andy @Prashant
heatTransferCoeff -> @SergioAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/386ENH: PatchParticleHistogram: add a new cloud FO2020-11-13T09:23:26ZKutalmış BerçinENH: PatchParticleHistogram: add a new cloud FO### Summary
Computes a histogram for the distribution of particle diameters
and corresponding number of particles hitting on a given list of patches.
A minimal example by using `constant/reactingCloud1Properties.cloudFunctions`:
...### Summary
Computes a histogram for the distribution of particle diameters
and corresponding number of particles hitting on a given list of patches.
A minimal example by using `constant/reactingCloud1Properties.cloudFunctions`:
```
patchParticleHistogram1
{
// Mandatory entries (unmodifiable)
type patchParticleHistogram;
patches (<patch1> <patch2> ... <patchN>);
nBins 10;
min 0.1;
max 10.0;
maxStoredParcels 20;
}
```
### Risks
No change to user inputs / no risk to regression.
PS: approval/feedback please @mark @Sergio @Mattijs @PrashantAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/385Issue 1871 ref ptr adjoint turbulence2020-12-04T07:33:42ZMark OLESENIssue 1871 ref ptr adjoint turbulence- reduces some code complexity.- reduces some code complexity.v2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/384Feature generalized newtonian2021-01-28T12:30:08ZSergio FerrarisFeature generalized newtonian1) Derivative of B in thermo.H (dKcdTbyKc) calculated from S and G instead of dGdT. (ported from org)
For the thermos, S and G are easier to obtain that dGdT.
In our branch the Jacobian dKcdTbyKc is not used in the reaction me...1) Derivative of B in thermo.H (dKcdTbyKc) calculated from S and G instead of dGdT. (ported from org)
For the thermos, S and G are easier to obtain that dGdT.
In our branch the Jacobian dKcdTbyKc is not used in the reaction mechanism, but it could be needed in the
future.
2) Removing hRefConst and eRefConst thermos and adding optional hRef, eRef
and Tref as optional in hCosnt and eConst. Tutorials were updated.
3): adding generalizedNewtonian to laminar turbulence model
The generalizedNewtonian viscosity models were ported from
the org version and added to the laminar turbulence framework.
This allows its use to compressible and incompressible solvers
through the turbulence dictionary under the laminar sub-dictionary.
The thermal laminar viscosity is taken from the thermo for solvers
that use thermo library or from the transportProperties dictionary
for incompressible solvers.
At the moment the option to include viscosity models through the
transportDict is still available.
The icoTabulated EoS, hTabulated thermo and tabulated transport were ported from the org version
All the single phase solvers are ready to use the generalizedNewtonian laminar models. Some multi-phase
solver needs the instantiation of the transport.
The VoF solver icoReactingMultiPhaseInterFoam is capable of using the new models.
Updating tutorial:
tutorials/multiphase/icoReactingMultiPhaseInterFoam/inertMultiphaseMultiComponentv2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/383Feature block mesh edges2020-10-06T08:37:12ZMark OLESENFeature block mesh edges- adds a new, more natural way to specify block mesh _arc_ edges using the arc origin that eliminates tedious and error-prone calculations. For example,
```
arc 0 1 origin (0 0 0);
```
When the keyword is missing, this corresponds to the...- adds a new, more natural way to specify block mesh _arc_ edges using the arc origin that eliminates tedious and error-prone calculations. For example,
```
arc 0 1 origin (0 0 0);
```
When the keyword is missing, this corresponds to the traditional means of specifying the arc via an additional point on the circumference (full backward compatibility). For example,
```
arc 0 1 (0.707 0.707 0);
```Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/382Pstream ranges2020-09-30T11:25:35ZMark OLESENPstream rangesv2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/381ENH: yPlus: add option to disable wall function contributions (#1773)2020-09-24T16:31:09ZKutalmış BerçinENH: yPlus: add option to disable wall function contributions (#1773)### Summary
See the self-explanatory commit messages.
### Resolved bugs (If applicable)
#1773
### Details of new models (If applicable)
Small test cases: [GL1773-pre-fix.zip](/uploads/55a0e0a9f20b72222d7f1710a1f742d9/GL1773-pre-fix...### Summary
See the self-explanatory commit messages.
### Resolved bugs (If applicable)
#1773
### Details of new models (If applicable)
Small test cases: [GL1773-pre-fix.zip](/uploads/55a0e0a9f20b72222d7f1710a1f742d9/GL1773-pre-fix.zip) vs [GL1773-post-fix](/uploads/6e82b41f337cf0b251280bffb0eb9b9d/GL1773-post-fix.zip)
Test-case characteristics:
* One-dimensional smooth-wall plane channel flow, ReTau=5200
* Number of cells = 20
* nu = 0.000192827 \[m2/s\]
* The case was designed to produce => -1\*sqrt(mag(wallShearStress)) = 1
* The y1+ set (expected) = {0.05, 0.5, 1, 5, 10, 20, 30, 50, 100, ~~1000~~}
* kOmegaSST/SpalartAllmaras, simpleFoam
Main field of interest:
* mag(wallShearStress) function object returns \~ 1 for all test cases, therefore the expected y1+
* yPlus function object (min) results for `lowerWall` rounded up to 2 decimals:
### y1+ = 0.05:
| Wall function | Pre-fix yPlus | Post-fix yPlus (when `useWallFunction=false`) |
| --- | ------ |---------:|
| nutUWallFunction | **0.12** | 0.05 |
| nutkWallFunction | **0.00025** | 0.05 |
| nutUSpaldingWallFunction | 0.05 | 0.05 |
| nutUBlendedWallFunction | 0.05 | 0.05 |
| nutLowReWallFunction | 0.05 | 0.05 |
### y1+ = 0.5:
| Wall function | Pre-fix yPlus | Post-fix yPlus (when `useWallFunction=false`) |
| --- | ------ |---------:|
| nutUWallFunction | **0.18** | 0.50 |
| nutkWallFunction | **0.025** | 0.50 |
| nutUSpaldingWallFunction | 0.50 | 0.50 |
| nutUBlendedWallFunction | 0.50 | 0.50 |
### y1+ = 1:
| Wall function | Pre-fix yPlus | Post-fix yPlus (when `useWallFunction=false`) |
| --- | ------ |---------:|
| nutUWallFunction | **0.34** | 1.00 |
| nutkWallFunction | **0.1** | 1.00 |
| nutUSpaldingWallFunction | 1.00 | 1.00 |
| nutUBlendedWallFunction | 1.00 | 1.00 |
### y1+ = 5:
| Wall function | Pre-fix yPlus | Post-fix yPlus (when `useWallFunction=false`) |
| --- | ------ |---------:|
| nutUWallFunction | **3.02** | 5.00 |
| nutkWallFunction | **2.75** | 5.00 |
| nutUSpaldingWallFunction | 5.00 | 5.00 |
| nutUBlendedWallFunction | 5.00 | 5.00 |
### y1+ = 10:
| Wall function | Pre-fix yPlus | Post-fix yPlus (when `useWallFunction=false`) |
| --- | ------ |---------:|
| nutUWallFunction | **9.12** | 10.00 |
| nutkWallFunction | **8.31** | 10.00 |
| nutUSpaldingWallFunction | 10.00 | 10.00 |
| nutUBlendedWallFunction | 10.00 | 10.00 |
### y1+ = 20:
| Wall function | Pre-fix yPlus | Post-fix yPlus (when `useWallFunction=false`) |
| --- | ------ |---------:|
| nutUWallFunction | 20.00 | 20.02 |
| nutkWallFunction | **19.30** | 20.01 |
| nutUSpaldingWallFunction | 20.00 | 20.00 |
| nutUBlendedWallFunction | 20.00 | 20.01 |
### y1+ = 30:
| Wall function | Pre-fix yPlus | Post-fix yPlus (when `useWallFunction=false`) |
| --- | ------ |---------:|
| nutUWallFunction | 30.09 | 30.09 |
| nutkWallFunction | 29.91 | 30.12 |
| nutUSpaldingWallFunction | 30.08 | 30.08 |
| nutUBlendedWallFunction | 30.09 | 30.09 |
### y1+ = 50:
| Wall function | Pre-fix yPlus | Post-fix yPlus (when `useWallFunction=false`) |
| --- | ------ |---------:|
| nutUWallFunction | 50.16 | 50.16 |
| nutkWallFunction | 50.51 | 50.19 |
| nutUSpaldingWallFunction | 50.17 | 50.17 |
| nutUBlendedWallFunction | 50.16 | 50.16 |
### y1+ = 100:
| Wall function | Pre-fix yPlus | Post-fix yPlus (when `useWallFunction=false`) |
| --- | ------ |---------:|
| nutUWallFunction | 100.01 | 100.01 |
| nutkWallFunction | 100.96 | 100.01 |
| nutUSpaldingWallFunction | 100.01 | 100.01 |
| nutUBlendedWallFunction | 100.01 | 100.01 |
### Risks
- Compiled with Gcc-7.4.1/Clang-9.0, DPInt32Opt
- No regression issue: [1-pre-fix-yPlus.zip](/uploads/213187624c831a9322790f83da09bd95/1-pre-fix-yPlus.zip) vs [2-post-fix-yPlus.zip](/uploads/f8ee035a427a3c7ea2fefb5d38a40609/2-post-fix-yPlus.zip) (Test: `incompressible/pisoFoam/RAS/cavity`)
- No changes in the default behaviour.
- User can now select the new behaviour by `useWallFunction=false` which is by default `true`.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/380ENH: finer granularity for handling functionObject failure (#1779)2020-08-06T16:15:10ZMark OLESENENH: finer granularity for handling functionObject failure (#1779)- additional "errors" entry with enumerated values
(default|warn|ignore|strict) for defining warning or error at
construct or runtime stage
- default : construct = warn, runtime = fatal
- warn : construct = warn, runtime = warn
-...- additional "errors" entry with enumerated values
(default|warn|ignore|strict) for defining warning or error at
construct or runtime stage
- default : construct = warn, runtime = fatal
- warn : construct = warn, runtime = warn
- ignore : construct = silent, runtime = silent
- strict : construct = fatal, runtime = fatal
The errors control can be added at the top-level and/or for individual
function objects.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/379remove cyclic dependencies for phase systems2020-08-06T06:23:44ZMark OLESENremove cyclic dependencies for phase systems### centralize more libraries in src/phaseSystemModels
### avoid phaseSystem cyclic dependencies, reduce number of libraries
Previously the phaseSystems had a number of smaller libraries to
provide interface and model properties. ...### centralize more libraries in src/phaseSystemModels
### avoid phaseSystem cyclic dependencies, reduce number of libraries
Previously the phaseSystems had a number of smaller libraries to
provide interface and model properties. However, the cyclic
dependencies between phaseSystem and the models (and turbulence)
causes extreme difficultly for mingw linking. The potential
additional flexibility is not actually used anywhere.
- libincompressibleMultiphaseSystems
- removed: libmassTransferModels
- libmultiphaseSystem
- removed: libcompressibleMultiphaseEulerianInterfacialModels
- libreactingMultiphaseSystem
- removed: libreactingPhaseSystem
- removed: libreactingEulerianFvPatchFields
- removed: libreactingEulerianInterfacialCompositionModels
- removed: libreactingEulerianInterfacialModels
- removed: libmultiphaseReactingTurbulenceModels
- libreactingTwoPhaseSystem
- removed: libreactingPhaseSystem
- removed: libreactingEulerianFvPatchFields
- removed: libreactingEulerianInterfacialCompositionModels
- removed: libreactingEulerianInterfacialModels
### Avoid duplicate symbol for phaseCompressibleTurbulenceModels.
Common turbulence models are defined in libreactingMultiphaseSystem,
and libmultiphaseReactingTurbulenceModels is now redundant.
The libtwoPhaseReactingTurbulenceModels extends the common models
for reactingTwoPhaseSystem.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/378autoPtr/tmp cleanup2020-07-17T15:29:17ZMark OLESENautoPtr/tmp cleanupMostly style (declutter) changes for autoPtr/tmp. The `valid()` and `empty()` methods tended to result (IMO) dense, hard to read code. Worst case example is an autoPtr wrapping of a tmp:
```
if (data.valid() && data().valid())
```
Wh...Mostly style (declutter) changes for autoPtr/tmp. The `valid()` and `empty()` methods tended to result (IMO) dense, hard to read code. Worst case example is an autoPtr wrapping of a tmp:
```
if (data.valid() && data().valid())
```
Which is somewhat easier to read with direct testing of the pointer, and a pointer deference:
```
if (data && data->valid())
```
Other cases of opaque code arise from the `empty()` with a negation:
```
if (!ptr.empty()) ... can use the pointer
```
instead of simply
```
if (ptr) ... can use the pointer
```
Removed some pre-nullObject (2014) code remnants from the tmp logic.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/377New Evap-Cond Lagrangian model (FuchsKnudsen) for solution (liquid + solid)...2020-09-22T15:37:04ZSergio FerrarisNew Evap-Cond Lagrangian model (FuchsKnudsen) for solution (liquid + solid) dropletsAdding evap-cond Lagrangian model for solution droplets
1) Adding LiquidEvapFuchsKnudsen model for Lagrangian evaporation.
This models is based on a diffusion type of evaporation/
condensation on particles composed...Adding evap-cond Lagrangian model for solution droplets
1) Adding LiquidEvapFuchsKnudsen model for Lagrangian evaporation.
This models is based on a diffusion type of evaporation/
condensation on particles composed of solution (liquid + solid).
2) Adding modes of calculating the particle rho and volume change.
The new keyword in constantProperties is volumeUpdateMethod
which three options:
a) constantRho
b) constantVolume
c) updateRhoAndVol
3) The entry rho0 is now optional for multicomponent parcels.
If defined , it is used but if it is not the actuall mixture
provided is used to calculate rho0 of the particle
T0 is still used as initial T and Cp0 is over-written in the
multi-component cloudAndrew HeatherAndrew Heather