[marupio]

... but it isn't.

I have a uniform scalar field, T. I've created a mass-conserving swirling flow on a 10x10 grid using icoFoam. When I run scalarTransportFoam, the internal field comes out with a seemingly random variation of +/- 0.0025%. The solution should be a uniform value. The mean value is still correct, though.

In fact, the variation is a function of the timestep: +/- 0.0025 dt %.

Any ideas as to why this is happening?

Is this inherent in the second-order accuracy of OpenFOAM? It is destroying my reaction solver.

-Dave

[alberto]

Let's see if I understood it correctly. You have a fixed velocity field, and a uniform temperature field with BC's that should lead to a uniform steady-state solution different from the initial condition or equal to it? In the second case, the solver should not even try to solve the temperature equation...

[marupio]

Hi Alberto, thanks for the response.

Think of it as a stability test. The temperature field is uniform (say) 100°, with zeroGradient boundaries all around. Regardless of the velocity distribution, the temperature solution should always be 100°, uniform. That's what I've set up.

The solver does run... I don't think it does any checks to see if it shouldn't run, but regardless, it runs and produces a fluctuation of +/- 0.0025 dt %.

Any ideas why?

Do you know if scalar transport is limited by the Courant number? My results seem to say: yes... but I'm not sure why.

-Dave

[calim_cfd]

Hi!

first it would be nice to c your T dictionary
i say cuz as alberto said.. if you BC are properly set the solver wouldn't even run.. or maybe for just 1 iteration?

second: i'm not that good in discretization schemes but have you tried to refine your mesh and check the error? maybe it's a consistency problem..

[alberto]

Could you share your case? :-)

[marupio]

Sure thing. I've zipped up the case, and it even includes the first timestep of results showing the odd variations. It also includes the full mesh, since it isn't that big. If you can't duplicate it, then perhaps it is my installation of OpenFOAM...


-Dave

[alberto]

First note: you should have the "phi" field from icoFoam into the 0 directory, or your velocity field won't be conservative. Remember that conservation is enforced on phi, not U.

[marupio]

Good point. I copied icoFoam's phi, and the result improved by an order of magnitude: a variation of +/- 0.00025%. scalarTransportFoam still ran, though. I attempted deltaT values of 1, 0.1 and 0.01, and there's no difference. Perhaps it depends on how good the solution of icoFoam is.

I've attached the phi here.

[marupio]

Update: I tightened up the fvSolution tolerances in icoFoam, and the result improved by 3 more orders of magnitude, from +/- 0.00023% to +/- 0.00000071%. Thanks alberto for your suggestions, I think you got me on the right track.

Since this error is crippling my solver, I'm doing an exhaustive study on its characteristics. calim suggested mesh refinement, and I found higher densities of mesh to produce greater errors... possibly because it's a statistical distribution, and with more cells, there's more points for the bell curve, and a greater chance of landing further outside it.

Timestep size has no effect. 10000 x 0.00001s, 100 x 0.001s, and 1 x 1s all produce the same error.

The error propogates linearly with time.

So I don't think scalarTransport is limited by the Courant number, unless it is a very large value of Co. Anyways, thanks again for your assistance.

-Dave

[calim_cfd]

Originally Posted by marupio

Update: I tightened up the fvSolution tolerances in icoFoam, and the result improved by 3 more orders of magnitude, from +/- 0.00023% to +/- 0.00000071%. Thanks alberto for your suggestions, I think you got me on the right track.

Since this error is crippling my solver, I'm doing an exhaustive study on its characteristics. calim suggested mesh refinement, and I found higher densities of mesh to produce greater errors... possibly because it's a statistical distribution, and with more cells, there's more points for the bell curve, and a greater chance of landing further outside it.

Timestep size has no effect. 10000 x 0.00001s, 100 x 0.001s, and 1 x 1s all produce the same error.

The error propogates linearly with time.

So I don't think scalarTransport is limited by the Courant number, unless it is a very large value of Co. Anyways, thanks again for your assistance.

-Dave

Nice!!!

about the tolerances.. i guess your solution should be as acc as these solvers can be.. so.. 0.0000007% ~residual ~7e-9 guess you've set your solver tol. to 1-e8 ..

anyway i guess you got this now...

and i about mesh refinement.. did you use refineMesh? cuz if your mesh is not completely structured, then this appl will most of the times create a mesh with worse quality, but i guess you've covered that .

good job with this investigation

[alberto]

Also, try saving fields as binary instead in ASCII format.

[marupio]

@calim, I found that the scalarTransport tolerance settings had negligible effect on the error; rather the tolerance settings in icoFoam had the most significant impact. I moved from 1e-8 to 1e-15 to produce the change mentioned above. Increasing it further to 1e-20 had no effect, so this maxes out also. As for mesh refinement, it is a simple evenly spaced orthogonal grid of a square cavity. Mesh refinement was changing the number in blockMeshDict. Thanks for your suggestions!

@alberto - I hadn't thought of that. So the binary format records all significant digits, I'm guessing. I've been using ASCII with excessive write precision of around 20 digits to ensure I got all the significant ones. I know there's probable 4 or 5 digits of garbage on the end. Mind you, if I changed to binary, my python post-processing stuff would fail.

Again, thanks for all the suggestions. I'm well underway to solving this problem.

-Dave

[alberto]

Originally Posted by marupio

@alberto - I hadn't thought of that. So the binary format records all significant digits, I'm guessing. I've been using ASCII with excessive write precision of around 20 digits to ensure I got all the significant ones. I know there's probable 4 or 5 digits of garbage on the end. Mind you, if I changed to binary, my python post-processing stuff would fail.

The binary format does not lose precision. You can always store in binary and convert back to ASCII with foamFormatConvert.

[jeicek]

Hi alberto

but how can we use phi in the zeor file of scalarTransportFoam becuase dimensionally it demands for m/s variable or velocity.
I copied the phi to 0 file of scalarTransportFoam and I get this error:
unexpected class name surfaceScalarField expected volVectorField
while reading object U

file: /home/arefhakim/Desktop/scalarTransportFoam/pitzDaily/0/U at line 15.

From function regIOobject::readStream(const word&)
in file db/regIOobject/regIOobjectRead.C at line 136.

FOAM exiting

'' I have changed the the name of phi file to U, so U here means phi actually''
Any Idea??

[jeicek]

Originally Posted by alberto

First note: you should have the "phi" field from icoFoam into the 0 directory, or your velocity field won't be conservative. Remember that conservation is enforced on phi, not U.

Hi alberto

but how can we use phi in the zeor file of scalarTransportFoam becuase dimensionally it demands for m/s variable or velocity.
I copied the phi to 0 file of scalarTransportFoam and I get this error:
unexpected class name surfaceScalarField expected volVectorField
while reading object U

file: /home/arefhakim/Desktop/scalarTransportFoam/pitzDaily/0/U at line 15.

From function regIOobject::readStream(const word&)
in file db/regIOobject/regIOobjectRead.C at line 136.

FOAM exiting

'' I have changed the the name of phi file to U, so U here means phi actually''
Any Idea??