Vincent, BastiL, I just sen
 

Vincent, BastiL,

I just sent you the whole model via yousendit.com.
Just go to the link that you will get on email accounts in the profile and download the file.

thanks

--
Rajneesh

Thanks a lot Rajneesh, I recei
 

Thanks a lot Rajneesh, I received it.

I just had a look at your mesh and it's totaly different from mine, so it will be very interesting.

I'm going to run it to see what I get, and I'll post my results.

Regards,

Vincent

I can not try 1.4 at the momen
 

I can not try 1.4 at the moment, I am using simpleFoam 1.4.1 and I get:

Starting time loop

Time = 1

DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 0.0254472, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 1, Final residual = 0.00714854, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 1, Final residual = 0.0269422, No Iterations 1
DICPCG: Solving for p, Initial residual = 1, Final residual = 0.00938556, No Iterations 13
time step continuity errors : sum local = 38.8664, global = -1.26956, cumulative = -1.26956
DILUPBiCG: Solving for epsilon, Initial residual = 0.999636, Final residual = 0.0488436, No Iterations 1
bounding epsilon, min: -316.208 max: 3.94271e+06 average: 149.224
DILUPBiCG: Solving for k, Initial residual = 1, Final residual = 7.80029e-05, No Iterations 1
ExecutionTime = 215.08 s ClockTime = 215 s

...

Time = 4

DILUPBiCG: Solving for Ux, Initial residual = 0.123077, Final residual = 0.00151918, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.291113, Final residual = 0.00156297, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 0.539444, Final residual = 0.000117586, No Iterations 1
DICPCG: Solving for p, Initial residual = 0.646448, Final residual = 0.00622016, No Iterations 59
time step continuity errors : sum local = 17.5265, global = 0.715884, cumulative = 0.36078
DILUPBiCG: Solving for epsilon, Initial residual = 0.0334807, Final residual = 4.11484e-05, No Iterations 1
DILUPBiCG: Solving for k, Initial residual = 0.233191, Final residual = 0.000210396, No Iterations 1
ExecutionTime = 870.11 s ClockTime = 870 s

....

Time = 9

DILUPBiCG: Solving for Ux, Initial residual = 0.147892, Final residual = 1.23908e-07, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.414654, Final residual = 1.23514e-06, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 0.51769, Final residual = 1.05291e-06, No Iterations 1
DICPCG: Solving for p, Initial residual = 0.597334, Final residual = 0.00588535, No Iterations 23
time step continuity errors : sum local = 7.93123e+08, global = 3.50323, cumulative = 12.0621
DILUPBiCG: Solving for epsilon, Initial residual = 0.0486521, Final residual = 0.00112071, No Iterations 1
bounding epsilon, min: -1.14166e+14 max: 1.22753e+25 average: 2.34251e+19
DILUPBiCG: Solving for k, Initial residual = 0.611983, Final residual = 9.01935e-06, No Iterations 1
bounding k, min: -3.57866e+09 max: 3.03393e+19 average: 3.13484e+13
ExecutionTime = 1790.34 s ClockTime = 1791 s

...

Time = 12

DILUPBiCG: Solving for Ux, Initial residual = 0.00277457, Final residual = 3.62285e-05, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.00162991, Final residual = 4.10471e-05, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 0.00264718, Final residual = 4.61501e-05, No Iterations 1
#0 Foam::error::printStack(Foam:http://www.cfd-online.com/OpenFOAM_D...part/proud.gifstream&) in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 __restore_rt in "/lib64/tls/libc.so.6"
#3 Foam::DICPreconditioner::calcReciprocalD(Foam::Fie ld<double>&, Foam::lduMatrix const&) in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::DICPreconditioner::DICPreconditioner(Foam::l duMatrix::solver const&, Foam::Istream&) in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#5 Foam::lduMatrix::preconditioner::addsymMatrixConst ructorToTable<foam::dicprecond itioner>::New(Foam::lduMatrix::solver const&, Foam::Istream&) in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#6 Foam::lduMatrix::preconditioner::New(Foam::lduMatr ix::solver const&, Foam::Istream&) in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#7 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libOpenFOAM.so"
#8 Foam::fvMatrix<double>::solve(Foam::Istream&) in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/lib/linux64GccDPOpt/libfiniteVolume.so"
#9 main in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/simpleFoam "
#10 __libc_start_main in "/lib64/tls/libc.so.6"
#11 Foam::regIOobject::readIfModified() in "/home/brblo/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/simpleFoam "
Floating point exception


