[wenxu]

Hello,everybody! Have a nice day!

QUESTION 1:
I am confused with the foamToVTK utility...
When I run the case /root/OpenFOAM/root-2.3.0/run/tutorials/incompressible/pisoFoam/les/pitzDaily, i got the different values with the paraFoam(load all of the time values:0 , 0.001,0.002 etc.) but when i use the foamToVTK utility and post process it with the paraview utility, i got the almost the different values, why?
(1)VTK(paraFoam) value
(2)different time (paraFoam) value.

I think the foamToVTK value is more "credible" since the inlet velocity is 10m/s...


QUESTION 2:
The previous case is my test case , i want to know the different divSchemes' dissipation.(I use the linear, limitedLinearV 1, linearUpwindV cellMDLimited, LUST grad(U) as the div(phi,U) fvScheme, the almost have the same value: the maximun value is around 16 m/s.)
But when i use Gauss linear as div(phi,U) fvScheme to calculate my case(attachment 3 :the flow jet inlet velocity is 9.5m/s.) the velocity seems unstable.. Any suggestions about my schemes, may i use other fvScheme such as LUST grad(U),limitedLinearV 1 or somthing else?

my mesh check as follows:
Checking topology...
Boundary definition OK.
Cell to face addressing OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
wall 2400 2480 ok (non-closed singly connected)
out_let 5440 5481 ok (non-closed singly connected)
out_pressure 20000 20080 ok (non-closed singly connected)
outer_wall 320 400 ok (non-closed singly connected)
inner_wall 640 720 ok (non-closed singly connected)
co_flow 3200 3280 ok (non-closed singly connected)
air_coal 1040 1081 ok (non-closed singly connected)
ch4 240 320 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (-0.03 -0.04 -0.04) (0.25 0.04 0.04)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (-6.205103531e-16 1.178824882e-15 -1.5696863e-15) OK.
Max cell openness = 3.329184873e-16 OK.
Max aspect ratio = 44.4510692 OK.
Minimum face area = 1.373471837e-08. Maximum face area = 8.494790386e-06. Face area magnitudes OK.
Min volume = 3.323882784e-12. Max volume = 1.412579007e-08. Total volume = 0.001256192872. Cell volumes OK.
Mesh non-orthogonality Max: 31.4382777 average: 2.385880292
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.4751537125 OK.
Coupled point location match (average 0) OK.

Mesh OK.

And divSchemes as follows:
divSchemes
{

default none;

//default none;
div(phi,U) Gauss linear;//upwind;//LUST grad(U);//limitedLinearV 1;//better than the linearUpwind scheme.//Gauss linearUpwindV cellMDLimited Gauss linear 1;
div(phid,p) Gauss limitedLinear 1;
div(phi,k) Gauss limitedLinear 1;
div(phi,Yi_h) Gauss multivariateSelection
{
O2 limitedLinear01 1;
CH4 limitedLinear01 1;
N2 limitedLinear01 1;
H2O limitedLinear01 1;
CO2 limitedLinear01 1;
h limitedLinear 1;
};
div((muEff*dev2(T(grad(U))))) Gauss linear;
div(phi,omega) Gauss limitedLinear 1;
div(phi,K) Gauss linear;//limitedLinear 1;
div(U) Gauss linear;
}
ddtSchemes
{
default backward;//Euler;
}

gradSchemes
{
default Gauss linear;
// default cellMDLimited Gauss linear 0.5;
// grad(U) cellMDLimited Gauss linear 0.5

}
laplacianSchemes
{
default Gauss linear limited 1;//corrected;//orthogonal;
}

snGradSchemes
{
default limited 1;//orthogonal;//corrected;//orthogonal;
}

fluxRequired
{
default no;
p ;
}

And my maxCo is 0.25, and the URF is:
fields
{
// ".*" 0.7;
"(p)" 0.3;
}
equations
{
".*" 0.7;
}
And pimple settings:
nCorrectors 3;//PISO correction times while SIMPLE always 1;
nOuterCorrectors 3;//in order to increase the stability you will need to add more corrector steps
nNonOrthogonalCorrectors 1;



Any suggestions will be helpful,thank you in advance...

my best wishes,
wen

[RodriguezFatz]

Wen, I am not sure I get you right... is this LES? I guess. Anyway, one general hint: Your mesh is good enough (orthogonal quality) to run without any "nNonOrthogonalCorrectors". You can set it to zero.

The velocity becomes unstable when switching from upwind to central differencing, because you remove all the additional dissipation that comes from the upwind scheme. I think this is pretty regular behavior. The question is how to get rid of it

