[ansubru]

Hey foamers!!

I am a fledgling in this new community. However, thanks to this forum I have been able to pick up the basics of openfoam rather quickly.

I have been trying to simulate "Specific gravity aided separation of grains" on a vibrating table. I have just began my work and started with setting up a very simple case of a fluidized system i.e a rectangular box being filled with spherical grains from the top and fluidized slightly from the bottom (quite similar to the Goldschmidt tutorial case).

I am encountering this very persistent issue. When i inject about 500 particles into the domain, the simulation proceeds flawlessly towards completion. However, when i decide to inject 5000 particles (not parcels) into the same system (no changes in the set up) the simulation crashes after the first time step.. with the following error ..

 Solving 3-D cloud kinematicCloud
    509 move-collide subCycles
[2] #0  Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OSspecific/POSIX/printStack.C:221
[2] #1  Foam::sigFpe::sigHandler(int) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OSspecific/POSIX/signals/sigFpe.C:108
[2] #2   in "/lib/x86_64-linux-gnu/libc.so.6"
[2] #3  Foam::divideOp3<double, double, double>::operator()(double const&, double const&) const at ~/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/ops.H:167
[2] #4  void VectorSpaceOps<3, 0>::opVS<Foam::Vector<double>, Foam::VectorSpace<Foam::Vector<double>, double, 3>, double, Foam::divideOp3<double, double, double> >(Foam::Vector<double>&, Foam::VectorSpace<Foam::Vector<double>, double, 3> const&, double const&, Foam::divideOp3<double, double, double>) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/VectorSpaceM.H:34
[2] #5  Foam::Vector<double> Foam::operator/<Foam::Vector<double>, double, 3>(Foam::VectorSpace<Foam::Vector<double>, double, 3> const&, double) at ~/OpenFOAM/OpenFOAM-2.3.0/src/OpenFOAM/lnInclude/VectorSpaceI.H:587
[2] #6  Foam::PairCollision<Foam::CollidingCloud<Foam::KinematicCloud<Foam::Cloud<Foam::CollidingParcel<Foam::KinematicParcel<Foam::particle> > > > > >::wallInteraction() at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/PairCollision.C:249
[2] #7  Foam::PairCollision<Foam::CollidingCloud<Foam::KinematicCloud<Foam::Cloud<Foam::CollidingParcel<Foam::KinematicParcel<Foam::particle> > > > > >::collide() at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/PairCollision.C:671
[2] #8  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/CollidingCloud.C:66
[2] #9  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/CollidingCloud.C:224
[2] #10  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/KinematicCloud.C:204
[2] #11  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/KinematicCloud.C:112
[2] #12  
[2]  at ~/OpenFOAM/OpenFOAM-2.3.0/src/lagrangian/intermediate/lnInclude/CollidingCloud.C:197
[2] #13  
[2]  at ~/OpenFOAM/ask-2.3.0/Solvers/DPMFoam_mod/DPMFoam_mod.C:85
[2] #14  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
[2] #15  
[2]  in "/home/ask/OpenFOAM/ask-2.3.0/platforms/linux64GccDPDebug/bin/DPMFoam_mod"
[ask-HP-Z230-Tower-Workstation:19297] *** Process received signal ***
[ask-HP-Z230-Tower-Workstation:19297] Signal: Floating point exception (8)
[ask-HP-Z230-Tower-Workstation:19297] Signal code:  (-6)
[ask-HP-Z230-Tower-Workstation:19297] Failing at address: 0x3e800004b61
[ask-HP-Z230-Tower-Workstation:19297] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7f38a88d94a0]
[ask-HP-Z230-Tower-Workstation:19297] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f38a88d9425]
[ask-HP-Z230-Tower-Workstation:19297] [ 2] /home/ask/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPDebug/lib/libOpenFOAM.so(_ZN4Foam6sigFpe10sigHandlerEi+0xbc) [0x7f38a9d9f7d0]
[ask-HP-Z230-Tower-Workstation:19297] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7f38a88d94a0]
[ask-HP-Z230-Tower-Workstation:19297] [ 4] DPMFoam_mod(_ZNK4Foam9divideOp3IdddEclERKdS3_+0x20) [0x4c25d4]
[ask-HP-Z230-Tower-Workstation:19297] [ 5] DPMFoam_mod(_ZN14VectorSpaceOpsILi3ELi0EE4opVSIN4Foam6VectorIdEENS2_11VectorSpaceIS4_dLi3EEEdNS2_9divideOp3IdddEEEEvRT_RKT0_RKT1_T2_+0x29) [0x4aba77]
[ask-HP-Z230-Tower-Workstation:19297] [ 6] DPMFoam_mod(_ZN4FoamdvINS_6VectorIdEEdLi3EEET_RKNS_11VectorSpaceIS3_T0_XT1_EEEd+0x3c) [0x49cc25]
[ask-HP-Z230-Tower-Workstation:19297] [ 7] /home/ask/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPDebug/lib/liblagrangianIntermediate.so(_ZN4Foam13PairCollisionINS_14CollidingCloudINS_14KinematicCloudINS_5CloudINS_15CollidingParcelINS_15KinematicParcelINS_8particleEEEEEEEEEEEE15wallInteractionEv+0x3f6) [0x7f38ace7bea4]
[ask-HP-Z230-Tower-Workstation:19297] [ 8] /home/ask/OpenFOAM/OpenFOAM-2.3.0/platforms/linux64GccDPDebug/lib/liblagrangianIntermediate.so(_ZN4Foam13PairCollisionINS_14CollidingCloudINS_14KinematicCloudINS_5CloudINS_15CollidingParcelINS_15KinematicParcelINS_8particleEEEEEEEEEEEE7collideEv+0x30) [0x7f38ace6b44a]
[ask-HP-Z230-Tower-Workstation:19297] [ 9] DPMFoam_mod() [0x4f6996]
[ask-HP-Z230-Tower-Workstation:19297] [10] DPMFoam_mod() [0x4e1b31]
[ask-HP-Z230-Tower-Workstation:19297] [11] DPMFoam_mod() [0x4cc6b1]
[ask-HP-Z230-Tower-Workstation:19297] [12] DPMFoam_mod() [0x4b6d84]
[ask-HP-Z230-Tower-Workstation:19297] [13] DPMFoam_mod() [0x4a383e]
[ask-HP-Z230-Tower-Workstation:19297] [14] DPMFoam_mod() [0x493a3d]
[ask-HP-Z230-Tower-Workstation:19297] [15] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f38a88c476d]
[ask-HP-Z230-Tower-Workstation:19297] [16] DPMFoam_mod() [0x4921e9]
[ask-HP-Z230-Tower-Workstation:19297] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 2 with PID 19297 on node ask-HP-Z230-Tower-Workstation exited on signal 8 (Floating point exception).

