<html>#2957: Discussion: Support multiple centering options for Cactus/CarpetX Grid Functions
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Maxwell Rizzo</td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>enhancement</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td></td></tr>
</table>
<p>Continuing a discussion from a few CarpetX calls:</p>
<p>Current Cactus/CarpetX supports Grid Functions (GFs) with a single selected choice of centering (cell centered ccc, vertex centered vvv, face centered/edge centered). </p>
<p>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.</p>
<p>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. </p>
<p>Current workarounds are:</p>
<ol>
<li>
<p>The user can exchange GFs between thorns that have mismatches in centerings, being careful of differences in shape.</p>
</li>
<li>
<p>The user can couple the thorns directly and remove the BaseX handoff for those GFs, adding a thorn dependency and storing near redundant GFs. </p>
</li>
<li>
<p>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.</p>
</li>
</ol>
<p>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.</p>
<p>Possible generic
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2957/discussion-support-multiple-centering'>https://bitbucket.org/einsteintoolkit/tickets/issues/2957/discussion-support-multiple-centering</a></p>
</html>