Can you post some of the log output, when the velocity is unstable?

[wenxu]

Dear,Philipp,
(1) yes,it is LES;
(2)To stablize the calculation, i set nOuterCorrectors 3; and use small maxco which i currently use is 0.25. Any idea to get rid of the unstable situation?
(3)Sorry, i did not save the log output, but i post the result after i change the settings every 0.0005s.I found that there is no precise time that the velocity become unstable.

Thank you again!
best wishes,
wen

[RodriguezFatz]

What do you mean by "velocity becomes unstable" anyway?

[wenxu]

I mean that the mean inlet velocity is 9.5m/s, when i use upwind scheme the maximum velocity will be 12m/s around,but when i changed to the linear scheme, the maximum velocity will rise up to 26m/s as you see. Thank you for your reply!
best wishes,
wen

[wenxu]

What do you think i change the scheme to Gauss limitedLinearV 1; or you think the velocity is reasonable? (sorry, i can not judge whether the velocity is ok.. ) or please give me some hints how to let the velocity become more "stable"..
thank you!

best,
wen

[RodriguezFatz]

I don't want to just guess something without knowing that everything else is alright. So without the log file I would rather say nothing.

[wenxu]

Originally Posted by RodriguezFatz

Wen, I am not sure I get you right... is this LES? I guess. Anyway, one general hint: Your mesh is good enough (orthogonal quality) to run without any "nNonOrthogonalCorrectors". You can set it to zero.

The velocity becomes unstable when switching from upwind to central differencing, because you remove all the additional dissipation that comes from the upwind scheme. I think this is pretty regular behavior. The question is how to get rid of it

Can you post some of the log output, when the velocity is unstable?

Originally Posted by RodriguezFatz

I don't want to just guess something without knowing that everything else is alright. So without the log file I would rather say nothing.

Dear Philipp,
sorry for that. Now i changed to calculate the combustion use the same slover. And i also changed the scheme to Gauss limitedLinearV 1; Now this is the log file for a while..Thank you very much.

wen

[RodriguezFatz]

To me, the log output looks pretty nice. I see two pictures, one in post #1 and one in post #3, they look different. Which one are we dealing with here?

Maybe you will get better help (from other people) if you name your thread better and put it in the correct sub forum (OpenFOAM Running, Solving & CFD, or even in the main cfd forum). This seems to be an LES question.
I don't see anything suspicious here. Every equation converges. Of course you will get much lower velocity fluctuations if you set convective scheme to upwind. You damp everything with numerical diffusion. When switching to less dissipative schemes, you remove the damping. Picture number 3 in post #1 looks strange, because the fluid seems to accelerate in the inlet pipe. But I don't know your boundary conditions, so this also might be physical.

[wenxu]

Thank you for your help, your points are precious.
The post #3 picture is the one i changed the scheme not for a while, and the post #1 is the one have flow for some time(0.02s).
Thank you for your suggestions, very nice of you.

regards,
wen

[Tobi]

Hello together,

as far as I get to the thread I want to mention a few things at the beginning:

• your thread is about vtk and normal paraview format

• your thread is about fvSchemes

• your thread is not about stability / runtime problem nor combustion solvers

• please use code - tags to let the code be more readable

foamToVTK and paraView

You should know that paraview interpolate the values from the cell centres to the points and you ALWAYS will get interpolation errors. If you just want to integrate the mass flow (phi) through one inlet patch you will be amazed how bad the calculated value is. The best way to do things like that is to provide a patch (internal or boundary) and use openfoam calculations like:

• patchAverage

• patchIntegrate

How the VTK format stores the data is out of my mind. But I know that paraview always has interpolation errors. Maybe VTK is a better choice (I think I read something about this here in the forum too).


Numerical schemes

Its not a big deal to know that "Gauss linear" is very unstable. There are a lot of papers and publications. Additionally you can check out that page: http://www.holzmann-cfd.de/index.php...erical-schemes

There should be a video for linear (but is at the moment not working). I will check this the next hours.

I will not repeat all things about numerical schemes because you wlil find a lot of stuff in this forum, papers, publications and world wide web. But as some hints:

• upwind is the only conserved scheme which never will give unphysical results
  (but its very diffusive, check out the above mentioned page and the simple test case)

• linear is a very worse scheme because it produces unphysical results and in some cases (depend on mesh type and cell orientation) it could happen that this scheme starts to generate some source or sink terms in cells. This will go on and blow up your solution

• I prefer to use limitedLinear schemes

• A college told me also that you always should use limitedLinear not (V) version. This information is yanked out of a presentation of Hendrik or Jasak (can not remember)

Your combustion case

I am not sure about your model because I only used the flamelet model for combustion and this model is total different to the other once. But with my experience I think the temperature you have:

T gas min/max   = 300, 3444.701528

is a bit too much, isn't it? I simulated free-stream flames of H2 etc. and had maximum temperatures like 2400K or lower. Your case is a bit high I think and additionally I dont know why you solve some particles? There are none included in your case so why you solve it.

Additionally your relaxation is wrong:

fields
{
    "(p)"           0.3;
    }
    equations
    {
             ".*"            0.7;
    }

That means that you underrelax also the final iteration and this is wrong. I am not sure if the solver is using 1 instead but I think its not implemented so far. Therefor you should write something like this:

fields
{
    p              0.3;
    pFinal 1;
    }
    equations
    {
             ".*"            0.7;
     ".*Final" 1;
    }

[wenxu]

Thanks very much for your time,Tobias Holzmann. Your reply is so clearly and helpful, today i'm the happiest person in the word!
(1) I am really confused with the different fvSchemes and i read almost all of the forum about the schemes. Now i know that the upwind scheme i could use to get the initial value, and then change to the higher order schemes. Which one should i choose? Now maybe i already have the answer. (i have test the different scheme :TVD (limited) and QUICK and linear and linearUpwind using the case .../les/pitzDily, they almost have the same result. this report also compare the different schemes and concluded that the linearUpwind almost the best. LARGE-EDDY SIMULATION OF AIRFOIL FLOW USING OPENFOAM)
(3)Yes, i already notice that the temperature is too high!!! But when i use upwind scheme, it do not go to so high. I want know that the whether scheme have influence on the scalar, so afternoon i use the combustionFoam to calculate the simulation. (i will calculate the coal combustion in the future, and coal will be injected to the domain later.)
(4) i am not sure whether the relation form is wrong. I read a post and say that when we use this form:

"p.*" 0.3;

the last final step will use the relax factor, and if we use this form:

"(p)" 0.3;

then we will not use the relax factor to calculate the final step. May be your form is also right, i will try that.

Thank you again! very nice of you!
I also want to use your flamelet model lately. Very interesting! (this model could be used in LES?) Now i use the infintelyFast model that openfoam has built in. Also i have compile the EBU model succeed, if you are interested in it, i could share with you!

best regards,
wen

Originally Posted by Tobi

Hello together,

as far as I get to the thread I want to mention a few things at the beginning:

• your thread is about vtk and normal paraview format

• your thread is about fvSchemes

• your thread is not about stability / runtime problem nor combustion solvers

• please use code - tags to let the code be more readable

foamToVTK and paraView

You should know that paraview interpolate the values from the cell centres to the points and you ALWAYS will get interpolation errors. If you just want to integrate the mass flow (phi) through one inlet patch you will be amazed how bad the calculated value is. The best way to do things like that is to provide a patch (internal or boundary) and use openfoam calculations like:

• patchAverage

• patchIntegrate

How the VTK format stores the data is out of my mind. But I know that paraview always has interpolation errors. Maybe VTK is a better choice (I think I read something about this here in the forum too).


Numerical schemes

Its not a big deal to know that "Gauss linear" is very unstable. There are a lot of papers and publications. Additionally you can check out that page: http://www.holzmann-cfd.de/index.php...erical-schemes

There should be a video for linear (but is at the moment not working). I will check this the next hours.

I will not repeat all things about numerical schemes because you wlil find a lot of stuff in this forum, papers, publications and world wide web. But as some hints:

• upwind is the only conserved scheme which never will give unphysical results
  (but its very diffusive, check out the above mentioned page and the simple test case)

• linear is a very worse scheme because it produces unphysical results and in some cases (depend on mesh type and cell orientation) it could happen that this scheme starts to generate some source or sink terms in cells. This will go on and blow up your solution

• I prefer to use limitedLinear schemes

• A college told me also that you always should use limitedLinear not (V) version. This information is yanked out of a presentation of Hendrik or Jasak (can not remember)

Your combustion case

I am not sure about your model because I only used the flamelet model for combustion and this model is total different to the other once. But with my experience I think the temperature you have:

T gas min/max   = 300, 3444.701528

is a bit too much, isn't it? I simulated free-stream flames of H2 etc. and had maximum temperatures like 2400K or lower. Your case is a bit high I think and additionally I dont know why you solve some particles? There are none included in your case so why you solve it.

Additionally your relaxation is wrong:

fields
{
    "(p)"           0.3;
    }
    equations
    {
             ".*"            0.7;
    }

That means that you underrelax also the final iteration and this is wrong. I am not sure if the solver is using 1 instead but I think its not implemented so far. Therefor you should write something like this:

fields
{
    p              0.3;
    pFinal 1;
    }
    equations
    {
             ".*"            0.7;
     ".*Final" 1;
    }

[Tobi]

Hi,

you are welcomed. But for the future some hints (typeset)

• do not make all the text bold (its crazy to read)

• I am just a guy so you can call me tobi, too

• do not quote all the previous post (it lead too such long replays and is also bad for reading)

• your points (1) (2)... can also be much better organized using the style of the forum

1. First question
2. Second question
3. Third question

To your suggestion of the relaxation factors.
Can you please post some link. I never saw that before. Also if you check out all tutorials:

cd $FOAM_TUTORIALS
grep -rni -e "(p)" *

You will not get a fetch. Additionally to your replay I do not agree with you. If you set relaxation factors like that:

"p.*"            0.3;

You always underrelax in each PIMPLE loop and also in the final loop!
For more information about the PIMPLE look here:
http://openfoamwiki.net/index.php/ThePimpleAlgorithm
http://www.cfd-online.com/Forums/blo...hm-part-i.html

[wenxu]

Sorry, tobi. I am really new to this forum and do not know much about the typeset. Next time i will remember your suggestions and you will see the clearly questions, h h.
Regarding the relaxtion form i think you are right, i will change that.
Very nice of you and i should know much from you in the future not only combustion but also anything else, such as type, English etc.
PS:this link is very useful:http://www.holzmann-cfd.de/index.php...s/gauss-linear
Thank you again!!!


Best regards,
wen

[smog]

Hello Wen Xu,

I am trying to simulate a free jet flow in OpenFOAM using the interFoam solver. Can I know what is the length of the jet inlet and the length of the cylinder that you shoot into? Also, what is the mesh resolution?

I am using the RANS k-omega SST model. And I am having difficulties having the jet to show the fanning that other commercial codes have already validated. I am pretty sure I have the BCs set appropriately. Any help will be highly appreciated.

[wenxu]

Dear moghe,

I do not think it is very important to set the jet inlet to generate the turbulence for RANS. You know in RANS framework, the time average value is used instead of instantaneous values as used in LES. You will see in LES the inlet jet or turbulence generation technique is often used but you usually can not find them in RANS, because that's meaningless..

Also, the mesh resolution is not also a typical requirement in RANS as that in LES. Because you just want the "time average values".

Best,
Wen

[smog]

Wen, I understand all your points. I just wanted to know what your case configuration is. I am using a min cell dimension of 0.1 mm, an inlet value of 35 m/s, water jet issuing into stagnant air. I am having difficulty getting the jet to fan out. I have ~ 50D length downstream of the jet. The jet just passes through the air without showing any breakup.

Hence I wanted to know about your case setup. Thanks.

[wenxu]

Yes, in fact I have answered your questions. It is not easy to see "eddies" in RANS simulation, because it is "time averaged values" (the eddies can only be found in instantaneous simulation, such as LES and DNS. ) Do you ever found any eddy in RANS simulation? If it is, please tell me (counter plot).

Figure 1 and 2 attached in #1 have the same configuration as that in pisoFoam/les/pitzDaily
The configuration as show in figure 3 attached in #1 is 10D*40D with the minimum mesh of 0.01D.

I strongly recommend you to compare the simulation results with LES and RANS for the same configuration. I also recommend you to test this in pisoFoam/les/pitzDaily and pimpleFoam or icoFom/ras/pitzDaily at the tutorial.

Best regards,
Wen

[smog]

I understand. I will post my results when I am done comparing RANS and LES. What is the max cell size I can use, if I want to run my case with LES? Unfortunately, due to processor limit (16), I cannot go D/100 on the entire mesh domain as you did.

Any paper/material directing me towards this would be great!

[wenxu]

Sorry, I do not have specific material to describe the mesh resolution of LES simulation. You can google it.

But we typically do test the mesh resolution of the LES simulation, which called "grid independence test". That means you implement different mesh resolution to simulate the case, if the simulation results have not much difference, then we can say the simulation results has no relation with the grid numbers, in other word, the grid has achieved its dependence.

Best,
wen