openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2020-01-29T16:54:18Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/336COMP: backport of updates for gcc-92 compilation2020-01-29T16:54:18ZMark OLESENCOMP: backport of updates for gcc-92 compilationAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/335Generated methods2020-01-30T12:39:49ZMark OLESENGenerated methodsExplicit define generated methods where the pairing (constructor/assignment) is partly broken by the existence of user-defined methods.
In some cases, it can be sufficient to simply remove the user definition and rely entirely on genera...Explicit define generated methods where the pairing (constructor/assignment) is partly broken by the existence of user-defined methods.
In some cases, it can be sufficient to simply remove the user definition and rely entirely on generated methods. In other cases, the user-defined methods are useful to retain. So we need to declare defaulted versions. This change is largely driven by new warnings from gcc-9.2.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/334ENH: lduMatrix: new matrix solvers: PPCG,PPCR2020-03-11T13:53:05ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: lduMatrix: new matrix solvers: PPCG,PPCRPPCG is pipelined version of PCG, PPCR is conjugate
residual version.PPCG is pipelined version of PCG, PPCR is conjugate
residual version.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/333support eulersolver heat transfer fo2020-05-21T14:21:40ZSergio Ferrarissupport eulersolver heat transfer foThe lib in src/phaseSystemModels/reactingEulerFoam/phaseSystems/
was not fully linked due to cyclic dependencies. When used in 'fieldFunctionObject' (to get the
HTC for multiphase), created a problem of linking in two apps:
appli...The lib in src/phaseSystemModels/reactingEulerFoam/phaseSystems/
was not fully linked due to cyclic dependencies. When used in 'fieldFunctionObject' (to get the
HTC for multiphase), created a problem of linking in two apps:
applications/utilities/preProcessing/createExternalCoupledPatchGeometry/Make/options
applications/solvers/multiphase/reactingEulerFoam/functionObjects/Make/options
And surely when called from controlDict in the tutorials.
Previously the missing libs were provided in the solvers (Euler solvers).
As we need a fully linked phaseSystems lib. I compiled last this lib in rc/phaseSystemModels/reactingEulerFoam/Allwmake. This creates a complete lib usable in fieldFunctionObject.
Some changes were needed in the intermediate libs as well for compilation.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/332ENH: stream adjustments2020-01-23T15:43:57ZMark OLESENENH: stream adjustments- make stream constructors explicit
- remove "using std::ifstream", "using std::iofstream" statements
for a cleaner namespace.
* copy/move assignments for ITstream
* IStringStream: default construct and construct from std::string
...- make stream constructors explicit
- remove "using std::ifstream", "using std::iofstream" statements
for a cleaner namespace.
* copy/move assignments for ITstream
* IStringStream: default construct and construct from std::string
instead of Foam::string
- reduce some overhead in masterOFstream
- simplify Pstream handling of string variants (#1525)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/331Submodule visualization2020-01-23T14:24:33ZMark OLESENSubmodule visualizationThis finalises the work done to collect visualization-related items:
- catalyst
- paraview-plugins
- runTimePostProcessing
into a single place.
- Makes it easier to make related code changes.
- Makes it easier to mix and match differen...This finalises the work done to collect visualization-related items:
- catalyst
- paraview-plugins
- runTimePostProcessing
into a single place.
- Makes it easier to make related code changes.
- Makes it easier to mix and match different combinations of VTK/ParaView versions and capabilities (Eg, MESA, MPI etc).
Replaces the standalone catalyst submodule.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/330SUBMODULE: added OpenQBMM submodule - see #15222020-01-25T02:11:02ZAndrew HeatherSUBMODULE: added OpenQBMM submodule - see #1522### Summary
Adds the OpenQBMM library from https://www.openqbmm.org/
OpenQBMM is a suite of solvers to simulate polydisperse multiphase flows using
Quadrature-Based Moment Methods (QBMM).
Main author: Alberto Passalacqua @alber...### Summary
Adds the OpenQBMM library from https://www.openqbmm.org/
OpenQBMM is a suite of solvers to simulate polydisperse multiphase flows using
Quadrature-Based Moment Methods (QBMM).
Main author: Alberto Passalacqua @albertop
### Details of new models (If applicable)
OpenQBMM implements methods to describe polydisperse multiphase flows, from the simplest size evolution of non-inertial particles in a carrier fluid to more complex cases with bubbles in a gas-liquid system and inertial particles in a gas-particle flow. These capabilities are implemented in a suite of solvers, among which:
- `pbeFoam` solves a population balance equation in a single control volume. This solver is useful to test kernel functions in the population balance equation and to solve spatially homogeneous problems. Example cases can be found in OpenQBMM/validation/pbeFoam/ which show the validation cases discussed in E. Madadi-Kandjani, A. Passalacqua, An extended quadrature-based moment method with log-normal kernel density functions, Chemical Engineering Science. 131 (2015) 323–339. https://doi.org/10.1016/j.ces.2015.04.005.
- `pbeTransportFoam` allows a frozen flow field to be used to solve a population balance equation with pre-imposed flow motion. A validation case is available in OpenQBMM/validation/pbeTransportFoam/serraTaylorCouette/ and discussed in A. Passalacqua, F. Laurent, E. Madadi-Kandjani, J.C. Heylmun, R.O. Fox, An open-source quadrature-based population balance solver for OpenFOAM, Chemical Engineering Science. 176 (2018) 306–318. https://doi.org/10.1016/j.ces.2017.10.043.
- `buoyantPbePimpleFoam` allows a transient flow with population balance equation to be modelled.
- `polydisperseBubbleFoam` is a specialized solver for gas-liquid flows with evolution of the bubble size due to coalescence and breakup. Bubbles can have a velocity distribution also accounting for polycelerity, with bubbles with different sizes in the same control volume allowed to have different velocities. Example cases are available in OpenQBMM/validation/polydisperseBubbleFoam/ while the implementation is discussed in the article J.C. Heylmun, B. Kong, A. Passalacqua, R.O. Fox, A quadrature-based moment method for polydisperse bubbly flows, Computer Physics Communications. 244 (2019) 187–204. https://doi.org/10.1016/j.cpc.2019.06.005.
- `denseAGFoam` implements an anisotropic Gaussian model for dense gas-particle flows. Implementation details are discussed in B. Kong, R.O. Fox, A solution algorithm for fluid–particle flows across all flow regimes, Journal of Computational Physics. 344 (2017) 575–594. https://doi.org/10.1016/j.jcp.2017.05.013.
- The solvers in the `velocityDistribitionTransport` implement quadrature-based moment methods for velocity distributions. These methods are suitable to describe disperse flows with non-equilibrium velocity distributions, such as crossing jets of particles or droplets. The `diluteVdfTransportFoam` solver implements the quadrature-based velocity distribution transport algorithm for a disperse phase, not coupled to a carrier fluid. One-way coupling between the disperse phase and the carrier fluid is implemented `oneWayCoupledVdfTransportFoam`. In both solvers, the particle size can evolve in space and time and particles can interact through collisions.
### Risks
Low - added as a submodulev2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/329BUG: add switch for nu:DphitEff in kEpsilonPhitF (fixes #1560)2020-01-21T12:28:10ZKutalmış BerçinBUG: add switch for nu:DphitEff in kEpsilonPhitF (fixes #1560)Including `nu` in `DphitEff` even though it is not present in (LUU:Eq. 17)
provided higher level of resemblance to benchmarks for the tests considered,
particularly for the peak skin friction (yet, pressure-related predictions
...Including `nu` in `DphitEff` even though it is not present in (LUU:Eq. 17)
provided higher level of resemblance to benchmarks for the tests considered,
particularly for the peak skin friction (yet, pressure-related predictions
were unaffected). Users can switch off `nu` in `DphitEff` by using
`includeNu` entry in `kEpsilonPhitFCoeffs` in order tofollow the
reference paper thereat. `includeNu` is left `true` by default.
See GitLab issue #1560,
- removes redundant `phit()` and `f()` access funcs,
- replaces `dimensionedScalar` with `dimScalar` to gain space.
LUU: Laurence, D. R., Uribe, J. C., & Utyuzhnikov, S. V. (2005).v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/328WIP: Revisiting analytical eigen decompositions and polynomialEqns2020-01-17T21:07:33ZKutalmış BerçinWIP: Revisiting analytical eigen decompositions and polynomialEqnsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/327ENH: shm: support for automatic faceZones2020-01-16T12:22:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: shm: support for automatic faceZones### Summary
Extends meshing of faceZones to allow having multiple faceZones per surface
### Details of new models (If applicable)
Currently a single (explicitly named) faceZone can be specified for a surface. This new function...### Summary
Extends meshing of faceZones to allow having multiple faceZones per surface
### Details of new models (If applicable)
Currently a single (explicitly named) faceZone can be specified for a surface. This new functionality extends it to have a separate faceZone for every region of the surface.
### Risks
The default behaviour has not changed. A new keyword, faceZoneNaming, can switch on the new behaviour. See the new mesh/snappyHexMesh/faceZoneRegions tutorial
v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/326ENH: regIOobject store() now also registers the object2020-01-13T15:42:55ZMark OLESENENH: regIOobject store() now also registers the object- previously the store() method just set the ownedByRegistry flag.
Now ensure that it is indeed registered first.
- support register/store of tmp<> items.
The tmp parameter is not cleared, but changed from PTR to CREF
to allow fur...- previously the store() method just set the ownedByRegistry flag.
Now ensure that it is indeed registered first.
- support register/store of tmp<> items.
The tmp parameter is not cleared, but changed from PTR to CREF
to allow further use.
The implicit registration allows code simplification using the
GeometricField::New factory method, for example.
Old Code
========
volScalarField* ptr = new volScalarField
(
IOobject
(
fieldName,
mesh.time().timeName(),
mesh,
IOobject::NO_READ,
IOobject::NO_WRITE,
true // Register
),
mesh,
dimless,
zeroGradientFvPatchField<scalar>::typeName
);
ptr->store();
New Code
========
auto tptr = volScalarField::New
(
fieldName,
mesh,
dimless,
zeroGradientFvPatchField<scalar>::typeName
);
regIOobject::store(tptr);
or even
regIOobject::store
(
volScalarField::New
(
fieldName,
mesh,
dimless,
zeroGradientFvPatchField<scalar>::typeName
)
);Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/325BUG: wrong bounding of sensitivity contituents in case of many control boxes ...2020-01-09T21:04:42ZVaggelis PapoutsisBUG: wrong bounding of sensitivity contituents in case of many control boxes (Fixes #1549)When more than one volumetric B-Splines control boxes are present, the
sensitivity constituents corresponding to the non-active design
variables were not bounded(zeroed) correctly. The resultant
sensitivities, used in the optimization, w...When more than one volumetric B-Splines control boxes are present, the
sensitivity constituents corresponding to the non-active design
variables were not bounded(zeroed) correctly. The resultant
sensitivities, used in the optimization, were bounded correctly, so this
was more a bug pertaining to the output file of the sensitivities rather
than a functional one.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/324TUT: misc cleanup in various tutorials2020-01-12T11:10:18ZKutalmış BerçinTUT: misc cleanup in various tutorialsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/323WIP: ENH: add 'outputCoeffs' and 'extendedOutput' options to forceCoeffs2020-01-17T21:07:23ZKutalmış BerçinWIP: ENH: add 'outputCoeffs' and 'extendedOutput' options to forceCoeffsENH: add 'extendedOutput' option that allows to output all constitutents
of all force coefficients, i.e. total, pressure, viscous, and porous
ENH: add 'outputCoeffs' option to allow to select coefficients to output
...ENH: add 'extendedOutput' option that allows to output all constitutents
of all force coefficients, i.e. total, pressure, viscous, and porous
ENH: add 'outputCoeffs' option to allow to select coefficients to output
ENH: remove redundant computations for porosity constituent when the option
porosity=false
DOC: improve header file and function declaration docs
BAKW: test backward compatibility and functionality in comparison to
v1906 by using `simpleFoam/motorBike` and `simpleFoam/bump2D`.
Tests have involved:
- Serial runs
- Parallel runs
- Serial restart
- Parallel restart
- Only binData = on (parallel)
- Only writeFields = on (parallel)
- Only extendedOutput = on (parallel)
- binData and extendedOutput = on (parallel)
- writeFields and extendedOutput = on (parallel)
- outputCoeffs and extendedOutput = on for arbitrarily chosen
(Cd CmRoll Cl) (parallel and serial)v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/322BUG: continuation of updateMethods with empty activeDesignVariables (#1540)2020-01-03T09:43:15ZVaggelis PapoutsisBUG: continuation of updateMethods with empty activeDesignVariables (#1540)When activeDesignVariables are not set explicitly, all design variables
are treated as active. These were allocated properly when starting from
0 but not when starting from an intermediate optimisation cycle
(e.g. running 5 optimisation ...When activeDesignVariables are not set explicitly, all design variables
are treated as active. These were allocated properly when starting from
0 but not when starting from an intermediate optimisation cycle
(e.g. running 5 optimisation cycles, stopping and restarting).
TUT: added a new tutorial including the restart of an optimisation run
to help identify future regressionAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/321BUG: writeMorpherCPs expects a controlBoxes entry (#1538)2020-01-03T09:43:42ZVaggelis PapoutsisBUG: writeMorpherCPs expects a controlBoxes entry (#1538)The *controlBoxes* wordList was removed from NURBS3DVolume in the
pre-release phase but *writeMorpherCPs* was not updated accordingly.
TUT: added the invocation of *writeMorpherCPs* in one of the tutorials to
help identify future re...The *controlBoxes* wordList was removed from NURBS3DVolume in the
pre-release phase but *writeMorpherCPs* was not updated accordingly.
TUT: added the invocation of *writeMorpherCPs* in one of the tutorials to
help identify future regressionAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/320BUG: Wrong FatalIOError message in displacementMethod and optMeshMovement (#1...2020-01-03T09:44:03ZVaggelis PapoutsisBUG: Wrong FatalIOError message in displacementMethod and optMeshMovement (#1537)- The core of the FatalIOError message was not printed due to exiting
with FatalError instead of FatalIOError
- Changed the TypeName in all derived classes of displacementMethod so
that the toc printed by the FatalIOError correspo...- The core of the FatalIOError message was not printed due to exiting
with FatalError instead of FatalIOError
- Changed the TypeName in all derived classes of displacementMethod so
that the toc printed by the FatalIOError corresponds to what the user
should add in dynamicMeshDictAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/319DEFEATURE: deprecate v2f model in favour of kEpsilonPhitF2020-01-03T09:41:19ZKutalmış BerçinDEFEATURE: deprecate v2f model in favour of kEpsilonPhitF- kEpsilonPhitF is a kEpsilon-based model which originated
from (Durbin, 1995)’s v2-f methodology. However, the majority of
v2-f model variants proved to be numerically stiff for segregated
solution algorithms due to the coup...- kEpsilonPhitF is a kEpsilon-based model which originated
from (Durbin, 1995)’s v2-f methodology. However, the majority of
v2-f model variants proved to be numerically stiff for segregated
solution algorithms due to the coupled formulations of v2 and f fields,
particularly on wall boundaries.
The v2-f variant (i.e. OpenFOAM’s v2f model) due to
(Lien and Kalitzin, 2001) reformulated the original v2-f model to enable
segregated computations; however, a number of shortcomings regarding
the model fidelity were reported in the literature.
To overcome the shortcomings of the v2-f methodology, the v2-f approach
was re-evaluated by (Laurence et al., 2005) by transforming v2 scale into
its equivalent non-dimensional form, i.e. phit, to reduce the numerical
stiffness.
This variant, i.e. kEpsilonPhitF, is believed to provide numerical
robustness, and insensitivity to grid anomalies while retaining the
theoretical model fidelity of the original v2-f model.
Accordingly the v2f RANS model is deprecated in favour of the variant
kEpsilonPhitF model.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/318ENH: improve BinSum container, and Test-BinSum app2020-01-17T21:07:16ZKutalmış BerçinENH: improve BinSum container, and Test-BinSum app```
BUG: protect against non-scalar or non-sum template specialisations
DOC: improve header/func docs
ENH: test Binsum constructors and member funcs
``````
BUG: protect against non-scalar or non-sum template specialisations
DOC: improve header/func docs
ENH: test Binsum constructors and member funcs
```v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/317Feature ihc wavemodels2019-12-18T13:59:42ZAndrew HeatherFeature ihc wavemodelsUpdated `waveMaker` boundary conditions for v1912 release - now possible to supply paddle information to generate 3-D waves.
Contribution from @barjasg at IH Cantabria; integration by OpenCFDUpdated `waveMaker` boundary conditions for v1912 release - now possible to supply paddle information to generate 3-D waves.
Contribution from @barjasg at IH Cantabria; integration by OpenCFDv1912Andrew HeatherAndrew Heather