You can notice that I have parallelized my simulation. I can clearly see that the crash is because DPMFoam is not able to handle this load of particles in my specified geometry.

Is there any manner in which I could get this simulation up and running. Have I missed something critical in my initial set up that leads to the solvers inadequacy to handle 5000 particles (which is not a large number by any means)???

Any help would be greatly appreciated.

Regards

ansubru

[ansubru]

Well.. I have solved the issue myself.. I guess.. I realized that some of the model parameters I employed.. modulus of elasticity etc were wrongly defined (wrong values).. hence some of the intermediate parameters estimated were wrongly estimated close to a null value leading to the crash.. Phew!! I think I solved that one....

I am still open for ideas.. If someone feels my deduction is wrong..

[maysmech]

Hi all,

I have two questions about DPMFoam:

1- Where is the tangential restitution coefficient? I didn't find it in case/constant/kinematicCloudProperties.

2- Is it possible to define two type particles with different density and/or diameter?

Regards,

[ansubru]

Hi Maysam!!

Its nice to see another person working with DPMFoam, this solver has a very poor user base.

To answer your questions,

1- Where is the tangential restitution coefficient? I didn't find it in case/constant/kinematicCloudProperties.

From my understanding, the DPMFoam solver uses only one friction factor and that is what you could call as "standard surface friction factor or normal friction factor'. The tangential friction factor is mainly used to simulate cases of rolling which i believe the DPMFoam solver does not do. The primary assumption on the particles is 'no rolling' and the particle positions are estimated wrt to sticking and sliding conditions alone. In most applications this assumptions is quite valid and the results are not that heavily impacted if you include rolling. Nevertheless ,if you want to do cases with rolling, i would recommend you to use LIGGGHTS, its another opensource software only for DEM cases, quite easy to install and it is coupled with openfoam.
http://www.cfdem.com/liggghts-open-s...imulation-code

