
Community
Network
Announcements
Hello,
a few changes happened to the project in these months:
- The code twoPhaseEulerPimpleFoam has a new name, in order to be more clear with the developments that went on, and to be compliant with OpenCFD® trademark guidelines. In short, twoPhaseEulerPimpleFoam is renamed fluidParticleTwoPhase4Foam (read it "fluidParticleTwoPhaseForFoam").
The new name brings with it a specialization of the algorithm, which has been cleaned up and optimized to deal with dense fluid-particle flows.
Currently gasParticleTwoFluid4Foam is in "almost maintenance mode", meaning that its development is complete. Some additional validation against experimental data is being done, and passed verification tests, where we compared with others code results published in the literature, were passed successfully. After publication of a paper, the code will be released under the GPL3 in my git repository.
- The extension to n-phases is progressing, giving origin to what will be fluidParticleMultiPhase4Foam. The development follows what done in fluidParticleTwoPhase4Foam, with the same specialized algorithm, but generalized to n phases. Currently phase models, drag models and a part of the kinetic theory models have been extended.
The implementation of turbulence models, heat and mass transfer is postponed to after the completion of the n-phase code.
Best,
Alberto
Discussions
- twoPhaseEulerPimpleFoam on Friday, 08 October 2010 11:03
- First results.... on Saturday, 20 November 2010 07:14
- Multiphase Turbulence on Wednesday, 20 October 2010 13:21
Wall
Hi Laurence,
It is great that you intend to publish your work! The turbulence modelling is definitely something that requires attention.
I agree with you that the layout of the site is somewhat confusing, but perhaps a better place for this kind of discussion is on the working groups own forum? (Link in the group information)
Hi Laurence,
thanks for the comment! First of all, do not feel pressured to released anything until your work has been published (be very careful on this point). This said, thanks for the offer :-)
I am doing deep surgery on the code to remove the phase-intensive form for my applications (gas-particle flow), so the structure of the "n-phase" code is going to change quite a bit, especially to manage the granular phases.
At this point I am not sure if it is worth keeping a general Euler-Euler code, or if it is convenient to specialize it, meaning one for gas-liquid systems and one for gas-solid systems. I guess we'll see when these things are done.
My actual current task is to implement CQMOM (yes, C, not D :-)) in OF to be able to solve kinetic equations, so I am busy too. As you see I proceed in very small steps with tasks...
About the version of OpenFOAM® I use, I choosed 1.7.x from OpenCFD® myself, since I do not need the -extend features at the moment, so there is no problem.
Best,
Alberto
Well I better publish something soon anyway ;D Results aren't exactly ground-breaking but I think they're interesting enough.
I think you may be right, fluid/fluid fluid/solid systems will probably need their own solvers (but share similar libraries). Some way off at the moment though.
Good luck with the conditional method.
Great work on publishing the twoPhaseEulerPimpleFoam!
I haven't tested your solver, but couple of things I noticed:
1. Why co you store the alpha.storePrevIter() in the beginning of the timestep when the alpha is relaxed with alphaEqn.relax()?
2. So in your experience, the PIMPLE + underrelaxation solves the packing limit issues satisfactorily without any other trickery? (At least I didn't notice any other tricks.)
3. Should we move this discussion to the user group forum?
Hi Juho, thanks!
1) I store alpha at the beginning of the outer corrector loop, not at the beginning of the time step.
2) It seems to work fine in many cases, as long as your time step is not extremely large. What has a very important role in stabilizing the computation is the alpha-U-p coupling: if you ensure simultaneous convergence of these equations, you are in a good position to have a robust algorithm. That's why I feel PIMPLE (or unsteady SIMPLE) are a better alternative to PISO when the particle pressure term is introduced, since it really changes too quickly to have an acceptable time-step and, at the same time, a strict enforcement of the maximum packing limit.
Notice that in the released code nothing has been changed in the kinetic theory / frictional stress models. To further stabilize the solution, I did something similar to what done in MFIX (and if I remember correctly, in your thesis too): it is possible to either write the radial distribution function g0 as a power series around the packing limit, or replacing it with a continuous expression for the particle pressure taken from the frictional models.
However, if you run the second test case, you will notice that even without these changes, the solution is stable.
The remaining problem is that the interface between zones with particles and zones without particles is altered if the particle pressure is strong there. I did not find a solution to make this work correctly with the phase-intensive form of the momentum equation, while it seems to be fixed using the conservative form.
3) Yes, we can move it there :-)
Best,
Alberto
Can you see the whole project, with tasks and such?
Best,
Alberto
Yes, I can see the project and the tasks. Also, I created a thread on the discussion forum for the twoPhaseEulerPimpleFoam.
Hi Holger, yes I set it up before answering to your question, and I am still exploring the features -extend offers to decide how to organize the work. At the moment I use a local git repository (and SVN makes me itch ;-P), so I have to figure out how to manage things.
Let me take advantage of your question to give an idea of my plan for the first stages of the project, concerning the development and stabilization of the two-phase solver.
The first steps will be to release a a slightly modified version of twoPhaseEulerFoam, based on the PIMPLE algorithm instead than on the PISO algorithm. Additionally, I added an option to explicitly solve the momentum predictor, instead than simply performing a Jacobi iteration. The time-line for this is very short (I think a couple of weeks, given my schedule). I only have to clean the code, and make it public, since it is a relatively simple modification of the existing solver.
As I'll show you, the code is stable, however it does not always behave correctly in some case, where dense granular phases are present and define sharp interfaces.
I have been working on this problem for quite some time, initially for personal interest, and recently because there are some aspects in common with my current research on high-order moment methods for gas-particle flows.
The code has been further modified so to implement:
- the conservative form of the momentum equation
- the partial elimination algorithm
- a slightly modified pseudo-staggered algorithm, which seems to be more robust when phase separation occurs, and sharp local gradients of the phase fraction are present
- a more robust implementation of the particle pressure term when the kinetic theory model is used
- additional sub-models for the kinetic theory framework
At the moment I do not have a time-line for the release of these parts of the code, which will be progressive.
All these features have been implemented and relatively tested, however some need a bit more testing and cleanup, and others are related to works that have to be published.
Best,
Alberto
Hi Alberto, please transfer that into the discussion board providing better possibilities to discuss... P.S.: I think we can share some tasks to interested members!
Yes, we can. I think the project is open now... at least I tried to achieve that :-)
Best,
Alberto
Did you know...
Online Users
Your Profile
Please login to seeyour Profile. Thanks!
Job Tags
Top Members
- Points: 128
- Points: 112
- Points: 96
- Points: 71
- Points: 66
Statistics






