Hi Erik,
Great questions.
- Is it necessary to have an explicit conversion thorn? Couldn't these routines be simply part of IllinoisGRMHD? For example, McLachlan uses its own variable, and contains its own routines to convert from/to ADMBase.
IllinoisGRMHD is designed to maximize user-friendliness, and to this end one of my goals is to minimize the amount of source code inside IllinoisGRMHD that is not directly related to GRMHD evolution. Thus if possible, I would prefer not incorporating functionality from these thorns into IllinoisGRMHD.
- If the routines really need to exist in two thorns, then I suggest having the actual routines in only one place, and calling the routines from the other place. (I probably completely missed the original motivation.) If necessary, you would need to introduce a third thorn containing these routines that these two thorns can call.
I would prefer not adding another thorn if possible, as I want to minimize the effort required by a new user to read and understand the IllinoisGRMHD evolution code. If they need to hunt in other thorns for needed functions, learning IllinoisGRMHD would require more effort. I could also raise a performance objection, in that the compiler may not be able to optimize as well if functions deep within loops exist in other thorns.
Here's a promising alternative: I just looked at the two compatibility-layer thorns in a bit more detail. Turns out there are a total of 2 functions from within IllinoisGRMHD that are needed by these two compatibility-layer thorns. If I make these two functions share-able in IllinoisGRMHD/interface.ccl, they can be accessed from the other thorns, right? Two complications:
1) these functions depend on a number of other functions within IllinoisGRMHD, so would this linkage work?
2) there is a header file "IllinoisGRMHD_headers.h" that is needed by both thorns...
In the end, as described in the IllinoisGRMHD trac ticket (https://trac.einsteintoolkit.org/ticket/1796)
I would like to move IllinoisGRMHD to a wider arrangement (called WVUThorns, for example), because it will be the first of many thorns my research team and I intend to contribute to the Toolkit. So if all these IllinoisGRMHD-related thorns exist in the same arrangement, maybe symbolic links aren't the worst possible option. git seems to have no problem handling them.
- Would scheduling "IN initial AFTER HydroBase_Initial" work?
Not sure; I will need to try this.
- Similarly, there should be a group HydroBase_SetHydroBaseVars where the respective routine should be scheduled. I think half of the functionality that is present in ADMBase is still missing from HydroBase since, so far, there was only one thorn (... or two very similar thorns ...) that used HydroBase. Feel free to suggest the respective extensions to HydroBase, modelled after ADMBase if possible.
This is a neat idea, and brings up another item on my TODO list: HydroBase currently does not allow for any input as to the staggering of the A-fields. Currently IllinoisGRMHD must define its own A-field variables in individual variable groups because the prolongation type for Avec in HydroBase is not independently specifiable for the different components of A. In addition to adding a group HydroBase_SetHydroBaseVars, it would also be nice to generalize the specification of A-fields.
Thanks, and have a great afternoon.