2- Is it possible to define two type particles with different density and/or diameter?

Yes it is possible. I use particles with different sizes in my cases. You need to initialize them in your case/constant/kinematicCloudProperties. I use the following initialization to have a random sampling of 2 particle sizes (50% of each size in the total number injected) with an error of 0.00015 m.

model1
        {
            type            patchInjection;
            parcelBasisType fixed;
            patchName       inlet;
            U0              (0 0 -1.5);
            nParticle       1;
            parcelsPerSecond  20000000;
            
            sizeDistribution
	    {
	    
            type        multiNormal;
                multiNormalDistribution
                {
                    minValue 0.0005 ;
		    maxValue 0.00255 ;
		    expectation  
                     
                       (0.001 0.0025)
                     ;

                   variance 
                     
                       (0.0001 0.0001)
                     ;

		  strength 
                     
                       (0.5 0.5)
                     ;
                  
                }
	}

            flowRateProfile constant 1;
            massTotal       2000000;
            SOI             0;
            duration        0.00001;  
            
        }
    }

I am working on modifying the DPMFoam solver so that it can handle dynamic meshes. I am not too adept at programming but I have generated some scripts. If you have any ideas on the same could you share them with me??

Regards
ansubru

[maysmech]

Thanks a lot Ananda,
I am happy too seeing a person working on DPM. I am almost new with Lagrangian in OpenFOAM. I worked with pisoFoam solver before. Because I didn't need moving Mesh in my previous works I don't have any idea about coupling dynamic mesh and DPM now.
I want use DPMFoam in simulating dense fluidized beds and spouted beds. Now I want see if it is validated or not. Did you have any validation for assurance results of DPMFoam in fluidized beds test cases? Do you think it is a good choice?
About two particle types: How can I have it in Godschemidt test case? I mean I want use case/constant/kinematicCloudPositions file and positioning two type particles in desired coordinates, not injecting them?
Regards,

[ansubru]

Hi again!!

Now I want see if it is validated or not. Did you have any validation for assurance results of DPMFoam in fluidized beds test cases?

I am not very aware of many validation cases, but I believe that it has been validated for the goldschmidt fuidized bed cases. This is something I am looking into as well. I am trying to validate the solver (more a qualitative assessment) for my application which is not so much a ' fluidized bed' but a vibrating table with air inlet (its for an industrial application in grain sorting).. At least by looking at my simulations I can see that most of the general trends are being captured (which is very good).. i am going to do a full scale validation quite soon.. But in my opinion it looks to be a very promising solver..

I want use case/constant/kinematicCloudPositions file and positioning two type particles in desired coordinates, not injecting them

The method is the same only 'patch injection' in my code will be replaced by the bit for injections using 'kinematicCloudPositions' (from the tutorial)

