[ET Trac] #2957: Discussion: Support multiple centering options for Cactus/CarpetX Grid Functions

[Maxwell Rizzo]

#2957: Discussion: Support multiple centering options for Cactus/CarpetX Grid Functions

 Reporter: Maxwell Rizzo
   Status: new
Milestone: 
  Version: 
     Type: enhancement
 Priority: minor
Component: 

Continuing a discussion from a few CarpetX calls:

Current Cactus/CarpetX supports Grid Functions (GFs) with a single selected choice of centering (cell centered ccc, vertex centered vvv, face centered/edge centered). 

Thorns ADMBaseX/HydroBaseX/TmunuBaseX and similar are used in exchanging and providing unified storage for GFs between evolution thorns and diagnostic / initial data thorns. The BaseX thorns makes a centering choice, provides the storage for the GFs, and some initial zeroing routines.

This presents an issue if the user want to use thorn that modifies or claims partial ownership of similar fields from the BaseX thorns, typically an evolution thorn. If this thorn needs a different centering option for one or more GF, it cannot use the BaseX GFs properly from the mismatch in centering. 

Current workarounds are:

1. The user can exchange GFs between thorns that have mismatches in centerings, being careful of differences in shape.

2. The user can couple the thorns directly and remove the BaseX handoff for those GFs, adding a thorn dependency and storing near redundant GFs. 

3. The user can modify their evolution code to properly interpolate back and forth, resulting in near duplicate GFs at different centering, increased memory and decreased performance from the added interpolation.

This issue arises more specifically in different evolution formulations for GRMHD, some use a cell centered magnetic field while others a face centered one. From today's CarpetX call, there was hesitance, as breaking from the convention that a thorn declares single centering GFs could have major implications for compiling/running Cactus/ CarpetX. For the BaseX thorns multiple centerings might be fairly straightforward as the only centering specific actions are the zeroing routines, which are about as trivial as it gets, for more complicated applications of multiple centerings it is less obvious how to proceed.


Possible generic solutions:

1. An opt-in style where all thorns with single centering GFs behave as normal and thorns could declare multiple specific centerings for GFs that are flexible. This probably would be the most invasive Cactus/CarpetX wise, providing the most flexibility.

2. BaseX (or simliar behaving thorns) can provide separate GFs for different supported centerings, say `foo_cellcen` and `foo_vertcen`, and a parameter to toggle the between the two. With conditional storage this can be done as to not reduce the amount of evolved GFs, but does increase the amount of knobs the user needs to turn correctly for BaseX thorns, which should have a minimal amount of runtime parameters.

3. The problem is possibly specific to just HydroBaseX/ADMBaseX/TmunuBaseX, and specific solutions might be simpler than a general one. Liwei suggested that the magnetic field shouldn't be included in HydroBase at all, not qualifying as a pure Hydro quantity.

4. A built in generic interpolation routine into the BaseX thorns to handle the mismatch, basically workaround 3 but centralized into the BaseX thorn to reduce the amount of duplicate implementations. Probably not advisable for similar reasons listed above.

Overall there is no immediate issue, there are current workarounds of direct coupling of thorns bypassing the BaseX thorns, simply using a GF as a different centering than it is, or interpolating. It may be worthwhile to address this in anticipation of future evolution thorns which do not follow the centering conventions set forth by BaseX thorns.

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2957/discussion-support-multiple-centering
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/trac/attachments/20260702/1a5f01d8/attachment.htm>