
[Sponsors] 
October 21, 2014, 14:03 

#1 
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 6 
I tested porousInterFoam and interFoam in an empty tube with exactly the same settings, but I got different results. From my understanding, they should behave the same when simulating an empty duct.
What is also interesting is interFoam takes "div((muEff*dev(T(grad(U)))))" while porousInterFoam uses "div((nuEff*dev(T(grad(U)))))". I am running OF222 Last edited by wyldckat; October 26, 2014 at 12:44. Reason: posted few minutes apart 

October 26, 2014, 12:49 

#2 
Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 9,558
Blog Entries: 39
Rep Power: 97 
Greetings yanxiang,
The difference in using "mu" and "nu" usually implies that one is using an incompressible model and the other uses compressible. Compare pimpleFoam with rhoPimpleFoam for a clearer idea on the differences and namely regarding which refers to compressible and which refers to incompressible . As for the results, the initial conditions might be the reason why you're getting such a big difference in results, since one handles fluid as incompressible and the other as compressible. If you provide the two cases, it will make it a lot easier to diagnose the specific reason why you're getting those results. Have a look at this blog post of mine, for more ideas: OpenFOAM: Interesting cases of bad meshes and bad initial conditions Best regards, Bruno 

October 27, 2014, 09:36 

#3 
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 6 
Dear Bruno,
Thanks for your reply. Indeed, "mu" and "nu" are usually used in the context of compressible and incompressible flows respectively. However, in my case, I use porousInterFoam, which should not be different from interFoam in that regard. Since it's simply an extension of the interFoam with the porous media model, I expect it reduces to the original interFoam when there is no resistance specified in the porosityProperties dictionary. I am, however, using a dangerous inlet boundary condition for the alpha1 field, which varies periodically with time. This could be the reason why it causes some numerical issues. I will test with a safer boundary condition and see whether they behave the same. Best, yanxiang 

November 1, 2014, 16:18 

#4 
Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 9,558
Blog Entries: 39
Rep Power: 97 
Hi yanxiang,
I took a better look at the cases and solvers in OpenFOAM 2.2.2 and I'm not finding any references to "nuEff" in the tutorials related to porousInterFoam and not even for most of the multiphase tutorials! And I took a look at the source code for this solver and the line that does use "div(muEff)" is commented out, which means that not even that is being used. Nonetheless, "muEff" is indeed used for this solver: https://github.com/OpenFOAM/OpenFOAM...terFoam/UEqn.H Perhaps you're mixing your tests with tutorial cases from past OpenFOAM versions? Best regards, Bruno
__________________


November 4, 2014, 14:34 

#5 
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 6 
Hi Bruno,
I double checked the two cases, and porousInterFoam doesn't use div(muEff) nor div(nuEff). So no numerical scheme needs to be specified for that. I also looked into the source code a bit more carefully and noticed that the implementation of UEqn in porousInterFoam is different from that in interFoam not only in the addition of the resistance, but also in the following lines: interFoam: Code:
fvVectorMatrix UEqn ( fvm::ddt(rho, U) + fvm::div(rhoPhi, U) + turbulence>divDevRhoReff(rho, U) ); Code:
fvVectorMatrix UEqn ( //pZones.ddt(rho, U) fvm::ddt(rho, U) + fvm::div(rhoPhi, U)  fvm::laplacian(muEff, U)  (fvc::grad(U) & fvc::grad(muEff)) // fvc::div(muEff*(fvc::interpolate(dev(fvc::grad(U))) & mesh.Sf())) == fvOptions(rho, U) ); Thanks, yanxiang 

November 4, 2014, 15:50 

#6 
Senior Member
Alexey Matveichev
Join Date: Aug 2011
Location: Nancy, France
Posts: 1,410
Rep Power: 25 
Hi,
if you take a look at the implementation of turbulence>divDevRhoReff(rho, U) (for example in kEpsilon.H): Code:
tmp<fvVectorMatrix> kEpsilon::divDevRhoReff ( const volScalarField& rho, volVectorField& U ) const { volScalarField muEff("muEff", rho*nuEff()); return (  fvm::laplacian(muEff, U)  fvc::div(muEff*dev(T(fvc::grad(U)))) ); } Main difference is in two lines: Code:
fvVectorMatrix UEqn ( ... == fvOptions(rho, U) ); Code:
pZones.addResistance(UEqn); Concerning mu and nu: mu usually used when UEqn has term: Code:
fvm::ddt(rho, U) Code:
fvm::ddt(U) Concerning your initial question: can you, please, post two archives with your case files? (So people can reproduce the behavior of the solvers, take a closer look at the settings etc.) 

November 4, 2014, 16:44 

#7 
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 6 
Hi Alexey,
Thanks a lot for your reply. I did track down the definition of divDevRhoReff, but could you explain how those last two terms are the same? Code:
fvc::div(muEff*dev(T(fvc::grad(U)))) Code:
(fvc::grad(U) & fvc::grad(muEff)) Thanks, yanxiang 

November 5, 2014, 12:05 

#8 
Senior Member
Alexey Matveichev
Join Date: Aug 2011
Location: Nancy, France
Posts: 1,410
Rep Power: 25 
Hi,
concerning results: till 0.10 s they are the same, after due to BC on alpha solution diverges: Code:
... MULES: Solving for alpha1 Phase1 volume fraction = 0.025671 Min(alpha1) = 0 Max(alpha1) = 2.11241 MULES: Solving for alpha1 Phase1 volume fraction = 0.025671 Min(alpha1) = 0 Max(alpha1) = 2.11232 MULES: Solving for alpha1 Phase1 volume fraction = 0.025671 Min(alpha1) = 0 Max(alpha1) = 2.11223 MULES: Solving for alpha1 Phase1 volume fraction = 0.025671 Min(alpha1) = 0 Max(alpha1) = 2.11214 ... 

November 5, 2014, 12:26 

#9 
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 6 
Hi Alexey,
Thanks for the tests. Indeed, they diverge after a certain point, and it is likely due to the BC. Also, thanks for pointing me to the BC's. Cheers, yanxiang 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
interFoam in parallel  gooya_kabir  OpenFOAM Running, Solving & CFD  0  December 9, 2013 06:09 
Problem of InterFoam with LES SpalartAllmarasIDDES  keepfit  OpenFOAM  3  August 29, 2013 11:21 
InterFoam stops after deltaT goes to 1e14  francesco_b  OpenFOAM Running, Solving & CFD  8  July 31, 2013 02:29 
interFoam vs. simpleFoam channel flow comparison  DanM  OpenFOAM Running, Solving & CFD  11  January 5, 2013 07:21 
Open Channel Flow using InterFoam type solver  sxhdhi  OpenFOAM Running, Solving & CFD  3  May 5, 2009 21:58 