I tried to play around with relaxation factors and nonorthogonal correcors without success. I would be very happy if a FOAM expert could give me some hints. As mentioned before checkMesh reports some errors but other solvers run on this mesh without problems.

Thanks

Hi Bastil, As I allready sa
 

Hi Bastil,

As I allready said , I got the same problems.

What I didn't mentioned earlier is that my mesh was also running fine with other solvers but not with OpenFOAM (1.4.1 at least). So I guess it's really a problem of stability with respect to cell shape.

By the way, is your mesh refined a lot at the wall? Because I also noticed that simpleFoam doesn't really like very refined meshes at walls.

I would also be interested in openfoam expert solution toughts on the subject.

Vincent

At first, you can try to start
 

At first, you can try to start from the potential solution.
Then, you can try switching off any turbulence model, at the beginning.
After a few iteration, switch it on again, starting from the laminar solution.

Good luck!
Francesco

Vincent: I have two prims laye
 

Vincent: I have two prims layers near the walls. I do not know if this is "very refined". But in every case it is a mesh suitable for turbulence model + wall function.
Francesco: Thanks for these hints. I will try to turn off turbulence first, maybe this will help.

Bastil

BastiL, I had better succes
 

BastiL,

I had better success with GAMG solver for pressure. See it in the setup files I posted in this thread.
Also, see if your initial k and eps values are reasonable
--
R

Rajneesh, I agree. I get be
 

Rajneesh,

I agree. I get better results with the settings from Hrv:

http://www.cfd-online.com/OpenFOAM_D...es/1/4245.html

Nevertheles in 1.4.1 use GAMG instead of AMG. I have 68 Timesteps so far and it looks much better. I will keep you up.

Hi everybody, did someone t
 

Hi everybody,

did someone tried to change the liftDrag utility to account for turbulence. I mean replacing dragCoefficient(...) by turbDragCoefficient(...).
I face a stupid problem. For the turbDragCoefficient computation, one need to pass the turbulence model since the first function argument is:
const autoPtr<turbulencemodel>& turbulence
my question is what should I add to liftDrag.C to pass this turbulence model?

Thanks in advance.

Vincent

I had written time ago this ap
 

I had written time ago this application which computed at runtime the forces on a body. It is not too efficient but it should work.
It runs by this command:

ssimpleFoam <root> <case> "(patch1 patch2 patch3)"

where patch1-3 are the patches of the body you want to calculate the force on.

