Hi,

in what cases it is recommended to use double instead of single precision for CFD calcs? When can I expect advantages from running double prec?

Best regards, Mark

Try to use double precision as often as possible unless you have a reason for not doing so.

Is double precision means only added accuracy and it also has to do something with convergence?

What i use to do is that when i have less computational resources, i go for single or else double..

see if ur avg. pressure values r large compared to pr. difference values then u need to go for double. Else single is sufficient.

Double precision removes the potential problem that round-off errors affect your solution or convergence. There is a bit more written about it in the Best Practice Guidelines for Turbomachinery CFD in CFD-Wiki. Here is a direct link to the relevant chapter:

http://www.cfd-online.com/Wiki/Best_...uble_precision

first, if your system is 64bit and u do not have memory constraint, always use dp, computational time is almost the same.

but when dp: as Jonas said dp just decrease rounding error (with proper scaling you could control them too), usually we do not need dp precision in floating point arithmetic but we have to use its due to other problem raised by rounding error.

i just state an example: assume iterative solution of Ax=b, if this system be ill-posed (e.g. pressure equation in multiphase flow, or generally Poisson equation with discontinuity in diffusion coefficient) small perturbation in the initial guess leads to large perturbation in solution (x, of next iteration) so decrease convergence or leads to divergence. So in this case we like to use precision as large as possible (just try by a numerical experiment), for more details look at Iterative Method book of Y. Saad, is online available (this issue is discussed where very nice).

Another example is solution of stiff ODE, the same scenario could be happen.

Hope this helps.

I'm certainly no expert in stiff ODEs or the like but the reason we introduced a dp solver into Flotherm was to resolve perception issues of incomplete convergence of temperature in models that have heat flow through high conductivity solids, e.g. the rather common case of heatsinks on smaller dissipating IC components.

With thermal conductivities ~300 W/mK small differences in dT (e.g. roundoff generated) give rise to large heat fluxes and associated perpetual small residuals. From a results perspective these errors were non-contributory to the overall thermal resistance of the heat flow path. So, double precision does remove these errors achieving a further one or two orders of magnitude decrease in residual error (with a painful increase in memory footprint) but the results of interest, temperature of the IC component, does not change.

If you need DP then you should think about changing your code.

Hi rt, u mention that "if your system is 64bit and u do not have memory constraint, always use dp, computational time is almost the same".

so if my OS is 32bit, will the computional time be similar too whether using dp or sp? I code in fortran and my code is in dp. I wonder if there's any difference if I've a 64bit OS. btw, the compiler also has to be 64bit, is that so? btw, my comp has 2gb ram.

Thanks!

I just express my personal experience, so i do not have an explicit answer to ur question, if u google in this regard u could found sufficient materials.

also cpu companies have some recipes about how to program which is compatible with your cpu, some year ago i read somthing about AMD32, i think that u sholud refer to such resources for more details, e.g. i read that there is not any cpu time benefit (but maybe drawback) to convert integer*4 to integer*1 (in fortran)! (consider data offseting on register memory of cpu)

maybe other members of this foroum has more information ?

I completely agree with Steve.

Everybody here is claiming that double precision is indispensible, but if you non-dimensionalise well, single precision must be enough.

Double precision is an era dependent concept, what was double in the past may be single in the future, so eehhh...