Just replace this bit in the tutorial 'sizeDistribution' initialization ..

 sizeDistribution
	    {
	    
            type        multiNormal;
                multiNormalDistribution
                {
                    minValue 0.0005 ;
		    maxValue 0.00255 ;
		    expectation  
                     
                       (0.001 0.0025)
                     ;

                   variance 
                     
                       (0.0001 0.0001)
                     ;

		  strength 
                     
                       (0.5 0.5)
                     ;
                  
                }

A general suggestion, if you want a solver validated with several benchmark studies for DEM applications; you should look at LIGGGHTS.. I am currently looking into it as well..

BR

ansubru

[maysmech]

Thanks.
I am trying to do validation with other test cases. As you know, the Goldschemidt tutorial is qualitative, not quantitative.
I worked with LIGGGTS and CFDEM which seems good solver from JKU, but because of my previous knowledge about OpenFoam, I prefer it, yet.
about multi type particle: I want to have two type particles with fixed value of size, not with wide size distribution. for example 20,000 particles with diameter of 2 mm and 5,000 particles with diameter of 4 mm. I think your commands are related to size distribution, isn't it? for fixed value of one type the below command is good, Can it be revised for two particles with two fixed value size?

sizeDistribution
{
type fixedValue;
fixedValueDistribution
{
value 0.0025;
}
}

[ansubru]

Hi again!!

I want to have two type particles with fixed value of size, not with wide size distribution. for example 20,000 particles with diameter of 2 mm and 5,000 particles with diameter of 4 mm.

Its size distribution with very minimal variation.. In my case I have two particular sizes of particles 1 mm and 2.5 mm with a variation of 0.0001 m.. Its almost a fixed distribution (almost 1 mm and 2.5 mm as my expectation initialization) with a very narrow size range.. You should give it try.. if you want the strength (i.e 5000 and 20000) need to tweak it a bit...This works for me though.. ..

Do let me know about ur validation cases...

BR

ansubru

[maysmech]

It works but some questions arise:
1- TypeID and nParticle is 1 in parafoam postprocessing. Showing contour of "d" leads to mixture of two diameters in whole of the domain, randomly or one by one. How can we arrange desired configuration?, for example large particle in the bottom and small particles on the top of the bed, initially. For this purpose, I think we should revise the particleClousPositions by separating positions of each type. I don't know how is possible for desired initial mixture configuration. Do you know?

2- For binary particles differing in density I think we can define another TypeId like below but don't know how to define diameter of each type in sizeDistribution section, also in the kinematicCloudPositions file.

constantProperties
{
    parcelTypeId 1;

    rhoMin          1e-15;
    minParticleMass 1e-15;

    rho0            2526;
    youngsModulus   1e8;
    poissonsRatio   0.35;

    constantVolume  false;

    alphaMax        0.99;
}

[ansubru]

Well, I did not have the need to have fixed positions for a particular size so I have not investigated it.. Moreover, if you have to change how the kinematiccloud positions injects/places the particles you might have to tweak the code as you rightly pointed out.. i am sorry... I can be of very little assistance on this regard ... one suggestion could be (may work for you).. use two injections instead of one.. In that way define two kinematic position files (one for the top section and the other for the bottom one).. then use the fixed distribution for each.. you can have two type ID's and two different densities.. I think this could be a way forward??

BR

ansubru

[maysmech]

It was only for curiosity and I don't need it yet. I will work on it in my leisure time.
What is strength definition? I changed it from (0.5 0.5) to (1.5 0.5) and it worked without error, So it couldn't be volume fraction of two particles. Do you know if it is based on number, mass, volume, ...?
Regards,

[ansubru]

From my understanding, strength is based on number ..

[mehdi kamyabi]

Dear All
I'm new in applying CFD in coupling with DEM. So far I find three fine soft-wares for CFD-DEM applications and have some experiences with them: CFD-DEM coupling , DPMfoam in OpenFoam and Mfix. Now my question is what's the difference among them and which one is more powerful and valid? Specially which one has the tools for handling electrostatic forces and other non-contacting forces between particles?

Best Regards

[ansubru]

Hi mehdi!!
The softwares you have mentioned are all widely used for simulating several applications of granular and other dense multiphase flow. Each code has its own merits and de-merits and additionally ease of use as well. For instance, the OF code is not very straight forward to use, and will need a little acclimating time. Mfix and CFD-DEM coupling are a little more straight forward to use. The choice of course depends on the user, and the level of proficiency with CFD tools. If you are interested in including your own models then OF is definitely the most customizable, however mfix is not that far behind. The choice is of course entirely urs to make, remember your application and the degree of customizability you desire. If its a straight forward case study, where you need results quickly I would suggest CFD-DEm coupling and mfix.. If you want complete control of every relevant physics, then I would definitely recommend OF.

Hope this would help you

Regards

Ansubru

[mehdi kamyabi]

Hi Ananda,

I appreciate your valuable comments on my post. It was completely useful.

[vinayvm]

Originally Posted by ansubru

Hi mehdi!!
The softwares you have mentioned are all widely used for simulating several applications of granular and other dense multiphase flow. Each code has its own merits and de-merits and additionally ease of use as well. For instance, the OF code is not very straight forward to use, and will need a little acclimating time. Mfix and CFD-DEM coupling are a little more straight forward to use. The choice of course depends on the user, and the level of proficiency with CFD tools. If you are interested in including your own models then OF is definitely the most customizable, however mfix is not that far behind. The choice is of course entirely urs to make, remember your application and the degree of customizability you desire. If its a straight forward case study, where you need results quickly I would suggest CFD-DEm coupling and mfix.. If you want complete control of every relevant physics, then I would definitely recommend OF.

Hope this would help you

Regards

Ansubru

I agree with Ansubru. I think what is also important to mention, when you talk of which is more powerful, is the programming language used and your proficiency with them. All of these are great packages to start with. If your work involves substantial development, I will ask you to be careful. Be sure what suits you. MFIX uses FORTRAN while OF and CFDEM uses C++.

From my experience in using all three packages I found MFIX most easy to use. The code is very easy to read. While OF was most difficult to read. It makes heavy use of templates and has several layers of coding. For an inexperienced C++ user this can be very frustrating.

However, if you are not going to make heavy changes and just make use of features as is than you may choose only based on their resp features.

Hope that helps!

Vinay

[minzhang]

Originally Posted by ansubru

Hi mehdi!!
The softwares you have mentioned are all widely used for simulating several applications of granular and other dense multiphase flow. Each code has its own merits and de-merits and additionally ease of use as well. For instance, the OF code is not very straight forward to use, and will need a little acclimating time. Mfix and CFD-DEM coupling are a little more straight forward to use. The choice of course depends on the user, and the level of proficiency with CFD tools. If you are interested in including your own models then OF is definitely the most customizable, however mfix is not that far behind. The choice is of course entirely urs to make, remember your application and the degree of customizability you desire. If its a straight forward case study, where you need results quickly I would suggest CFD-DEm coupling and mfix.. If you want complete control of every relevant physics, then I would definitely recommend OF.

Hope this would help you

Regards

Ansubru

Hello Ansubru,

This is Min. I have been working on MPPICFoam for 3 months and I plan to use DPMFoam. I think you are an expert on DPMFoam. Could I ask several questions?

If we set nParticle=1 for DPMFoam, what is the difference between unresolved CFD-DEM and DPMFoam?

If we set nParticle>1 for DPMFoam, what is the difference between coarse-grained CFD-DEM and DPMFoam?

What is the difference between MPPICFoam and DPMFoam?

In addition, I am wondering whether you could have a look at my post about MPPICFoam when you have time.
Simulate particle/liquid flow in a converging geometry with MPPICFoam

Thank you so much!

[ansubru]

Hi Min!


Firstly, I am flattered that you think I am an 'expert' in DPMFoam (I personally dont think that is the case :P)..


To provide a quick answer to some of your questions -



1) I am no expert in MPPIC methods, infact I have never worked with that framework. A quick google gave me this --> *The heart of the MP-PIC method is in the use of the as yet undefined particle volume fraction in [21] and [26] to approximate advanced-time pressures and solids stresses*(Andrews and Rourke, International Journal of Multiphase flow (1994) https://doi.org/10.1016/0301-9322(95)00072-0). So I am guessing that you need to dig into how the particle stresses are estimated in the MPPIC src code. A good starting point is - "grep -r -i MPPIC .". That shell command run in the foam/src dir would give you all the relevant files that you could investigate.


2) If we set nParticle=1 for DPMFoam, what is the difference between unresolved CFD-DEM and DPMFoam?
This question I do not understand. What do you mean by unresolved CFD-DEM, are you referring to the boundary layers around the particle being unresolved? If so, then that is a feature of all CFD-DEM approaches, remember its a Lagrangian treatment for the particles which assumes point particle treatment (negligible size, but fixed mass)
If nparticle = 1, it means that one DEM particle represents one real particle, if nparticle = n it means you are looking at clusters of particles and if you have a really dense bed of several million particles, then this would be a reasonable assumption to predict some general trends of the particulate flow. In CFD-DEM you are coupling the fluid and the particle much like the MPPIC (its 4 way coupled), only that you solve for the individual particle positions (using Newtons 2nd law) and not a louville equation for the distribution of particle positions. So in some way this is deterministic!


