turbFoam vs CFX  2D case high Re
Hi everybody
I am running a 2D simulation with turbFoam trying to match the experimental test data of Delany Sorensen paper ( Low speed drag of cylinders of various shapes) and in order to compare OF results with CFX5 ones. Unfortunately the solver during the run becomes unstable and finally diverge for Co number > 0.2. This mean a time consuming run comparable with the CFX one and with a lower quality of results. So I am wondering that something is basically wrong in my simulation settings. Description of the run: 2D bluff body (rounded square shape) incompressible fluid  high Reynolds number 1e51e6 (subtrans critical region) unsteady RANS, kOmegaSST model for turbulence Mesh  box: 20D flow direction 7D transverse direction bodyinlet distance 7D (yplus checked mean about 0.5) Solver solver turbFoam (vers. OF 1.5 dev) The first question is about the BC: inlet U and p fixedValue outlet U and p zeroGradient  wall no slip condition top and bottom symmetry Are the BC correct for this kind of problem? I mean, would be better to use a integral outflow condition for pressure or a freestream BC? The second question: with Co>0.2 at the beginning of the vortex shedding the solution becomes unstable,the values of Cd, p and wallshearstress start to present high frequency spurious oscillations. The final results are very noisy signals that tends to diverge. Please take a look to my fvSchemes ddtSchemes { default CrankNicholson 0.9; //almost fully impliit // default backward; } gradSchemes { default Gauss linear; } divSchemes { default none; div(phi,U) Gauss limitedLinearV 1; div(phi,k) Gauss upwind; div(phi,omega) Gauss upwind; div((nuEff*dev(grad(U).T()))) Gauss linear; } laplacianSchemes { default none; laplacian(nuEff,U) Gauss linear corrected; laplacian((1A(U)),p) Gauss linear corrected; laplacian(DomegaEff,omega) Gauss linear corrected; } interpolationSchemes { default linear; interpolate(U) linear; } snGradSchemes { default corrected; } fluxRequired { p; } So how to solve this problem saving calculation time? thank you in advance for your comments Fabio 
1 Attachment(s)
just an example of Cd plot
the green line represents the simulation with Co = 0.7 for the red one Co = 0.2 as you can see the Cd signal becomes very noisy. Fabio 
Quote:
from a first glance, try to run it with:  inlet: U fixedValue, p zeroGradient  outlet: U zeroGradient, p fixedValue. Andreas 
1 Attachment(s)
thank you Andreas
I am running now the simulation with the suggested BC and the signal seems to be stable now but it is quite irregular. I don't know why but OF run does not present a well defined first armonic as in the CFX simualtion. I hope this is a transient effect. What do you think about? Fabio 
I looked at your latest Cd plot. What happened at t = 1.15s?
Did you change discretization schemes there? Just a general question: how does your controlDict look like? How did you set the values for the evaluatin of your forceCoeffs? 
nothing has changed just the wake become unstable. here is my controlDict
pplication turbFoam; deltaT 1e05; writeControl adjustableRunTime; writeInterval 0.05; purgeWrite 0; writeFormat ascii; writePrecision 6; writeCompression uncompressed; timeFormat general; timePrecision 6; runTimeModifiable yes; adjustTimeStep yes; maxCo 0.2; maxDeltaT 1.e04; functions // this one! ( forces { type forces; functionObjectLibs ("libforces.so"); //Lib to load patches (HULL); // change to your patch name rhoInf 1.185; //Reference density for fluid CofR (0 2.1336 0); //Origin for moment calculations } forceCoeffs { type forceCoeffs; functionObjectLibs ("libforces.so"); patches (HULL); //change to your patch name rhoInf 1.185; CofR (0 2.1336 0); liftDir (0 0 1); dragDir (0 1 0); pitchAxis (1 0 0); magUInf $v_inlet; lRef 0.3048; Aref 0.00929; } ); thank you for your comments Fabio 
Well, what you can do moreover is check your lRef and Aref. Afaik Aref for 2Dcalculations is lRef*cellThickness in the "empty"direction.
Maybe you should also try to run "Gauss linear" on your divSchemes for the reason of accurateness. On the other hand this schemes of second order are often the reason for socalled "wiggles" in your solution. But give it a try! 
thanks again
the data in the controlDict are correct, but real problem is the wide band frequency of the signal. anyway i'll try to change the divSchemes (div(phi,U)??). Fabio 
I saw and see the problem :)
Some oscillation might be due to the transient phenomena, but the range of oscillation seems  as you already said  to high. I can offer you to send me the case to dietzandreas(at)gmx(dot)de 
2 Attachment(s)
Fabio,
I just had a collapse of the computation atfter 0.13769s of transient computation. Strange thing about it is that when I restart from the latest written timestep, the simulation passes the point where it crashed before without any problems... (See attached files) Let's see what happens until tomorrow and if I can give any explanation for that. Edit: One reason for diverging could be that I worked with relTol = 0.01 for p iterations. Now I changed it to relTol = 0. 
1 Attachment(s)
Computation was not successful, same behavior as you described: Sudden increase of p and U leading to divergence.
It seems like the red cell in the attached image causes the calculation to break down. Probably you have to improve your mesh. As I see, your mesh fails one mesh check in "checkMesh". Simplest way would be to raise your y+. For a timestep where computation still ran fine I had the following values for yPlusRAS: min: 0.0100218 max: 0.194452 average: 0.0668419. Hence you can increase the cell size and within doing so get rid of the high aspect ratio cells checkMesh is complaining about. Best regards, Andreas 
First of all thanks,
However it is very strange. My last results seems to be better and they is no longer diverging. I'll check the file that I provided to you. Some other check I'll post my uptodate results. Quote:
Quote:
Anyway I do not understand why for CFX seems to be good enough. B.R. Fabio 
Quote:
Quote:
Quote:

ok, ok...you are definitely right.
I'll try to do a better mesh but my hope was to sweep across an acceptable range of Re with the some mesh...too optimistic?!. I'm quite interested in your comment about the relTol to be set to 0. Could you explain me your point? Fabio 
relTol compares the residual of the computed timestep to the previous one(s). In case the residuals are oscillating/building up you can run into a diverging computation even if the relTol of the residuals remains in its bounds.
Regards 
2 Attachment(s)
hi Andreas
below you can find the last plot of the solution. What do you think about? Probably your problems with the divergence of the run was my fault. Sorry. The fvSchemes provided could be the wrong one. You can find below the raw original version (a old mixed shemes dict). thanks again Fabio 
Hey Fabio,
you are the one with the Delany Sorensen paper ;) If you are awaiting periodic detachement, your Cd could be right. But for me it is not possible to say if these values are correct, especially the amplitude seems really high to me. Andreas 
The mean of Cd seems to be Cdmean = 1.2 [nd], it is 15% higher than the Delany tests one. It is the best result that I was able to get so far (with this mesh).

All times are GMT 4. The time now is 05:11. 