#2686: Rename CCTK_REAL -> double when float is not tested
Reporter: Zach Etienne
Status: new
Milestone:
Version:
Type: enhancement
Priority: minor
Component:
Comment (by 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.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2686/rename-cctk_real-…
#2686: Rename CCTK_REAL -> double when float is not tested
Reporter: Zach Etienne
Status: new
Milestone:
Version:
Type: enhancement
Priority: minor
Component:
Comment (by 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.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2686/rename-cctk_real-…
#2686: Rename CCTK_REAL -> double when float is not tested
Reporter: Zach Etienne
Status: new
Milestone:
Version:
Type: enhancement
Priority: minor
Component:
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.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2686/rename-cctk_real-…
#2685: credentials are not taken from ORCID
Reporter:
Status: new
Milestone:
Version:
Type: task
Priority: trivial
Component:
Comment (by Steven R. Brandt):
I believe this was resolved when the user updated their profile and made their email public.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2685/credentials-are-n…
#2679: How to link an externally compiled library during ET compilation
Reporter: Maria Mutz
Status: open
Milestone:
Version:
Type: bug
Priority: minor
Component:
Comment (by Roland Haas):
Sorry, I forgot to respond to this. Looking at the `make.code.defn` file I do not understand why it even would ever try to compile `include_modulefiles_MRNS.f90` at all since it is not even listed in the SRCS line. So I am very confused. Is there any chance that I could get to see the whole source code?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2679/how-to-link-an-ex…
#2684: The tarball with the results of static_tov is full of macOS-specific files
Reporter: Gabriele Bozzola
Status: resolved
Milestone:
Version:
Type: bug
Priority: trivial
Component: EinsteinToolkit website
Changes (by Roland Haas):
status: resolved (was new)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2684/the-tarball-with-…
#2684: The tarball with the results of static_tov is full of macOS-specific files
Reporter: Gabriele Bozzola
Status: new
Milestone:
Version:
Type: bug
Priority: trivial
Component: EinsteinToolkit website
Comment (by Roland Haas):
I updated the file. Thank you.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2684/the-tarball-with-…