# scalarTransportFoam - this should be easy...

 Register Blogs Members List Search Today's Posts Mark Forums Read

 March 7, 2012, 17:27 scalarTransportFoam - this should be easy... #1 Senior Member   David Gaden Join Date: Apr 2009 Location: Winnipeg, Canada Posts: 397 Rep Power: 12 ... 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 __________________ ~~~ Follow me on twitter @DavidGaden

 March 9, 2012, 04:43 #2 Senior Member   Alberto Passalacqua Join Date: Mar 2009 Location: Ames, Iowa, United States Posts: 1,894 Rep Power: 26 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... __________________ Alberto Passalacqua GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as live DVD/USB, hard drive image and virtual image. OpenQBMM - An open-source implementation of quadrature-based moment methods

 March 9, 2012, 10:50 #3 Senior Member   David Gaden Join Date: Apr 2009 Location: Winnipeg, Canada Posts: 397 Rep Power: 12 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 __________________ ~~~ Follow me on twitter @DavidGaden

 March 9, 2012, 14:54 #4 Senior Member     mauricio Join Date: Jun 2011 Posts: 136 Rep Power: 8 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.. __________________ Best Regards /calim "Elune will grant us the strength"

 March 9, 2012, 16:03 #5 Senior Member   Alberto Passalacqua Join Date: Mar 2009 Location: Ames, Iowa, United States Posts: 1,894 Rep Power: 26 Could you share your case? :-) __________________ Alberto Passalacqua GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as live DVD/USB, hard drive image and virtual image. OpenQBMM - An open-source implementation of quadrature-based moment methods

March 9, 2012, 17:22
#6
Senior Member

Join Date: Apr 2009
Posts: 397
Rep Power: 12
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
Attached Files
 transportErrorCavity.tar.gz (20.6 KB, 25 views)
__________________
~~~

 March 10, 2012, 05:46 #7 Senior Member   Alberto Passalacqua Join Date: Mar 2009 Location: Ames, Iowa, United States Posts: 1,894 Rep Power: 26 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 likes this. __________________ Alberto Passalacqua GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as live DVD/USB, hard drive image and virtual image. OpenQBMM - An open-source implementation of quadrature-based moment methods

 March 10, 2012, 11:44 #8 Senior Member   David Gaden Join Date: Apr 2009 Location: Winnipeg, Canada Posts: 397 Rep Power: 12 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. __________________ ~~~ Follow me on twitter @DavidGaden

 March 10, 2012, 13:24 #9 Senior Member   David Gaden Join Date: Apr 2009 Location: Winnipeg, Canada Posts: 397 Rep Power: 12 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 __________________ ~~~ Follow me on twitter @DavidGaden

March 10, 2012, 15:12
#10
Senior Member

mauricio
Join Date: Jun 2011
Posts: 136
Rep Power: 8
Quote:
 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
__________________
Best Regards
/calim

"Elune will grant us the strength"

 March 10, 2012, 17:57 #11 Senior Member   Alberto Passalacqua Join Date: Mar 2009 Location: Ames, Iowa, United States Posts: 1,894 Rep Power: 26 Also, try saving fields as binary instead in ASCII format. __________________ Alberto Passalacqua GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as live DVD/USB, hard drive image and virtual image. OpenQBMM - An open-source implementation of quadrature-based moment methods

 March 11, 2012, 13:22 #12 Senior Member   David Gaden Join Date: Apr 2009 Location: Winnipeg, Canada Posts: 397 Rep Power: 12 @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 __________________ ~~~ Follow me on twitter @DavidGaden

March 11, 2012, 15:11
#13
Senior Member

Alberto Passalacqua
Join Date: Mar 2009
Location: Ames, Iowa, United States
Posts: 1,894
Rep Power: 26
Quote:
 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.
__________________
Alberto Passalacqua

GeekoCFD - A free distribution based on openSUSE 64 bit with CFD tools, including OpenFOAM. Available as live DVD/USB, hard drive image and virtual image.
OpenQBMM - An open-source implementation of quadrature-based moment methods

 April 28, 2014, 03:03 #14 New Member   jeicek Join Date: Nov 2013 Location: Germany Posts: 18 Rep Power: 3 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??

April 28, 2014, 03:05
#15
New Member

jeicek
Join Date: Nov 2013
Location: Germany
Posts: 18
Rep Power: 3
Quote:
 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

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

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

 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post santoo_cfd OpenFOAM Running, Solving & CFD 34 May 22, 2014 10:20 Boogiwoogie Main CFD Forum 0 December 19, 2010 07:32 danielr OpenFOAM Running, Solving & CFD 3 October 5, 2009 16:05 stu CFX 6 June 9, 2007 10:04 Dob Main CFD Forum 0 October 10, 2006 16:45

All times are GMT -4. The time now is 02:45.