-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle the negative growth rate and limited abscissa #188
Comments
Thank you for reporting, @xinzhenQin In general, negative growth is not supported out of the box. It requires removing the quadrature abscissae that approach zero and using the remaining nodes only, which was not implemented in the current algorithm. I marked this part as a feature request. I will investigate the second part, concerning positive growth and let you know.
|
I confirm the problem: when setting a maximum value for the abscissa, the source term becomes zero, as expected once such value is reached. In the case of pure growth, this leads to no change in the moments, which causes the ODE solver to loop indefinitely. I tested a correctio against the pureGrowth case with maxAbscissa set to a sufficiently small value to trigger the situation, and it now runs. Cases for pbeFoam are also correctly executed and validated. See commit 63c6677, which works with OpenFOAM v2212. Managing negative growth will take some more time. |
Thank you very much for your quick response!But I still wonder if I can make the corresponding changes in the QBMM version corresponding to of2016. |
Yes, you could make that change: see line 321 and following here: 63c6677. |
Thanks, I have run successfully on of2106 against the modified version. Thank you very much for your work. But I also found that sometimes the ODE solver reports problems that are not guaranteed to be stable. |
Could you please provide more details on the issues you have found? If you could point to a small case to reproduce them, it would be great (also, not that for negative growth, I have not pushed a solution yet, and how the problem is addressed depends on if QMOM or EQMOM is used. In the first case, you would remove quadrature nodes when the abscissa is null, in the second case the strategy in the paper from Nguyen et al. (2016) can be used). |
Ok, I'll put together a description of the problem and send it up here later today @AlbertoPa |
I'm sorry, I think I'm having some architectural issues. For example, I couple the univariate populationBlanceModel with a solver, but the information of each order moiments such as volScalarField--"momnet.o.populationBalance" are stored under the univariatePDFTransportModel class. Since the populationBlanceModel class does not contain this information, I cannot obtain this field information through populationBlanceModel object created in my solver. I think if this problem can be solved, QBMM can be better coupled with CFD! |
@xinzhenQin this is not the case. Fields of moments and nodes are accessible via the OpenFOAM database. Once the simulation is running, you can retrieve them as normally done with any field. Both are contained in the quadratureApproximation object, so retrieve the population balance model object as shown here then retrieve the quadratureApproximation object, and from there you have access to all the data you need. Access functions available from the quadratureApproximation object can be seen here: https://github.com/OpenQBMM/OpenQBMM/blob/master/src/quadratureMethods/quadratureApproximations/quadratureApproximationI.H In general, OpenQBMM heavily relies on OpenFOAM structures and facilities to avoid duplicating code and simplify maintenance, so what can be done in an OpenFOAM application in terms of data access is typically doable with OpenQBMM classes. I would suggest you take some time to explore the code if you plan to use OpenQBMM and couple it to custom solvers. |
thank you very much @AlbertoPa |
Currently, populationBalanceModel is just a wrapper class (not really aware of what quadrature type the actual pbe is going to use) to allow the runtime selection of different types of population balance models. However, the actual calculations happen in the univariatePDFTransportModel and in the specialized version of it univariatePopulationBalanceModel. The logic is that the PDFTransportModel is associated to a quadratureApproximation, consequently it returns the corresponding quadrature and moments. |
Thank you for your work!@AlbertoPa |
Since we can't currently handle the problem of abscissa less than 0 caused by negative growth rates, I chose to add a minAvscissa to avoid abscissa less than 0. When I set up a pure growth study as follows, a new error was raised:
--> FOAM FATAL ERROR: (openfoam-2106)
FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) at ??:? |
You cannot simply bind the abscissa so it does not become negative if you have a negative growth term. The zero-order moment at some point will become inconsistent with the other moments, which changed due to negative growth, while m0 did not. In QMOM, you must take care of removing the quadrature nodes whose abscissa is exactly zero. In EQMOM you can implement the approach discussed in: T.T. Nguyen, F. Laurent, R.O. Fox, M. Massot, Solution of population balance equations in applications with fine particles: Mathematical modeling and numerical schemes, Journal of Computational Physics. 325 (2016) 129–156. https://doi.org/10.1016/j.jcp.2016.08.017. which refers to: M. Massot, F. Laurent, D. Kah, S. De Chaisemartin, A Robust Moment Method for Evaluation of the Disappearance Rate of Evaporating Sprays*, SIAM Journal on Applied Mathematics. 70 (2010) 3203–3234. |
I based on OF 2106 and chose the corresponding version of QBMM.
First of all, when calculating particle growth, I found that when the growth rate is negative, there is a problem in calculating ODE.
Second, for a positive growth rate, when maxAbscissa is set, the ODE solver will be stuck near maxAbscissa. Even the pureGrowth calculation example that comes with pbeFoam has this problem
The text was updated successfully, but these errors were encountered: