[lr103476]

Hi,

I am validating OpenFOAM using Fluent on a static circular cylinder at Re=150.

The full grid and a zoom are shown here:
full grid
grid zoom near the cylinder

I used the following schemes:
ddtSchemes
{
default CrankNicholson 0.5;
}
gradSchemes
{
default Gauss linear;
grad(p) Gauss linear;
}
divSchemes
{
default none;
div(phi,U) Gauss linear;
}
laplacianSchemes
{
default none;
laplacian(nu,U) Gauss linear corrected;
laplacian(1|A(U),p) Gauss linear corrected;
}
interpolationSchemes
{
default linear;
interpolate(HbyA) linear;
}
snGradSchemes
{
default corrected;
}
fluxRequired
{
default no;
p;
}

The standard ICCG and BICCG solvers are used untill convergence to resectively 1e-6 and 1e-5 is obtained. The time step was chosen to be 0.02, which corresponds to 250 timesteps within each vortex shedding cycle.

Also the standard boundary conditions are applied:
inlet: U fixed and zeroGradient for p
outlet: p fixed and zeroGradient for U
upper/lower boundary: symmetry

I investigated the drag and lift which were comparable for both solvers, Fluent and OpenFOAM, but the vorticity plots show strange artifacts.

The following figures show these vorticity plots of both solvers:
vorticity Fluent zoom view
vorticity Fluent full view
vorticity OpenFOAM zoom view
vorticity OpenFOAM full view

When comparing the zoom views it appears that certain 'secondary' vortices occur which are not allowed to exist. It appears that the numerical diffusion is different between Fluent and OpenFOAM. OpenFOAM gives a reasonable solution, but not yet good enough. I also used blended and quick differencing but with comparable results.

Is someone having any ideas on how to improve these simulations? Do I use the proper schemes? Is the mesh of sufficient quality?

Thanks,
Frank

[hjasak]

The discretisation is fine - the only thing you could additionally try is to use least square gradients (which are strictly second order no matter what the mesh is doing) and you will have a full second-order accuracy with all bells and whistles (you could tighten the pressure tolerance a bit, but it probably does not matter). If PISO is converging, this is about the best you can get. What does the Courant number info say?

As for the solution, I cannot see that OpenFOAM is obviously inferior: it is clear you get more detail in the wake, but I doubt you can say that this is wrong. Could you expand your comments on "not good enough" please. For my taste, OpenFOAM has got minimal numerical diffusion and gives you more detail in the wake, which is in line with its LES pedigree.

Hrv

[eugene]

Hmmm, those extra features dont generally show up in low Re Karman vortex sheets.
http://upload.wikimedia.org/wikipedi...-animation.gif

Other than what Hrv has mentioned, all I can suggest, off the top of my head, is that it might be due to dispersion errors resulting from the use of central differencing on a non-uniform mesh. If you are playing around, use midPoint differencing instead of linear (CD) to improve energy conservation. Probably wont make a difference though.

[sshyu]

I guess it's the BC (outlet?) that cause the problem.

[lr103476]

By "not good enough" I mean that the Von Karman street does not look like the common figures out of the book, just like the previous link from Eugene.

The max courant number which corresponds to the chosen time step (0.02) was between 1.7 and 1.9. I also performed computations with half of the time step (0.01) such that the max Courant = 0.8 - 0.9. In that case the vortex wake was also similar. But, Crank Nicholson is unconditionally stable, why is Courant so important then?

Steven, why could the BC causing the problem. The boundary conditions I used are very general accepted.

Later today, I will post some pictures using different schemes.

Thanks,
Frank

[hjasak]

Some comments:
- I would say the Co number is a bit high for this kind of discretisation but your experiments will show if I'm right
- You are using central differencing and Crank Nicolson, which means that the discretisation error is fully dispersive in nature. Thus, you need to beware dispersive error effects rather than worry about stability. Also, note that having full second-order discretisation still does not help you if you take a time-step of half an hour because it's both the nature and magnitude of the discretisation error that matters
- The vortex we are looking at is pretty weak and it is located between two stronger vortices. However, to me it does not look like numerical rubbish (too big, growing and well organised in terms of flow). Also, thinking about the flow, I cannot exclude the possibility of there being a vortex in this position (consider a similar example of a backward-facing step and a small vortex right in the corner).
- Having in mind that the vortex is weak, keep in mind that you will kill it even with a small amount of numerical diffusion: I would predict that with Euler implicit in time or Gamma in space you will kill off the additional vortices and get the picture you expect. However, this may tell you more about the quality of second-order implementation in FOAM than whether there should be a vortex there in the first place

I've had a look on the web - search Karman Vortex in Google images



It seems to me there's something going on experimentally in the region we are looking at.

Please keep me posted,

Hrv

[lr103476]

So say less numerical diffusion is present in OpenFOAM. How can you explain the solution to be more smeared out near the end of the domain (visible in the plots of the full domain).

On monday I will try to post a more detailed investigation using more different schemes.

Thanks, Frank

[eugene]

The smearing near the outlet is almost certainly a result of the zero gradient outlet condition on velocity and fixed value pressure. Obviously, zero gradient is not a strictly valid outlet condition for velocity when you have vortices crossing that boundary with a circulation magnitude that is an appreciable fraction of the convection velocity. Similarly, the vortices will have local pressure minima at their cores. Translating them across the boundary will cause this minimum to "collapse" when it hits the fixed value boundary. I have personally observed this phenomenon in many of my LES runs, but because I place the outlet far from regions of interest it never bothered me.

Looking at the full domain plots, it is distinctly possible that one or both of these inaccurate outlet boundary conditions might be a contributer to the perceived problem.

Hrv might be able to suggest a more suitable BC for the pressure (fixed mean outlet pressure, locally interpolated from the interior), but I dont think we ever developed a transmissive BC for momentum. If such is necessary for an accurate solution, it is certainly something the OpenFOAM community should be interested in implementing.

[sshyu]

Frank,

Eugene has explained very clearly. I think there are a couple of ways to test if the BC is OK:
1. increase the flow domain, or
2. increase Re

If the problem is less obvious (I don't think it will disappear), then it's very likely the outlet BC causes the problem.

Do you use the same BC for OpenFOAM and Fluent? Do they use the same discretization, particularly the convection terms?

Do they have the same frequency? Did you compare the cases at the same time? If the two cases have different frequencies, yet we are looking at the same time t, then they are under two different conditions. The better way is to look at the cases with the same dimensionless time, in whch the time is normalized based on the freqency. I am wondering then we could see the same structure near the cylinder.

[lr103476]

Hi,

At the following location I put some of my results concerning the validation of OpenFOAM using the flow around circular cylinders:

www.aero.lr.tudelft.nl:/~frank

I calculated the following cases:

1) Fluent reference case, 2nd order temporal/spatial accuracy
2) OpenFOAM central difference scheme, dt=0.02, corresponding to max Co=1.8
3) OpenFOAM central difference scheme, central diff, dt=0.005, corresponding to max Co=0.5
4) OpenFOAM, blended difference scheme
5) OpenFOAM, gamma difference scheme
6) OpenFOAM, least squares difference scheme
7) OpenFOAM, QUICK difference scheme
8) OpenFOAM, standard settings + Euler implicit time integration.

Looking at the vorticity plots the following things can be observed:
* A smaller time-step and Courant number does not change the solution significantly.
* The 'secondary' vortices are present in all cases except for case 1, 4 and 5. Blended and gamma differencing seems to diffuse the solution much more than central differencing. Additionally, Gamma differencing led to 'blurbed' vortices, as is QUICK differencing.
* The influence of Euler Implicit compared to the standard (case 2) is low.

The smearing near the outlet boundary is present in all cases. I doubt that this will influence the flow near the cylinder, where the 'secondary' vortices are born.

Steven, I performed also one simulation with Re=400, with similar results. But higher Reynolds numbers than 150 are subjected to turbulent regions, such that icoFoam can't be used. Since my ultimate goal is to use icoFoam on moving wings at Re=150, I am not very interested in high Reynolds number flow.

So I guess I will have to write a free surface boundary condition at the outlet, or something
like that. Btw, in the case of Fluent I also used a pressure outlet BC.

I will work on the following:
* Exactly the same settings using Fluent. From experience with Fluent I doubt that the 'secondary' vortices will pop up.
* Enlarge the flow domain.

So, I am gladly asking I if you got any comments on my findings.

