[aerosayan]

One year ago I asked if devs here develop their solvers to support single precision.
Paolo said that he only uses double precision because single precision is way too imprecise.

But many commercial solvers seem to provide single, mixed, and double precision solvers. Why?

ANSYS documentation even states that single precision is enough for most cases, except for a few, where high precision is required. Is that really the case? I think modern hardware has become more than powerful enough to fully support double precision. Even GPUs now support double precision codes.

Playing devil's advocate, I would say that their codes aren't single or double precision.

And I think that's actually a good decision from a business perspective. From a business perspective, it makes sense for ANSYS and other big companies to be able to use the highest precision that is available in the current/future generation hardware, 10,20,30,40 years from today.

It's not just about using future generation hardware. They can see benefits from using higher precision for current tasks which might need very high precision. One example would be point-inside-or-outside-polygon tests in mesh generation codes for particularly problematic cases.

So, most likely their code is generic and they just compile with REAL defaulting to REAL(KIND=8) or REAL(KIND=WHATEVER_FUTURE_PRECISION_IS_AVAILABLE).

But I still don't understand why they still provide single precision solvers? Like what's the use of single precision solvers when users can just as easily use double precision?

[Continuum]

I believe this move is in support of legacy 32 bit applications. These are memory-limited to about 2.5 GB (with reserve for the OS) and a single precision complilation gives a larger mesh count for the given limit. Of course, compiled to 64 bit, these limits are removed for the most part. I have several legacy applications that live in the 32 bit realm and need new compilers.



Years back, I recall Flow3D gave you a SP and DP option when running.


But as you ask, there is really no reason now (unless you are compiler-bound somehow).



Regards

[flotus1]

My counter-argument is this: why would you use a double precision solver, when you can get the answers you need with single precision?
SP runs faster. Which means more design iterations per unit of time. And/or less hardware costs to run an analysis. And/or less software license costs. And/or less electricity costs.
And for many applications, single precision floating point calculations are indeed more than enough accuracy.
Most RANS simulations I come across on a daily basis would not benefit from higher numerical precision. You won't get a solver to converge further than what FP32 can provide. Hence no need for FP64.
There are cases where the additional precision is required to get the simulation to run at all. And for one-off simulations, I also like to just use double precision. One thing less to worry about. But I don't think this is a strong enough argument to abandon the advantages of lower precision entirely.

I would also like to point out that double precision is not a magic bullet. Speaking of your example "point-inside-or-outside-polygon tests", you either handle the edge-cases in a way that would also work in single precision, or you are stuck with the exact same problem while doing double precision calculations.

Even GPUs now support double precision codes.

My observation of the GPU market is quite different. There is a massive downward trend for FP64 compute.
For GPUs that are not sold specifically marketed for GPU acceleration, the divider between FP32 and FP64 performance is getting larger each generation. Nvidia is currently at a factor of 32:1.
GPUs that don't have their FP64 performance nerfed are getting pretty rare these days. Quadros from the Fermi generation basically all had a divider of 2:1. In the following generations, this factor quickly increased for all but the highest-end models. And nowadays, I am not even sure if there is a current-gen "Quadro equivalent" graphics card with FP64 performance worth noting.
These days, development time and die space goes into AI-specific execution units.

I think modern hardware has become more than powerful enough

From my personal point of view, computers will never be powerful enough. But maybe that's just me

[aerosayan]

@flotus1 thanks for your answer.

so how should we consider developing our code? specifically how do we determine when REAL*4 would not be enough and we need REAL*8?

obviously one easy example of such a scenario would be when we MIN_ELEMENT_SIZE of the grid is so small that we need REAL*8.

but i'm not sure for which applications of our solvers, we don't need REAL*8. i would like to know how one might do an analysis to determine that REAL*4 would be enough.

few optimization strategies have worked for me, that i don't mind sharing : things like non-dimensionalization and storing the data as REAL*4 but using them as REAL*8 have been extremely useful (used only when higher precision is required, and we can guarantee data isn't lost by storing it as REAL*4)

currently i want to use REAL*4 mainly to reduce memory requirement of my grid generators by 50%. i have found some amazing optimization strategies for my quadtree grid generators, and they work! but the triangle grid generators seem to be brutally memory hungry.

[arjun]

Fluent offers because it is very old code and starccm provides because good number people involved in developing it were fluent developers.

