|
[Sponsors] |
October 21, 2014, 14:03 |
|
#1 |
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 14 |
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 11:44. Reason: posted few minutes apart |
|
October 26, 2014, 11:49 |
|
#2 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
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, 08:36 |
|
#3 |
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 14 |
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, 15:18 |
|
#4 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
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, 13:34 |
|
#5 |
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 14 |
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, 14:50 |
|
#6 |
Senior Member
|
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, 15:44 |
|
#7 |
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 14 |
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, 11:05 |
|
#8 |
Senior Member
|
Hi,
concerning results: till 0.10 s they are the same, after due to BC on alpha solution diverges: Code:
... MULES: Solving for alpha1 Phase-1 volume fraction = 0.025671 Min(alpha1) = 0 Max(alpha1) = 2.11241 MULES: Solving for alpha1 Phase-1 volume fraction = 0.025671 Min(alpha1) = 0 Max(alpha1) = 2.11232 MULES: Solving for alpha1 Phase-1 volume fraction = 0.025671 Min(alpha1) = 0 Max(alpha1) = 2.11223 MULES: Solving for alpha1 Phase-1 volume fraction = 0.025671 Min(alpha1) = 0 Max(alpha1) = 2.11214 ... |
|
November 5, 2014, 11:26 |
|
#9 |
New Member
Join Date: Mar 2012
Posts: 29
Rep Power: 14 |
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 |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
InterFoam stops after deltaT goes to 1e14 | francesco_b | OpenFOAM Running, Solving & CFD | 9 | July 25, 2020 06:36 |
interFoam vs. simpleFoam channel flow comparison | DanM | OpenFOAM Running, Solving & CFD | 12 | January 31, 2020 15:26 |
interFoam in parallel | gooya_kabir | OpenFOAM Running, Solving & CFD | 0 | December 9, 2013 05:09 |
Problem of InterFoam with LES SpalartAllmarasIDDES | keepfit | OpenFOAM | 3 | August 29, 2013 11:21 |
Open Channel Flow using InterFoam type solver | sxhdhi | OpenFOAM Running, Solving & CFD | 3 | May 5, 2009 21:58 |