Thanks, Frank

[eugene]

Are you doing any nonOrthogonal corrections? (see nNonOrthogonalCorrectors in fvSolution)
Does the "midPoint" differencing scheme make any difference?

I bet the fluent outlet BC uses a fixed mean pressure and not a fixed local pressure, i.e. locally the pressure is interpolated from the interior, but scaled to match the overall pressure spec. I just dont know how else to explain the massive smearing near the outlet.

[sshyu]

Frank:

Good work!

If the two codes use the same discretization (in convection), have the same BC, I can't think of any reason to get different phenomena.

[sshyu]

Frank:

Take a look at the outlet pressure of Fluent see if Eugene is correct.

[JBeilke]

I run some tests a year ago to check the pressure differences for a given mass flux between OpenFOAM, Star and CCM+ (for polyhedral meshes). There was a real difference at cases with vortices or a backflow at the outlet, just because star/ccm+ uses the mean pressure and FOAM uses a fixed local pressure.

[eugene]

You can easily impose the mean pressure outlet condition in the top level code provided the outlet is on a single processor of a multi-processor run. All this requires, is setting the outlet pressure equal to the near-outlet cell pressure (zero gradient), calculating the resulting mean pressure and then scaling the newly assigned outlet pressures to conform to the specified fixed outlet pressure.

Unfortunately, due to the fact that not all processors are aware of all boundaries (something that will hopefully change soon) it is very difficult to generalise the calculation of the average outlet pressure when the outlet boundary is distributed over 2 or more processors. Incorrect scaling can of course produce discontinueties in the outlet pressure, which will probably play havoc with your simulation.

Certainly worth a try in this case though.

[hani]

I'm having a similar discussion about outlet boundary conditions in another thread (http://www.cfd-online.com/cgi-bin/Op...=5899#POST5899).

I would like to ask Frank if you could try just to set a Neumann boundary condition for the pressure at the outlet and specify the pressure reference point somewhere where the pressure is likely to be constant. You set this in fvSolution, PISO:
pRefCell 0;
pRefValue 0;
where pRefCell is the cell where pRefValue is set.
This should be faily easy for you to do, and it would show if the discussion on the outlet pressure boundary condition is relevant.

Håkan.

[lr103476]

Thanks for all the responses to my problem. I updated my results on:
www.aero.lr.tudelft.nl/~frank
with midpoint integration, coarsening enlarged mesh near the outlet and a higher Re=400 case. I also included a table with results of the mean drag, the mean frequency of the lift/drag and the mean amplitude of lift/drag.

All cases got the same 'secondary' vortices and large diffusion near the outlet. Using an enlarged mesh with large cells near the outlet I tried to diffuse the wake in order to find out if the flow near the outlet influences the 'secondary' vortices near the cylinder. This was not the case.

The most plausible explanation for the diffusion seems indeed the boundary condition near the outlet. First I will try the Neumann boundary condition at the outlet specified by Eugene in the other thread: http://www.cfd-online.com/cgi-bin/Op...=5899#POST5899

Maybe I free-surface or zero stress boundary condition are also better alternatives to the zero gradient pressure BC. I will try to programme these myself, which won't be easy since I am not really into the source code. Still learning though. But I doubt that the 'secondairy' vortices are due to a wrong outflow BC. I hope to find the solution soon which will encourage me to go on with OpenFOAM during my PhD here in Delft.

Unfortunately I am not able to come to the workshop. It would have been nice to give a presentation about my problem, maybe next time. I hope that the presentations given at the workshop will be available via the wiki page.

I'll keep you posted.
Frank

[lr103476]

Is there a change that my 'problem' may be mesh dependent? If so, what would be a good mesh instead?

Thanks, Frank

[lr103476]

All right.

The 'strange' secondary vortices which I showed you are really dependent on the mesh size. Right now I am performing a range of simulations using meshes of 50k, 100k and 200k cells using dt=0.02,0.01 and 0.005 with OpenFoam and Fluent.

On the finest mesh using the smallest time step the 'strange' vortex things are gone and nice vortex pairs remain, just the way you would expect according to literature. As soon as I have analysed the results I will post them on my web.

Regards, Frank

[sshyu]

In my experience, a bad BC might require very fine mesh and/or very large range to resolve the problem.