In newer codes I do not see this trend of providing different precisions.

I personally prefer double precision because i have seen some cases that did not converge with single precision but converged with double precision.

I have even added long double support in Wildkatze and one model uses it. This model i am developing thinking that it shall be able to handle vacuum like situations. So density shall be dropping to 1E-7 or more.

[aerosayan]

Originally Posted by arjun

Fluent offers because it is very old code and starccm provides because good number people involved in developing it were fluent developers.

In newer codes I do not see this trend of providing different precisions.

I personally prefer double precision because i have seen some cases that did not converge with single precision but converged with double precision.

I have even added long double support in Wildkatze and one model uses it. This model i am developing thinking that it shall be able to handle vacuum like situations. So density shall be dropping to 1E-7 or more.

Thanks for your answer Arjun.

Yes, fluent is an old code, and it's a safe bet to use double precision, but as flotus1 said, single precision is extremely useful if you know that the results will be valid even with single precision.

I can think of heat conduction/diffusion through metal as an example case where we don't need very high precision. So if the code can use single precision, we can save memory and time.

But I don't know which cases in fluid flow can be solved with single precision. Probably low speed flows with RANS would be the best use case scenario.

It's somewhat starting to make sense to me I guess.

[arjun]

Originally Posted by aerosayan

Thanks for your answer Arjun.

Yes, fluent is an old code, and it's a safe bet to use double precision, but as flotus1 said, single precision is extremely useful if you know that the results will be valid even with single precision.

I also agree with it mostly. Theoretically there is no problem in accepting it. Practically it is alright more than 95 % of the time but ONCE in a while you end with situation where single precision won't cut it.

I give two example where it counted:

1. When i worked with CD Adapco there was case that came from client and no one could converge for almost 2 months. Until someone decided to run it in double precision. Wasted two months for the support engineer involved.

2. I had a case last year with half a million triangles. The complain was it took lots of time to converge. I checked and it turned out AMG was barely converging even after using up all 30 cycles.
it was very strange that it behaved that way. It turned out that due to precision, sum of off diagonals are slightly bigger than diagonal. In single precision the same would be much worse.

Theoretically one can say that this shall never happen but in practice, things do not go as book says.

Off course i put a guard against it and it now cost some time too.


precision can matter sometimes. The whole point is that accuracy does not count if your simulation does not converge. Once converged its all okay i guess.

[flotus1]

Originally Posted by aerosayan

so how should we consider developing our code? specifically how do we determine when REAL*4 would not be enough and we need REAL*8?

I don't think there is a simple and straightforward answer to that. Estimating the effect of numerical precision on the results in general, or further usage of the results somewhere later down the line, requires careful evaluation of every algorithm in your code.
This topic is definitely full of traps, waiting to bite an unsuspecting developer in the ass.

Your question was originally about single precision in large commercial codes. With decades of history, huge development teams, and a fallback option to double precision. I made my case for single precision under this pretense.

For developing your own solver, the answer is much easier. When in doubt, just use double precision. Your code will surely have enough other unique selling points, otherwise you would not develop your own code. No need to put in all the additional work just to keep the advantages of running single precision on top of that.

[sbaffini]

Originally Posted by aerosayan

One year ago I asked if devs here develop their solvers to support single precision.
Paolo said that he only uses double precision because single precision is way too imprecise.

I don't want to be picky, but what I said here Are you writing solvers for single or double precision?

is, roughly speaking, that I am not good enough to write a working single precision solver. I didn't actually try, but there are issues to carefully consider almost everywhere, and I don't really have time. Once you have them figured out, I think, you are just left with compiling the same code version with different flags. Single precision has indeed advanatges if you have it (speed, memory, communication and storage), so why not?

[aerosayan]

Originally Posted by sbaffini

I don't want to be picky, but what I said here Are you writing solvers for single or double precision?

is, roughly speaking, that I am not good enough to write a working single precision solver. I didn't actually try, but there are issues to carefully consider almost everywhere, and I don't really have time. Once you have them figured out, I think, you are just left with compiling the same code version with different flags. Single precision has indeed advanatges if you have it (speed, memory, communication and storage), so why not?

Yes some precision issues can be tricky. I just figured out yesterday how to generate extremely accurate meshes with single precision co-ordinates.