CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   Main CFD Forum (http://www.cfd-online.com/Forums/main/)
-   -   Single or double precision (http://www.cfd-online.com/Forums/main/13203-single-double-precision.html)

Jonas Larsson March 25, 2007 18:51

Single or double precision
 
I was writing some numerical advice in the CFD-Wiki Best Practise Guidelines for Turbomachinery CFD.

From my experience, mainly on pure aero simulations (not with combustion, acoustics etc.), you only need to do use double precision if you have very well resolved boundary layers (y plus below 1). For inviscid euler simulations and coarse wall-function simulations it is most often sufficient with a single precision solver. Anyone disagree?

Is this the case also for more special simulations involving combustion, acoustics, etc. ? Or should the advice about single or double precision be enhanced with details about different types of simulations?

Hrvoje Jasak March 25, 2007 21:18

Re: Single or double precision
 
There is a lot of theories about this. The main issue is whether you can afford the memory for double precision or not - memory was an issue 10-15 years ago but now frankly I don't care.

Regarding the actual accuracy, in most external aerodynamics simulations you are OK with single precision. Ideally, the linear equation solver should be written in double precision (but not necessarily the coefficients). One needs to keep in mind that 1e-6 as a convergence criterion for a single precision would be really really tight.

However, as you move towards more complex physics, single precision will bite you. Examples include free surface (density ratio), combustion, spray, in-cylinder simulation (think mesh motion at time-step size of 0.01 deg crank angle) etc.

In any case, my philosophy (when running OpenFOAM) is to use double precision and not worry about round-off errors OR run single precision and compensate by engaging the brain :)

Hrv

Jonas Larsson March 26, 2007 04:38

Re: Single or double precision
 
That was the feeling I had - when running physics that create strong gradients it is often good to run in double precision. I added a bit of your thoughts to the best practise guidelines for turbomachinery CFD that I was working on. You can see the round-off section here:

http://www.cfd-online.com/Wiki/Best_...und-off_errors

If you have any other suggestions please let me know.

Praveen. C March 26, 2007 06:23

Re: Single or double precision
 
I always use double precision. Memory is not a constraint now. I do not know whether CPU times are different for single versus double precision. If the code is single precision, and in future you feel the need for double precision, then you will have some work to do to convert the code, especially with fortran, considering even all math functions come in two flavours. Hence I prefer to use double precision all the time.

George March 26, 2007 08:42

Re: Single or double precision
 
I prefer to use double precision, because some variables, like temperature, pressure and turbulent dissipation take quite large values (for example temperature=400 K, pressure= 150000 Pa, epsilon=10000 m^2/s^3), and especially for pressure the "lost" digits with single precision are important.

Jonas Larsson March 26, 2007 09:17

Re: Single or double precision
 
Yes, that is why codes often do not use the real pressure but instead use a gauge pressure, which is the pressure difference compared to the ambient pressure. That way you avoid excessive round-off errors when computing pressure differences etc.

Jonas Larsson March 26, 2007 09:22

Re: Single or double precision
 
Memory is always a constraint :) I still haven't used a computer which I haven't used up all the memory on. Many years ago CPU times used to be almost double for double precision. However, this is not the case for modern CPUs. Usually double precision is something like 30% slower I would guess, but I haven't really checked it in detail lately. Anyone have any recent details on the speed and memory difference when running CFD software in single or double precision? With the explosive growth of hardware and compilers these things change.

With a good fortran compiler it is usually very trivial to switch to double precision. With the compiler I used a long time ago all you had to do was to add a -r8 switch when you compiled your code.

George March 26, 2007 10:34

Re: Single or double precision
 
But in some applications (like in-cylinder simulation) pressure increases up to 15 bar during compression (15.E+5 Pa) and the difference compared to the ambient pressure is 14.E+5 Pa, again a very large number for single precision.

andy March 26, 2007 10:53

Re: Single or double precision
 
Personally, I tend to use single precision most of the time for reasons of efficiency but writing your code so that you can change one parameter, recompile and run in double precision is important for checking that roundoff really is limiting the convergence and not, for example, some boundary condition issue. It is also one of the standard checks to gain information when you observe something you do not understand in the behaviour of your code.

To expand on the point of Hrvoje, engaging the brain and writing code so that it can run in single precision when, for example, you are running a compressible code at low Mach number, teaches you a fair amount about good ways to normalise, express and difference terms.

I would suggest that your advice should be that the wise researcher uses both single and double precision.

Jonas Larsson March 26, 2007 12:45

Re: Single or double precision
 
Sounds like an application where double precision is not a bad idea.

Steve March 26, 2007 13:30

Re: Single or double precision
 
I wouldn't call 15.E+5 a large number. Large compared with acoustic perturbations perhaps, but not compared with ambient pressure numbers. I've never found the need for DP for state variables. Cumulative crank angles and time yes, stiff chemical equations yes, state variables no.

Praveen. C March 26, 2007 14:15

Re: Single or double precision
 
With g77/gfortran, there does not seem to be any way to switch variables during compilation. Aren't all computations actually done with the same precision in the floating point registers ? It would seem that the difference would arise due to the overhead of moving data into and out of registers, which may be smaller for single precision, and also better cache utilization ??? Of course this may be significant.

rt March 26, 2007 14:35

Re: Single or double precision
 
In my experience on AMD64, there is not sensible difference between 4-byte and 8-byte data word,

Also i mention that (i am not certain) when i read something about programming for AMD64 cpu, they adviced to use 4-byte data word alwase, and using smaller type (especially 1-byte) not only increase performance but also decrease executation speed (consider data off-set,...)

rt March 26, 2007 14:36

Re: Single or double precision
 
>they adviced to use 4-byte data word alwase an error, must be corrected to: they adviced to use 8-byte data word alwase

Bak_Flow March 26, 2007 16:10

Re: Single or double precision
 
Hi Jonas,

for turbomachinery, especially later stages of an axial compressor the geometry and mesh should be generated in double precision because the whole problem is offset from the axis of rotation by the hub radius.

As Hrv points out the coefficients should be ok single precision. BUT to get them you need difference of dimensions. Say you are doing a tip gap which is the order of 0.01[in] which is divided into 10 cells...that is NOT fine today! This gives dimensions on the order of 0.001! Then an offset of 10[in] starts to put you in real trouble.

Unfortunatly many meshes are still not written out in double precision today.

I always run in double precision today as well.

Regards,

Bak_Flow

desA March 27, 2007 00:15

Re: Single or double precision
 
I agree with Hrvoje's comments. Using double-precision is my norm - in fact, I'd go for anything beyond that, if it were available.

Then, at least, we could silence the eternal - it is all due to 'numeric error' - wherever that bogey may come from.

desA



All times are GMT -4. The time now is 11:55.