#2753: Add CarpetX thorns to Einstein Toolkit manifest
Reporter: Erik Schnetter
Status: new
Milestone:
Version:
Type: proposal
Priority: major
Component: Other
Comment (by Samuel Cupp):
Sorry for not responding to this promptly. I do not have a complete list of machines that people are currently using. However, I know for sure people are using Deep Bayou, the INL machines, and Falcon. It looks like Falcon has gcc 12, which I believe has all of the '17 standard. Can you confirm what version of gcc is the minimum for CarpetX currently?
I don’t know what machines the RIT group is using, but it sounded like several of their machines probably don’t have access to C\+\+17 \(or anything beyond like 2011…\).
I agree with Roland that it would likely be untenable to require C\+\+17 by default to compile the toolkit.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2753/add-carpetx-thorn…
#2753: Add CarpetX thorns to Einstein Toolkit manifest
Reporter: Erik Schnetter
Status: new
Milestone:
Version:
Type: proposal
Priority: major
Component: Other
Comment (by Roland Haas):
Since we only really support gcc or \(on some systems\) clang I ran a quick test to see just how involved this might be:
```
.../mdb/optionlists$ git grep -l CC.*gcc *
db-sing-cpu.cfg
db-sing-nv.cfg
debian-cuda.cfg
expanse-gnu.cfg
generic.cfg
graham-gpu.cfg
graham.cfg
orca-gcc.cfg
raspbian.cfg
summit.cfg
thornyflat.cfg
wheeler.cfg
```
which shows that almost none of the big US production clusters \(except expanse and summit\) use `gcc` and none clang.
`db-sing-nv` and `db-sing-cpu` are are both special for deepbayou and singularity and CarpetX so they are ok.
So we would be disabling everywhere and enable only on db1, expanse and summit. We cannot easily enable on generic since that would push the minimum required gcc on workstations where we do not know what is present \(one hopes that everybody runs a gcc new enough, though gcc-11 might be too new for some setups\).
I could not find any cluster officially using clang \(an only theta uses Cray’s `cc` wrapper but uses the intel compiler\).
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2753/add-carpetx-thorn…
#2754: Inconsistent definition of B in evolution thorns
Reporter: Samuel Cupp
Status: new
Milestone:
Version:
Type: bug
Priority: minor
Component: EinsteinToolkit thorn
Comment (by Erik Schnetter):
I am surprised that there is no consensus about `HydroBase`; this should be documented in that thorn. Given historic precedence, I would go with the definition used in `GRHydro`.
`HydroBaseX` should then use the same definition.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2754/inconsistent-defi…
#2754: Inconsistent definition of B in evolution thorns
Reporter: Samuel Cupp
Status: new
Milestone:
Version:
Type: bug
Priority: minor
Component: EinsteinToolkit thorn
GRHydro and IllinoisGRMHD use different definitions for several quantities. This is mostly fine, as IllinoisGRMHD converts `vel` to get its desired velocity variable. However, the magnetic variable `B` also differs between these two thorns by a factor of `sqrt(4pi)`. This means that GRHydro couldn't use, for example, initial data from the Seed\_Magnetic\_Fields thorns without rescaling them. Without an expectation for what `B` is, diagnostic thorns that need this variable will produce incorrect results if used with anything except for the evolution thorn they were designed for. Presumably, all the WVUThorns are using IlliniosGRMHD’s `B`, and GRHydro\_InitData uses GRHydro’s `B`. Anything that isn't explicitly tied to an evolution thorn would be ambiguous. Is there a consensus on what `B` in HydroBase is expected to be?
Especially with the transition to CarpetX, having a single definition for B would likely help keep thorns mutually compatible.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2754/inconsistent-defi…
#2753: Add CarpetX thorns to Einstein Toolkit manifest
Reporter: Erik Schnetter
Status: new
Milestone:
Version:
Type: proposal
Priority: major
Component: Other
Comment (by Erik Schnetter):
I corrected the missing ExternalLibraries and disabled the PoissonX thorn.
I am looking for guidance regarding C\+\+17. I can see several ways forward:
* Update currently supported machines, possibly removing some old machines from the list
* Disabling CarpetX by default everywhere
* Explicitly disabling CarpetX on those machines that don’t support C\+\+17 \(possibly many machines\) and updating others
Sam, do you have a list of machines that you consider “high priority” for the release?
-erik
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2753/add-carpetx-thorn…
#2753: Add CarpetX thorns to Einstein Toolkit manifest
Reporter: Erik Schnetter
Status: new
Milestone:
Version:
Type: proposal
Priority: major
Component: Other
Comment (by Samuel Cupp):
As I said on the PR, this also has the issue that PoissonX inherits from PDESolvers, which is disabled. They probably should both be disabled or both enabled.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2753/add-carpetx-thorn…
#2753: Add CarpetX thorns to Einstein Toolkit manifest
Reporter: Erik Schnetter
Status: new
Milestone:
Version:
Type: proposal
Priority: major
Component: Other
Comment (by Roland Haas):
This would currently “do harm” and prevent the thorn list from compiling for \(at least\) two reasons:
* CarpetX and AMReX require C\+\+17 which is not enabled by any \(?\) of the option lists that ship with Simfactory in the ET
* the thornlist lacks that ExternalLibraries required to compile CarpetX
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2753/add-carpetx-thorn…
#2752: Parameter file parser generates illegal (?) C code
Reporter: Erik Schnetter
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Changes (by Roland Haas):
component: EinsteinToolkit thorn (was Cactus)
Comment (by Roland Haas):
Most likely this is a “\\phi” \(ie LaTeX syntax\) in one of the parameter descriptions of TwoPunctures\_BBHSF. Those get copied to C strings and will then trigger this.
The simplest solution is to not use LaTeX code in Cactus description strings \(or double up on the backslash\). A better solution \(in Cactus\) may to sanitize strings passed in by users, but is only doable if there are not yet thorns that that double up the backslash already \(right now `grep -rF '\\' arrangements///*.ccl` returns none\).
Cheng-Hsin and Giuseppe are maintainers, but Bitbucket will not let me enter Cheng-Hsin into the assignee field \(even though he is a teammate\) and Giuseppe does not seem to be a team member.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2752/parameter-file-pa…