I run it in version 1.3 but it I verified it works with 1.4 as well (I don't have installed 1.4.1).

Hope this is useful.

http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif ssimpleFoam.tgz

to Rajneesh: I had a quick look at the setting of the Amhmed body you posted. How did you choose turbulent parameters? I mean k and epsilon at inlet.
Why did you start by zero velocity as initial condition?

Rosario, Initially I had pi
 

Rosario,

Initially I had picked values corresponding to the turbulence intensity of 0.6 and length scale of 0.02. It gives k and eps of order of 0.1. After that I played with several other values. Simulation does blow up if these values are too much out of reasonable limits.

There is no particular reason for starting from 0. Just thats the way I have been doing at my work for Fluent simulations. This choice seems safest even though it may take little longer to converge for some cases.

Thank you Rajneesh for your an
 

Thank you Rajneesh for your answer.

Actually I was thinking to use an higher value for turbulence intensity, but I don't know the details of the ahmed body experiment.

Are your result affected much by the turbulence set at inlet? (I'm just curious).

Hi Rajneesh, I come back t
 

Hi Rajneesh,

I come back to you after I run your case.
I didn't change anything and the computation went fine to the end.
Now I would like to compute the lift and drag and I get some strange results.
Here is what I get from my liftDrag utility:

Create mesh for time = 1500

Time = 1500
Reading U

Reading p

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting turbulence model RNGkEpsilon

Inlet velocity: (60 0 0)
pressure Coefficient: 0.00540718 viscous Coefficient: 0.000145663 turb Coefficient: -0.00139343
Wall patch 3 named a.forebody :
Reference area: 1 Reference length: 0.182 Total Turbulent drag coefficient: 0.00415941 Lift coefficient: (0 -0.0314594 0.00310949)

pressure Coefficient: -1.42641e-12 viscous Coefficient: 0.000213444 turb Coefficient: -0.000637851
Wall patch 4 named a.side :
Reference area: 1 Reference length: 0.862199 Total Turbulent drag coefficient: -0.000424407 Lift coefficient: (0 -0.0411145 8.50987e-07)

pressure Coefficient: -2.85131e-07 viscous Coefficient: 0.000111487 turb Coefficient: -0.000347901
Wall patch 5 named a.top :
Reference area: 1 Reference length: 0.645392 Total Turbulent drag coefficient: -0.000236699 Lift coefficient: (0 3.45158e-06 0.0261528)

pressure Coefficient: 0 viscous Coefficient: 0.000150484 turb Coefficient: -0.00048029
Wall patch 6 named a.bot :
Reference area: 1 Reference length: 0.862 Total Turbulent drag coefficient: -0.000329805 Lift coefficient: (0 -1.36859e-07 -0.0361365)

pressure Coefficient: 0.00288352 viscous Coefficient: 3.65491e-05 turb Coefficient: -4.66086e-05
Wall patch 7 named a.baklite :
Reference area: 1 Reference length: 0.216612 Total Turbulent drag coefficient: 0.00287346 Lift coefficient: (0 1.51287e-06 0.0129836)

pressure Coefficient: 0.0133659 viscous Coefficient: 3.91805e-07 turb Coefficient: 0.000242045
Wall patch 8 named a.rear :
Reference area: 1 Reference length: 0 Total Turbulent drag coefficient: 0.0136083 Lift coefficient: (0 -1.37909e-05 5.13891e-06)


One thing to notice is that I prescribe a reference area of 1m². So the numbers have to be divided by the real frontal area of the ahmed body which in your case is 0.5x0.288x0.389 (because it's a half body,am I right?).
So, to obtain the pressure coefficient for instance, I sum all pressure coefficients of each body part and divide by the number explained above. Then I get a rounded pressure coefficient of 0.387 which is exactly twice as yours. The same can be done with the viscous coefficient and I obtain 0.012 which is also twice as yours.

My questions are then, are your drag coefficients computed using the half body frontal area or the whole frontal area? are my computations wrong? Where is my mistake?

Thans a lot for your help.

Regards,

Vincent

Vincent, Its quite possible
 

Vincent,

Its quite possible that I am using area for the
full body. We have to use the half model frontal area, exactly as you mentioned. I will check it from home tonight and let you know

I had modifed the computeForces.H program by hardcoding the area
value (full body area = 0.1120). I have been lately using full model as well to see if the symmetry assumption makes any difference. The Fluent setup that predicted Cd exactly for 12.5 deg body is way off for this 30 deg model.

BTW if you are interested here is full mesh model for 30 Deg Ahmad body.It should be available on this link for next two-three days.

http://download.yousendit.com/09F309E86E2932AB

Rosario: I was playing with various turbulence conditions to see if the solution converges or blows up. I never really ran it long enough to get final values.

All: I am still trying to figure out best schemes for the second order accuracy for external aero simulations. Please post your observations.
--
Rajneesh

Ok, so I guess the drag coeffi
 

Ok, so I guess the drag coefficient you gave before in this thread should be multiplied by 2.

This actually closer to the results I get by using my own mesh.

Unfortunately this is not a good news since it is twice as large as ahmed results. And this factor 2 is very disturbing.

I'm going to download you 30° mesh and run it to see if we obtain the same results (i.e. drag coefficient twice as large as ahmed for a 30° slant angle).

Anyway thanks a lot for sharing your work.

Vincent

Yes, confirmed I was using are
 

Yes, confirmed I was using area of the full model.
So Sorry for the confusion.

By changing to second order schemes, Pressure Cd does come down to 0.320 (with correct area) but it is still quite far from the experimental values.

--
R

Hi all, I started working o
 

Hi all,

I started working on the half model from Rajneesh yesterday.First calculations went fine. Concerning the differences we should consider the following (I do not have th evalues of th ehmed experiment...)

1.) Make sure drag/lift is computed correct. Which tools are you using? I can not find any of the draglift tools in OF 1.4.1, are they? Where can I get them?

2.) Get rid of mesh-dependencies concerning near wall resolution and farfield. I guess mesh from Rajneesh is nice but hexcore mesh would be nicer. Also wake and stagnation point refinements are the key to validation.

3.) Turbulence modelling is another key.