3) What is the difference between MPPICFoam and DPMFoam?
The fundamental difference as I see is the governing equations being solved. CFD-DEM is a euler-lagrange treatment, where as MPPIC seems more like a continuum-meso scale approach where a Liouville equation is solved for the distribution function of particle positions, velocities and sizes. Due to this CFD-DEM is a bit more tractable as the equations you are solving are 'simpler' and the coupling between the phases (at least in DPMFoam) is semi-implicit (which is combination of explicit and implicit treatments): In essence for a simulation with a few 100000 particles CFD-DEM is much more tractable (particularly given the computing resources we have these days)


Hope I was able to clear some of your doubts.


Regards


Ananda

[minzhang]

Hi Ananda,

Thank you so much for your answer!

Originally Posted by ansubru

Firstly, I am flattered that you think I am an 'expert' in DPMFoam (I personally don't think that is the case :P)..

I am wondering whether you are still working on DPMFoam, or other similar methods.

Originally Posted by ansubru

1) I am no expert in MPPIC methods, in fact I have never worked with that framework. A quick google gave me this --> *The heart of the MP-PIC method is in the use of the as yet undefined particle volume fraction in [21] and [26] to approximate advanced-time pressures and solids stresses*(Andrews and Rourke, International Journal of Multiphase flow (1994) https://doi.org/10.1016/0301-9322(95)00072-0). So I am guessing that you need to dig into how the particle stresses are estimated in the MPPIC src code. A good starting point is - "grep -r -i MPPIC .". That shell command run in the foam/src dir would give you all the relevant files that you could investigate.

Thanks! I will look into that.


2) If we set nParticle=1 for DPMFoam, what is the difference between unresolved CFD-DEM and DPMFoam?

