openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2020-10-06T08:37:12Zhttps://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/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 Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/375Feature dynamic library - issue #17372020-07-14T15:41:40ZMark OLESENFeature dynamic library - issue #1737Some minor cleanup for dlLibraryTable handling to avoid multiple closing of duplicate libnames, mutable access to libs, a global singleton.Some minor cleanup for dlLibraryTable handling to avoid multiple closing of duplicate libnames, mutable access to libs, a global singleton.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/374Feature add additional scaling to geometric area overlap calculation inside acmi2020-12-11T10:35:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comFeature add additional scaling to geometric area overlap calculation inside acmi### Summary
Added 'scale' parameter to cyclicACMI. Scales the amount of 'coupledness' (= mask). Allows opening/closing without mesh motion.
### Resolved bugs (If applicable)
Rebased onto develop
### Risks
- kept as close as possibl...### Summary
Added 'scale' parameter to cyclicACMI. Scales the amount of 'coupledness' (= mask). Allows opening/closing without mesh motion.
### Resolved bugs (If applicable)
Rebased onto develop
### Risks
- kept as close as possible to develop.
- tested old functionality against develop. Bit identical (non-parallel & parallel)
- tested new functionality (TJunctionSwitching). Also parallel.
- small optimisation in using faces instead of localFaces.
- probably not working with topo change version.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/373ENH: Updated Curle function object2020-06-18T20:56:18ZAndrew HeatherENH: Updated Curle function objectThe Curle function object now computes the acoustic pressure for a set of observer locations as opposed to creating a very approximate volume field. The locations can either be supplied as a list, or extracted from the face centres of a...The Curle function object now computes the acoustic pressure for a set of observer locations as opposed to creating a very approximate volume field. The locations can either be supplied as a list, or extracted from the face centres of a user-supplied surface.
These changes also include fixes for reading the ensight geometry files where the mask was not correctly replaced by the appropriate zero padded index. Note that the `surfaceNoise` model currently requires the data to be provided in ascii format.
For testing, the `vortexShed` tutorial has been updated to process both the point- and surface-based options, and correctly recovers the shedding frequency of approx 0.1 Hz.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/372BUG: provide setup backward-compat for actuationDiskSourceCoeffs2020-06-18T20:59:51ZKutalmış BerçinBUG: provide setup backward-compat for actuationDiskSourceCoeffs#1732 @Prashant#1732 @Prashantv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/371ENH: prevent natural-logarithm domain errors in nut wall functions2020-06-18T20:57:08ZKutalmış BerçinENH: prevent natural-logarithm domain errors in nut wall functions#1730#1730v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/370DOC-STYLE: various release changes2020-06-16T12:50:23ZKutalmış BerçinDOC-STYLE: various release changes- Header-file documentation of various new functionalities was moved to the Extended Code Guide.
- Various corrections to the clashes in release commits #1726- Header-file documentation of various new functionalities was moved to the Extended Code Guide.
- Various corrections to the clashes in release commits #1726v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/369New Weber number cloud function object2020-06-11T14:00:37ZAndrew HeatherNew Weber number cloud function objectExample usage:
cloudFunctions
{
WeberNumber1
{
type WeberNumber;
}
}
This will calculate and write the Weber number field as a 'standard' cloud field, available for post-proces...Example usage:
cloudFunctions
{
WeberNumber1
{
type WeberNumber;
}
}
This will calculate and write the Weber number field as a 'standard' cloud field, available for post-processing alongside other lagrangian fields in the lagrangian/<cloudName> directory.
See example in `$FOAM_TUTORIALS/lagrangian/sprayFoam/aachenBomb/constant/sprayCloudProperties`v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/368Updates for the adjoint optimisation library2020-06-12T14:04:50ZVaggelis PapoutsisUpdates for the adjoint optimisation libraryA number of updates related to the adjoint optimisation library.
The branch contains mainly enhancements in the infrastructure of the objective functions, the computation of sensitivity derivatives for shape optimisation and some minor...A number of updates related to the adjoint optimisation library.
The branch contains mainly enhancements in the infrastructure of the objective functions, the computation of sensitivity derivatives for shape optimisation and some minor new features like the adjoint to the rotatinWallVelocity boundary condition and the introduction of a new objective function minimising the square of the turbulent viscosity over a certain volume, which can be used to qualitatively approximate (and then minimise) noise (see also the header of the corresponding class for a bibliographic reference).v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/367AMI code enhancements2020-06-24T21:12:39ZAndrew HeatherAMI code enhancements### Summary
**Note: this is beta-level code and will receive further updates in future releases**
This change set includes:
- New option for `cyclicAMI` and `cyclicACMI` patches to perform topological updates to enforce a 1-to-1 m...### Summary
**Note: this is beta-level code and will receive further updates in future releases**
This change set includes:
- New option for `cyclicAMI` and `cyclicACMI` patches to perform topological updates to enforce a 1-to-1 match between source and target patches to ensure conservation across AMI patches and greatly reduced pressure field perturbations. Changes based on ref [1]
- Deprecated `directAMI`; replaced by `nearestFaceAMI`
- Significant code refactoring
### Resolved bugs (If applicable)
- General AMI conservation issues/noisy pressure predictions
### Details of new models (If applicable)
- Backwards compatibility [should be] maintained
- New topological changes triggered by using a special mesh motion solver: `dynamicFvMesh dynamicMotionSolverFvMeshAMI;`
- this may be absorbed into the 'standard' `dynamicMotionSolverFvMesh` model in future releases
- Test case: [mixerVesselAMI2D_with-boundary-layers.tgz](/uploads/4ca838c78e139007cb6f2f06026bdf07/mixerVesselAMI2D_with-boundary-layers.tgz)
| dynamicMotionSolverFvMesh | dynamicMotionSolverFvMeshAMI |
| ------ | ------ |
| ![plot](/uploads/37f8e095ad01c8c10dcdb9ab40ffa74c/plot.png) v2006| ![plot](/uploads/ad90049926e774bd3127256f86f0e075/plot.png) v2006|
| ![plot](/uploads/7a0930907ab64ac5941c6bcf781e17ba/plot.png) v1912| |
Note: since the AMI code triggers topological updates, to reconstruct parallel cases:
- use `reconstructParMesh` to reconstruct the mesh at each time, followed by `reconstructPar` to reconstruct the fields; or
- use `redistributePar -reconstruct` to reconstruct both mesh and fields (in parallel)
- Code refactoring has enabled greater control of the AMI; the AMIMethod can now be set in the `polyMesh/boundary` file, e.g.
```
AMI2
{
type cyclicAMI;
inGroups 1(cyclicAMI);
nFaces 96;
startFace 6336;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch AMI1;
// New optional entries
AMIMethod faceAreaWeightAMI;
restartUncoveredSourceFace 1;
}
```
### Deprecations
The `directAMI` method has been deprecated and replaced by the faster and more robust, new `nearestFaceAMI` method. The new method creates a 1-to-1 mapping based on the nearest face.
### Risks
- Significant change to AMI code
- Not only affects cyclic patches, but other areas of the code that make use of the tooling, e.g.:
- mapped patches
- mapFieldsPar
- region models (film modelling)
- mapping function objects
### Known issues/to check
When using `dynamicMotionSolverFvMeshAMI`
- restart behaviour not currently available
### Tests
Checked on the following cases:
- pimpleFoam/laminar/mixerVesselAMI2D
- pimpleFoam/RAS/oscillatingInletACMI2D
- XiDyMFoam/annularCombustorTurbine
- {customer turbo machinery}
For each, the `dynamicMotionSolverFvMesh` option recovers v1912 behaviour
### References
[1] H.J. Aguerre, S. Márquez Damián J.M. Gimenez, N.M.Nigro, *Conservative handling of arbitrary non-conformal interfaces using an efficient supermesh*, Journal of Computational Physics 335(15)21-49. 2017. https://doi.org/10.1016/j.jcp.2017.01.018
### Acknowledgements
- Many thanks to Horacio Aguerre @aguerrehoracio and Santiago Márquez @santiagomarquezd for bringing the methodology to our attention and for many useful discussions and testing throughout these developments.v2006https://develop.openfoam.com/Development/openfoam/-/merge_requests/366Feature flexible install paths2020-06-08T12:50:48ZMark OLESENFeature flexible install pathsAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/365Adding PIMPLE option finalOnLastPimpleIterOnly2020-06-08T14:42:54ZSergio FerrarisAdding PIMPLE option finalOnLastPimpleIterOnlyThe PIMPLE option finalOnLastPimpleIterOnly allows the call the Final
solver only in the last PIMPLE loop. The default is false which is
the present behavior.The PIMPLE option finalOnLastPimpleIterOnly allows the call the Final
solver only in the last PIMPLE loop. The default is false which is
the present behavior.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/364ENH: Miscellaneous enhancement/features and bug fixes2020-06-11T12:30:36ZKutalmış BerçinENH: Miscellaneous enhancement/features and bug fixesv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/363ENH: New atmospheric boundary layer (ABL) model suite (Part 1)2020-06-09T10:09:12ZKutalmış BerçinENH: New atmospheric boundary layer (ABL) model suite (Part 1)### Summary
This commit is the first main commit of a collaborative work between `OpenCFD Ltd.`-`ENERCON Gmbh`-`CENER`, for which there will be another comprehensive commit in the next release (may include SOWFA-6 - [see](https://gith...### Summary
This commit is the first main commit of a collaborative work between `OpenCFD Ltd.`-`ENERCON Gmbh`-`CENER`, for which there will be another comprehensive commit in the next release (may include SOWFA-6 - [see](https://github.com/NREL/SOWFA-6/issues/11) for exchange of ideas).
With this commit, OpenFOAM learns:
- How to comprehensively model (RANS) surface and Ekman atmosphere layers under (slightly/very) stable/unstable/neutral atmospheric stability conditions over spatiotemporal-variant terrain (e.g. partially forestry plain).
### Details
Please refer to the header file documentation for complete set of details.
- 8 new `fvOption`s that are usable with epsilon/omega-based RANS closure models:
- atmAmbientTurbSource
- atmBuoyancyTurbSource
- atmCoriolisUSource
- atmLengthScaleTurbSource
- atmPlantCanopyTurbSource
- atmPlantCanopyUSource
- atmPlantCanopyTSource
- atmNutSource
- 7 new `wall function`s shipped with `PatchFunction1` and `TimeFunction1` support for the input entries:
- atmAlphatkWallFunction
- atmEpsilonWallFunction
- atmNutkWallFunction
- atmNutUWallFunction
- atmNutWallFunction
- atmOmegaWallFunction
- atmTurbulentHeatFluxTemperature
- A new function object to quantify the [Obukhov length](http://glossary.ametsoc.org/wiki/Obukhov_length#:~:text=Obukhov%20length,consumption%20of%20turbulence%20kinetic%20energy.):
- ObukhovLength
- 3 new tutorials involving `buoyantBoussinesqSimpleFoam` verifications in comparison to field measurements:
- `verificationAndValidation/atmosphericFlows/atmFlatTerrain`
- verification with the `Leipzig` field experiment
- illustration of precursor/successor field mapping
- `verificationAndValidation/atmosphericFlows/atmForestStability`
- verification with the Sweden field experiment
- 2 new actuator disk modelling approaches in the existing `actuationDiskSource` wherein the incoming velocity measurements can now be held by using `topoSet`s.
### Resolved bugs (If applicable)
None.
### Verifications
The model suite was verified for `neutral stability` by the `Leipzig` experiment for which all the details can be found in, and can be reproduced by `verificationAndValidation/atmosphericFlows/atmFlatTerrain`
`buoyantBoussinesqSimpleFoam-kEpsilon`:
<img src="/uploads/96349ecee9d1561d196795b266d22cdd/u-z.png" width="250" height="500">
<img src="/uploads/146d8921d130e210f27b21f1c8a902ce/v-z.png" width="250" height="500">
`buoyantBoussinesqSimpleFoam-kOmegaSST`:
<img src="/uploads/aead7fafb086e2d918302d45660e8e61/u-z.png" width="250" height="500">
<img src="/uploads/bca10f4506b06986ed47c2114e9c43ad/v-z.png" width="250" height="500">
In addition, the model suite was verified for all spectrum of stability conditions with forestry ground by the `Sweden(?)` experiment for which all the details can be found in, and can be reproduced by `verificationAndValidation/atmosphericFlows/atmForestStability`
`buoyantBoussinesqSimpleFoam-kEpsilon` (wind speed, turbulent kinetic energy, and wind veer profiles, respectively):
<img src="/uploads/370aca91fc19f2fbb719ce4655ad4618/uNorm-zNorm.png" width="600" height="500">
<img src="/uploads/e024e77ee5460299774ccaeff9e360c5/kNorm-zNorm.png" width="600" height="500">
<img src="/uploads/d292e5901e01dbb0bc517d9c76be79b2/veer-zNorm.png" width="600" height="500">
with the Obukhov lengths:
veryStable = 44.7979
stable = 300.723
slightlyStable = 859.962
neutral = undefined
slightlyUnstable = -547.088
unstable = -265.992
`buoyantBoussinesqSimpleFoam-kOmegaSST` (wind speed, turbulent kinetic energy, and wind veer profiles, respectively):
<img src="/uploads/4e19e3e02e97044e8d2dda9e718e2e32/uNorm-zNorm.png" width="600" height="500">
<img src="/uploads/8803c8bbe63de1ac2015310615521fa2/kNorm-zNorm.png" width="600" height="500">
<img src="/uploads/c938b5ae2d5fd19e5116bd00b910809a/veer-zNorm.png" width="600" height="500">
with the Obukhov lengths:
veryStable = 67.5555
stable = 396.562
slightlyStable = 1147.69
neutral = undefined
slightlyUnstable = -707.885
unstable = -319.368
Furthermore, the persistence of atmospheric boundary layer inlet profiles downstream were quantified in comparison to the profiles near the outlet, and it was found out that the overall discrepancy is within 2%:
(wind speed, turbulent kinetic energy, turbulence intensity, and temperature horizontal profiles, respectively)
<img src="/uploads/e01e5f6429cb054adda7bddc649d4348/Horizontal_MagU.png" width="600" height="500">
<img src="/uploads/78472b8205b8c79a611793a9b0a6933a/Horizontal_k.png" width="600" height="500">
<img src="/uploads/f001568734ac5b398018ba1fd5349aa2/Horizontal_TI.png" width="600" height="500">
<img src="/uploads/21eaa5b3ec305eacb8f2af11c0226985/Horizontal_T.png" width="600" height="500">
### Risks
- **User input change:** `nutkAtmRoughWallFunction` is renamed without extra support to `atmNutkWallFunction` (ensured the bitwise regression)
- Since the majority of the utilities above are new, the potential effects on the existing utilities would only be unexpected.
v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/362ENH: unify use of dictionary method names2020-06-03T08:31:01ZMark OLESENENH: unify use of dictionary method names- previously introduced `getOrDefault` as a dictionary _get_ method,
now complete the transition and use it everywhere instead of
`lookupOrDefault`. This avoids mixed usage of the two methods that
are identical in behaviour, makes ...- previously introduced `getOrDefault` as a dictionary _get_ method,
now complete the transition and use it everywhere instead of
`lookupOrDefault`. This avoids mixed usage of the two methods that
are identical in behaviour, makes for shorter names, and promotes
the distinction between "lookup" access (ie, return a token stream,
locate and return an entry) and "get" access (ie, the above with
conversion to concrete types such as scalar, label etc).v2006Andrew HeatherAndrew Heather