BastiL

Hi everybody, So, unfortuna
 

Hi everybody,

So, unfortunatly I was right, the drag coefficients were wrong. But as you said, Rajneesh, by changing fvSchemes we get closer to the right values. Actually I changed the schemes to these ones:

ddtSchemes
{
default steadyState;
}

gradSchemes
{
default fourth;
grad(p) fourth;
grad(U) fourth;
}

divSchemes
{
default none;
div(phi,U) Gauss SFCD;
div(phi,k) Gauss SFCD;
div(phi,epsilon) Gauss SFCD;
div(phi,R) Gauss SFCD;
div(R) Gauss SFCD;
div(phi,nuTilda) Gauss SFCD;
div((nuEff*dev(grad(U).T()))) Gauss linear;
}

laplacianSchemes
{
default none;
laplacian(nuEff,U) Gauss linear corrected;
laplacian((1|A(U)),p) Gauss linear corrected;
laplacian(DkEff,k) Gauss linear corrected;
laplacian(DepsilonEff,epsilon) Gauss linear corrected;
laplacian(DREff,R) Gauss linear corrected;
laplacian(DnuTildaEff,nuTilda) Gauss linear corrected;
}

interpolationSchemes
{
default linear;
interpolate(U) linear;
}

snGradSchemes
{
default corrected;
}


and I'm getting a value of 0.27 (using th right area) for the drag coefficient which is not so bad. I'm still playing with the schemes to find the best ones to use.

Then, we'll have to find the best turbulence model to see if we get better results as Bastil has mentioned.

For the liftDrag utility, I use one I found on this forum. Use the search command to find the thread, there is an explanation on how to install the liftDrag tool on previous version of OpenFOAM (and this also works with 1.4.1).

Vincent

A good news I guess Fluent si
 

A good news I guess
Fluent simulation for the same mesh (0.63 Mill Cells) as used for OpenFoam predicts Cd of 0.309.
Now OF results do not look that bad. Fluent model
of ~3 Mill cells gives same result as test. I will
try that on my machine sometime soon.

From now on, I will be uploading interesting results, flow vis comparisons to the googlepage site
linked in my profile.

Actually, yes, it looks like a
 

Actually, yes, it looks like a good news.
I didn't understand how OpenFOAM was so far from Fluent, but the mesh difference is certainly one of the reasons.

I'm waiting forward to see what you get. I'll keep you updated if I find better results with other shemes.

Concerning the schemes I am no
 

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

Yes probably one of the closes
 

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.

Hi Rosario, These are very
 

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

Hello, unfortunately I don'
 

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.

I don't know if this is import
 

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

Hi Rosario, I have one more
 

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

Vincent, this are the final
 

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:

http://www.cfd-online.com/OpenFOAM_D...ges/1/5436.jpg

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

Rosario, You are getting mu
 

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?

@Rajneesh:My turbulent force i
 

@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?

@Rajneesh: it would be very st
 

@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.

Rajneesh, in your post from
 

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

Rosario, My liftDrag utilit
 

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.

Hello Rajneesh, I think tha
 

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.

Hi Vincent, thank you for p
 

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

Yes indeed, I don't know why i
 

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

Hi Rosario, I agree that lo
 

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

Hello Rajneesh, I totally a
 

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...

Hello, I had a look at the
 

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.

Yes, Rosario, I'd agree with y
 

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

Yes it is strange that the pro
 

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.