[bastil]

Concerning the schemes I am not sure what fluent uses for div and laplacian. I guess theses are some defualt schemes you can not vary in fluent, can you? The interpolation scheme in fluent should be 2nd order upwind (=linear upwind in OF). For best comparison this should be tried.

Bastil

[ariorus]

Yes probably one of the closest to the fluent 2nd order div scheme is Gauss limitedLinear.
By the way using it I found Cd less than 0.24; actually I used a little bit higher values for turbulence than Rajneesh: k=0.5 and eps=3.
(v 1.4 grid and Rajneesh grid of 0.6M).

Ciao.

[vinz]

Hi Rosario,

These are very good results but we should also check mesh convergence, by refining the mesh of Rajneesh for instance.
Could you post the fvSolution and fvScheme file you are using?

Thanks in advance.

Vincent

[ariorus]

Hello,

unfortunately I don't have much time to play with the mesh.

I just run the computation after changing k and eps as written before, starting from a uniform velocity of 60 m/s and a uniform k and epsilon equal to the inlet values.

I only changed the div scheme to limitedLinear 1 in fvSchemes, the rest of the setting is exactly the same as the one from Rajneesh.

[ariorus]

I don't know if this is important: I forgot to mention thar I started from upwind scheme and afterward switched to limitedLinear.

[vinz]

Hi Rosario,

I have one more question.
I guess you use your ssimpleFoam solver for the computations.
Could you post the lines:
Total pressure force =
Total viscous force =
Total turbulece force =
...
that you get from your solver (just for the last time for instance).

I'm not sure to make the right computation to get the Cd from the force, so I would prefer to compare directly the force. Since we run the same mesh with the same speed, this won't be a problem.

Thank you.

vincent

[ariorus]

Vincent,

this are the final forces I get:

Total pressure Force = (25.3542 -74.2559 1.36579)
Total viscous Force = (0.888662 -0.0129506 -0.0106971)
Total turbulent Force = (-2.01799 -2.7271 -0.0341599)
Total Force = (24.2248 -76.996 1.32093)
ExecutionTime = 5898.53 s ClockTime = 8583 s

Note that the values are not constant but oscillate a little as you can see by the following picture:



To find Cd I did 24*4/(60^2*0.1120)=0.238

[vega]

Rosario,

You are getting much lower numbers than me for the same mesh. One difference I see is the initial solution. I start from velocity field of (0 0 0)
as opposed to (60 0 0) for you. I will try your
ICs tonight.

Also, why is your turbulent Force negative? Am I missing something?

[vinz]

@Rajneesh:My turbulent force is also negative when I do the computations, even using exactly your case.

@Rosario: for the Cd I think you wanted to write:
24.4/(0.5*(0.5*0.288*0.389)*60²)=0.24
The result is the same, but not the computation. Am I right?

[ariorus]

@Rajneesh: it would be very strange if we got too much different values.. maybe I misunderstood something and/or I'm not running exactly your problem? (I used the mesh you sent me and the setting you posted in this thread on September 11). The results should not depend so much on the initial conditions either.

Regarding the negative value of the turbulent force it should not be too strange for a bluff body. Am I wrong? Don't you get a negative value in your case?

@Vincent: I don't understand your question: instead of using half the area I just doubled the force.

[anger]

Rajneesh,

in your post from September, 6 you were asking about the first entry in

turbDragCoefficient
(
const autoPtr<foam::turbulencemodel>& turbulence,
const volVectorField& U,
const volScalarField& p,
const dimensionedScalar& mu,
const word& patchName,
const vector& Uinf,
const scalar& Aref
);

How did you manage to convince liftDrag.C to calculate the turbulent coefficients? I do not seem to be able to give the first entry in that code such that compilation succeeds.

Best regards,
-Thomas

[vega]

Rosario,

