MRF working with reactingTwoPhaseEulerFoam but not with reactingMultiphaseEulerFoam
 

Dear Foamers,


I am trying to set up a case of three-phase turbulent flow in stirred tank using reactingEulerFoam. Now since I want to start simple and increase the complexity of the problem a step by step, I have made a test case with laminar flow using MRF approach with two phases, air and water.



The problem appears when I activate the MRF in the rotating zone. After some long testing I have figured out that the same case works with reactingTwoPhaseEulerFoam solver but not with reactingMultiphaseEulerFoam solver. Same BCs, thermophysical properties and interfacial models applied in both cases. The only difference between the two cases is the solver.


reactingTwoPhaseEulerFoam: runs the case and exits perfectly.
reactingMultiphaseEulerFoam: starts solving but the courant number increases every time-step. Basically, everything starts getting messed up. Air volume fraction increases and water volume fraction decreases (which is not supposed to happen, because there is no mass transfer). Wrong pressure and high pressure residual..etc.



I attached both cases below. If anyone with some expertise in these solvers can have a look and tell me if I am missing something, or if this is a bug in the rMEF solver, I would appreciate it a lot!

Hi Mazen,

have you made any progress on this? I am also facing serious stability issues when using MRF together with reactingMultiphaseEulerFoam in OF 6.0.

Which OF version are you using?

Andrea

Hello Andrea,

I'm glad to see other people interested in using MRF with rMEF solver!

Actually, I haven't done any remarkable progress on this issue yet. However, there is clearly a bug when using MRF with rMEF deep in the code. The team I am working with have a strategy of finding out where the bug exactly is before reporting it.

The issue becomes even worse when you turn on face momentum in fvSolution! I haven't been able until now to make a simulation run with MRF and face momentum in rMEF, whether the solution is conservative or not.

Another research group have reported that they have less issues when using partial elimination in fvSolution.

To answer your question, I have tested v6, v7, dev and even v1912 they all have the same issue.

Thanks for the quick reply!

That destroys my hope that moving to 7 would have miraculously fixed the issue :D

BTW I have also made some additional tests in OF-6 and the same case with the same settings works like a clockwork with reactingTwoPhase but fails miserably in reactingMultiphase. The behaviour I am observing in the latter is very similar to what you have described: the velocity within the MRF region keeps increasing with time to unphysical values and so, of course, does the Courant number.

Please keep my posted if you make any progress on this, I'll do the same ;)

Andrea

Out of curiosity, are you testing on 3D or 2D case? Because when you set g = 0, the solver seems to deliver conservative solution. However, I still have no way of solution validation.

Also are you using face or cell momentum?

I will definitely keep you posted, thanks!

My domain is 3D and includes gravity. I have also run a very basic test in 2D with reactingMultiphase and MRF and everything seems to work there.

I have tested both face and cell-centred formulations for the momentum equation, none of them are working and I did not notice any significant difference between the two. Will try and have a go with partial-elimination.

Good luck!
Andrea

Just to add that partial elimination slows down the velocity divergence process, but does not fix it.

There were issues with the implementation of MRF in rMEF. A smart guy in our group worked on fixing these bugs. Until now the bug fixes look good, they work on 2D and 3D cases, and provide reasonable results.


If things go well, the bug fix will be communicated with OpenFOAM Foundation. If they accept it, you will be able to see it soon in the commits of OpenFoam-dev. You can then clone their repository, compile it and run your cases.


Kind regards,

Hi,

many thanks for the update and good job on finding the bug! Any chance you could share here what the bug was and ideally how your very smart colleague fixed it?

Cheers,
Andrea

Hi Andrea,


you can see the changes made to the code in OpenFOAM dev release, as it's already been adopted.



https://github.com/OpenFOAM/OpenFOAM...8676a78f7a8f20


Hope it can help you run your case!


Kind regards,
Mazen

Great, thank you Mazen!