Rename CCTK_REAL -> double when float is not tested

[Zach Etienne]

Here's an idea: Virtually no thorns have been tested with CCTK_REAL -> float (single precision), and in fact many are guaranteed to break. How about for all thorns that have no unit tests in which CCTK_REAL -> float, we do a regex replace CCTK_REAL -> double?

Bottom line: If CCTK_REAL looks like a double, swims like a double, and quacks like a double, let's call it a double.

[Erik Schnetter]

Many thorns work and have been tested, in particular all thorns in the CactusBase, CactusPUGH, CactusPUGHIO, Carpet, and many in the CarpetX arrangements. Most of the basic infrastructure thorns work, but many of the physics thorns won’t.

Unit tests don’t specify the precision of CCTK_REAL, that’s a build-time choice. We could run unit tests in single precision, but I’m afraid many would fail simply because single precision has a different accuracy.

[Zach Etienne]

Thanks for the insights, Erik. It’s great to know that the core infrastructure correctly handles float. Indeed the problem lies with the many, many physics modules that – in all likelihood – have never been run with float. Most if not all of these could/should have CCTK_REAL replaced with double , as setting CCTK_REAL to float would break them.

[Erik Schnetter]

I’m not convinced they would break. I assume that many of them would switch to double precision for intermediate calculations, but they wouldn’t per se break. And if they break then it’s usually just a compile-time error that is straightforward to correct, such as e.g. calling max(x, 1.0) in C++.

In fact, I am going to propose that we should build the commonly used thorns with single precision and correct these compiler errors.

[Zach Etienne]

I like the idea of testing all the commonly used thorns with single precision, but I worry it’s going to take a long time to debug and fix all the issues. (I’d love to be proven wrong!)

Compiler errors are just the start I fear; consider all the algorithms with tolerances tuned to relative errors ~1e-15 like conservatives-to primitives solvers, AH finders, etc. Also I bet our more complex finite-difference-based and possibly finite-volume-based codes (BSSN & GRMHD codes) would become unstable & unusable without significant work. But again, I’d love to be proven wrong.

[Zach Etienne]

Roland pointed out during today’s call that the compile flag REAL_PRECISION can be set to 4, 8, or 16 bytes. It’s likely this directly sets CCTK_REAL.

Also if we would truly like a say, physics thorn, to be cross-compatible with different CCTK_REAL aliases, we’d probably also need aliases for transcendental functions so that e.g., CCTK_SIN(x) would alias to sin(x) for double , sinf(x) for float , and sinl(x) for long double.

[Erik Schnetter]

See https://en.cppreference.com/w/c/numeric/tgmath for C. (Fortran and C++ already support this generic functionality.)