Originally Posted by ansubru

This question I do not understand. What do you mean by unresolved CFD-DEM, are you referring to the boundary layers around the particle being unresolved? If so, then that is a feature of all CFD-DEM approaches, remember its a Lagrangian treatment for the particles which assumes point particle treatment (negligible size, but fixed mass)

Compared with the "resolved" CFD-DEM (the fluid-solid coupling just arises from the solution), "unresolved" CFD-DEM means it utilizes drag (or other) force models/correlations for the solid-fluid coupling.

Another question, what do you mean by "point particle treatment (negligible size, but fixed mass)"? I think in CFD-DEM, the particles have the real size, yes?

My question is, what is the difference of the particle treatments between DPMFoam and CFD-DEM?

Originally Posted by ansubru

If nparticle = 1, it means that one DEM particle represents one real particle, if nparticle = n it means you are looking at clusters of particles and if you have a really dense bed of several million particles, then this would be a reasonable assumption to predict some general trends of the particulate flow.

Yes, you are correct!

Originally Posted by ansubru

In CFD-DEM you are coupling the fluid and the particle much like the MPPIC (its 4 way coupled), only that you solve for the individual particle positions (using Newtons 2nd law) and not a louville equation for the distribution of particle positions. So in some way this is deterministic!

How about DPMFoam, it is also a four-way coupling method, yes?
Since DPMFoam and MPPICFoam are utilizing a lot of same functions, they should be very similar, the only difference is the particle-particle interaction, yes?


3) What is the difference between MPPICFoam and DPMFoam?