My liftDrag utility does not have turbulent drag part as yet so I am not getting this magnitude.
I was focusing on the pressure drag only. I know from experience and literature that viscous drag
for automotive bodies range from 10-20% of the total drag. I would have expected total viscous drag (laminar + turbulent) to add ~ 5N of force.

I don't think turbulent force can ever be negative. It comes from shear stress contribution of turbulent viscosity. Shear stress, as you can visualise, will always resist flow so it has to be positive.

This brings to another observation I am trying to fathom for OpenFoam. I notice in my simulation that using second order schemes result in k and eps bounded to negative number to very high positive number. Negative k anywhere in the domain is unphysical. Did you also see negative k in your flowfield? Probably there is a connection between these two observations.

[ariorus]

Hello Rajneesh,

I think that it may happen that turbulence forces be opposed to the main stream direction even if (of course) turbulent viscosity is always positive.
In fact in k-epsilon models Reynolds stress is proportional to the mean strain tensor, and in some regions the resulting force could have a net effect opposed to the main stream, especially if separation occurs. I don't know if this is reasonable in Ahmed problem, but so far it is what I get. It will be interesting to see what happens with a finer mesh.

By the way both my k and epsilon fields are positive.

[anger]

Hi Vincent,

thank you for posting your liftDrag.C file.

Just for the files: I noticed two typos which prevented liftDrag.C from compiling:
1. line 108: read turbulenceModel instead of turbulencemodel
2. line 117: read wallFvPatch instead of wallfvpatch

Best regards,
-Thomas

[vinz]

Yes indeed, I don't know why it has been change into small leters when copying it on the forum snce it's capital letters in my code.
At least it works for you know.
I made some modifications to the lifDrag.C file in order to write at each time step the Cd values (laminar and turbulent) to a file named Forces.
Now it looks like the program of Rosario but can be used as a post-processing tool.
The lifDrag file can be downloaded at:
www.rtech-engineering.com/liftDrag.C

Regards,

Vincent

[vega]

Hi Rosario,

I agree that locally there may be negative turbulence force in the separated flow region.
But for 12.5 deg Ahmed body, flow remains attached.
And even if it separates, only part of the model that can see separation is a.baklite. All other
parts will have attached flow. (a.rear will not contribute to the viscous drag). How is your distribution of turbulent forces on each part?
Is it -ve for a.side or a.top/a.bot as well?

Also, total sum of all viscous forces should be +ve. Fluent's viscous drag contribution is ~20% of the pressure drag. Something is not correct, either with simulation or the liftDrag calculations.

--
Rajneesh

[ariorus]

Hello Rajneesh,

I totally agree with you. I don't have time to look at the solution by paraview but if there is no massive separation there must be something wrong in my forces computation. Moreover I checked the force on every surface and turbulent one is the opposite it should be (always negative in x except in a.rear where it is small but positive).

Maybe I made a mistake in computeForce file, I never checked the sign because I took the expression from the liftdrag utility, I don't know...
As soon as I can I will look at it.

Sorry...

[ariorus]

Hello,

I had a look at the liftDrag and have a doubt about how the turbulent force is computed:

turbForce = gSum
(
- mesh.Sf().boundaryField()[patchLabel]
& turbulence->R()().boundaryField()[patchLabel]
);


My problem is the - sign.
In fact
R=2/3 I k -2 nu_t Sij = <u_i*u_j>= - tau_tur

So the force exerted on the surface should be dF = -tau_tur dS = R ds, without the - sign.

If this was true it would explain the results I obtained (see the previous post in this thread). Could someone verify? What I am missing?

Thank you.

[nico765]

Yes, Rosario, I'd agree with you. I have computed a simple case, and i get negative turbForce.

Strange that the problem never came up before. Or they maybe see the problem, change it themselves without reporting.

Might be good to submit a bug report.

Nicolas

[ariorus]

Yes it is strange that the problem was never noted before, maybe it is because turbulent forces are not usually written as output sepatated by the other ones, or maybe I'm wrong and everything is fine, but we are missing something...

I'll wait for somebody else to confirm or deny this.