SUBMODULE: 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 @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 submodule

changed milestone to %v2006

added Ready contribution integration: third party library labels

Compiles OK, but noticed that there are host of various 2-phase/multi-phase models (eg, TomiyamaSwarm) that might be

• duplicates of existing files within OpenFOAM
• lightly modified versions of the same
• new implementations
• time to restructure code (again)?

Could @Sergio please also take a look and see if there is anything to refactor here, or potential collisions?

marked as a Work In Progress

changed the description

After a 'very' quick look, this quadrature model is based on a quadrature moment approach (QMOM) while the one implemented in org is multiple size group model.

Both are used to get the bubble diameter balance on a two phase flow. They share many sub-models as per break up, coalescence, growing, etc. So there is some duplication on the sub-models for both of these methods.

Then, the in solver/velocityDistributionTransport, the interfacialModels has duplication on all the from org and ours.

Again, don't know why, the same models are duplicated in /applications/solvers/multiphase/interfacialModels/ (This does not look nice)

Ideally we want to bring this quadrature model in line to our branch and be able to use in the Euler-solvers. And check which of the solver in the sub-module are worth to integrate.

S

unmarked as a Work In Progress

added 17 commits

• 447ca941...42c8bbf6 - 16 commits from branch develop
• 54f80980 - SUBMODULE: added OpenQBMM submodule - see #1522 (closed)

Compare with previous version

merged

mentioned in commit a48d258a

Hi @Sergio,

there are a few reasons why we duplicated the interfacialModels a few times, which I know is not ideal, but it was convenient when developing (also to be shielded by upstream changes, with reactingEuler being in a development flux). The main technical reasons are the following:

1. The code in solver/velocityDistributionTransport uses a different form of the momentum exchange functions. In this quadrature approach, each cell has multiple velocity vectors (one per each quadrature node) to describe the local velocity distribution. The drag, virtual mass, wall-lubrication models etc. depend on the node velocities too.

2. The polydisperseBubbleFoam and the denseAGFoam solvers use the interfacialModel folder in /applications/solvers/multiphase/interfacialModels/. The key difference is that in polydisperseBubbleFoam we use a difference phaseModel "polyDispersePhaseModel" (in /applications/multiphase/twoPhaseSystem/phaseModels/polydispersePhaseModel) because this solver solves for the mean velocity as in a two-fluid model, then uses quadrature methods to evaluate the velocity of each bubble size. However, some cleanup here should be possible, at least to try to reduce duplication within OpenQBMM (I will take a better look at this).

3. Coalescence and breakup models are implemented to reuse the code in populationBalanceModel /src/quadratureMethods/populationBalanceModels to leverage of the machinery for moment advection, realizable ODE solver etc., so they are inherently incompatible with what done in reactingEulerFoam at this point.

For what concerns using quadrature methods in the Euler solvers, that would take a number of changes in the structure of reactingEulerFoam, which is now specialized towards one type of method (and implements kinetic theory and turbulence in the same stack, which is incorrect). I can give more details on what would be needed, if we decide to go in this direction.

Hi @albertop ,

Thanks for this description, it is very helpful.

1. Should it be possible then, to use several instances of the same model for each velocity of the quadrature in each cell?.(ie. List Where each model is similar to the version used in the no-quadrature approach?

2. ok

3. I'll have a mode detailed look

At this moment, we are starting to get some interest on Euler-Euler solvers from different people and multiphase in particular. I am trying to get an overall picture through the different contributors and what we got so far and be more active on this field. You contribution and feedback is very welcome for the future on this.

Hi @Sergio ,

It should be possible to reduce code duplication, I think. In our code we have a different phaseModel (https://github.com/OpenQBMM/OpenQBMM/blob/master/applications/solvers/velocityDistributionTransport/phaseModel/vdfPhaseModel/vdfPhaseModel.C) which provides access to most of the quadrature data.

To give you an idea, when we do quadrature (I don't know how familiar you are with these methods, so I apologize in advance if I write things you know), we discretize the distribution of size and/or velocity (what we call abscissae). This discretization gives you a finite number of velocities (and/or sizes, if those are considered too) each with its own weight. Weights can be mass fractions, number densities, or volume fractions (the choice depends on how equations are written) of that "class" of particles with that velocity and/or size. So, when we compute the momentum exchange terms, both the weight (mass or volume fraction with that velocity) and the velocity are needed. To make it easier to access these quantities, we use the index of the nodes (pairs of weights and velocity, in our example). This would need to be modified/standardized to reuse the code, but I think it can be done. In the end, the force models have the same expression, so it is question of defining a common interface.

If you prefer to discuss the last point (Euler-Euler models) by e-mail, feel free to send me an email (apcfd@outlook.com). Mark has my work email too.