Originally Posted by ansubru

The fundamental difference as I see is the governing equations being solved. CFD-DEM is a euler-lagrange treatment, where as MPPIC seems more like a continuum-meso scale approach where a Liouville equation is solved for the distribution function of particle positions, velocities and sizes.

So you mean, DPMFoam is CFD-DEM, yes?
A lot of CFD-DEM studies are based on OpenFOAM&LIGGGHTS&CFDEMcoupling, yes?
But DPMFoam is only a solver in OpenFOAM.
What is the difference?

Originally Posted by ansubru

Due to this CFD-DEM is a bit more tractable as the equations you are solving are 'simpler' and the coupling between the phases (at least in DPMFoam) is semi-implicit (which is combination of explicit and implicit treatments): In essence for a simulation with a few 100000 particles CFD-DEM is much more tractable (particularly given the computing resources we have these days)

Yes, I cannot agree with you more.
As far as I know, the equations of MPPICFoam are much more complex than CFD-DEM methods.

Could you give more details about the semi-implicit scheme?
So you mean, DPMFoam is CFD-DEM, yes?

Originally Posted by ansubru

Hope I was able to clear some of your doubts.

Absolutely! Thanks again for your detailed answers!


Best regards,
Min

[ansubru]

Compared with the "resolved" CFD-DEM (the fluid-solid coupling just arises from the solution), "unresolved" CFD-DEM means it utilizes drag (or other) force models/correlations for the solid-fluid coupling.

Ok, now I understand what you are saying. DPMFoam is an unresolved CFD-DEM, as the coupling is achieved by means of drag. You are not resolving the fluid stress tensor to actually calculate the force on the particle (for instance this is typically done in Immersed boundary methods).. So you rely on empirical correlations for the coupling

Another question, what do you mean by "point particle treatment (negligible size, but fixed mass)"? I think in CFD-DEM, the particles have the real size, yes?

What i mean is you don't resolve the boundary layer around the particle. In essence you just impose the drag as the coupling term at the center of mass for the particle. Which is the essence of Lagrangian methods where boundary layer effects are considered unimportant. So although they have a real size, in comparison to the domain size this can be negligent (meaning boundary layer around the particles are unimportant)

My question is, what is the difference of the particle treatments between DPMFoam and CFD-DEM?

I cannot comment on this, as I have not used the other codes, for instance EDEM etc. However, if i were to guess i would say they are the same. As you employ coupling between phases through drag.

How about DPMFoam, it is also a four-way coupling method, yes?
Since DPMFoam and MPPICFoam are utilizing a lot of same functions, they should be very similar, the only difference is the particle-particle interaction, yes?

Yes DPMFoam is 4 way coupled. You can use the soft sphere model to deal with particle-particle and particle-wall collisions.

So you mean, DPMFoam is CFD-DEM, yes?
A lot of CFD-DEM studies are based on OpenFOAM&LIGGGHTS&CFDEMcoupling, yes?
But DPMFoam is only a solver in OpenFOAM.
What is the difference?

DPMFoam does the same thing as OpenFOAM&LIGGGHTS&CFDEMcoupling. The only difference is that it was developed completely using the OpenFoam object oriented style ( so basically someone just combined the existing DEM implementation with the continuum CFD).

Could you give more details about the semi-implicit scheme?
So you mean, DPMFoam is CFD-DEM, yes?

Yes, DPMFoam is CFD-DEM. I dont want to blow my own trumpet (but i will do it anyway ), I have authored a paper in powder technology which identifies the basic parts of the framework and at the same time addresses how I set up a DPMFoam simulation --> https://www.chalmers.se/en/staff/Pages/ananda.aspx (have a look at this one https://doi.org/10.1016/j.powtec.2016.07.003 )

And to answer your first question, I do not work with DPMFoam anymore, but I am really interested to see how it has developed over the years. Currently I am dealing more with an Immersed boundary based DNS method to study gas-solid systems involving nanoparticles (rarefied flow of particulates in a micro-channels)

Regards

/Ananda