<html>#2952: GRHayLET/IllinoisGRMHD convert_*_to_*.c magnetic sector subleties
<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>bug</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td>EinsteinToolkit thorn</td></tr>
</table>
<p>Comment (by Leonardo Rosa Werneck):</p>
<p>Hi Maxwell! Thanks for pointing these out!</p>
<ul>
<li>Regarding <code>phitilde = Aphi</code>, I agree that this is misleading. Although I don't see anything in the <code>HydroBase</code> documentation that states that <code>Aphi</code> is defined without the <code>sqrt{gamma}</code> factor in it, intuitively that's what I would expect. This has been likely not been a problem because most of our ID thorns set <code>Aphi</code> to zero initially. This can definitely be fixed.</li>
<li>Regarding the factor of <code>1/sqrt(4pi)</code>, I would point to the discussion surrounding Eqs. (A9) and (A10) of the <a data-is-external-link="true" href="https://arxiv.org/pdf/2512.15846" rel="nofollow">GRHayL paper</a>. Since this affects only the definition of the magnetic field itself, I think rescaling only <code>Avec</code> is correct, but let me know if you find a reasoning to also rescale <code>Aphi</code>.</li>
<li>Regarding <code>Ax</code>/<code>Ay</code>/<code>Az</code> being staggered, I don't know of a way to remedy this. Our initial data thorns (such as <code>Seed_Magnetic_Fields</code>) "borrow" <code>Avec</code> as auxiliary storage. Although one can argue this is incorrect and that they could initialize <code>Ax</code>/<code>Ay</code>/<code>Az</code> directly instead, doing that would make it difficult for users to utilize our initial data in their own evolution thorns. Our "solution" was to add a parameter to the ID thorns that allows users to initialize <code>Avec</code> with either staggered or vertex-centered data. We'd be happy to discuss alternatives, if you'd like to propose any.</li>
<li>Regarding repopulating <code>Avec</code>/<code>Aphi</code>, this can be added, but the usefulness is less clear to me. While having them in the <code>HydroBase -> GRHayLET</code> conversion enables users to more easily utilize our initial data thorns, having them in the <code>GRHayLET -> HydroBase</code> seems less useful/redundant, as users can output <code>Ax</code>/<code>Ay</code>/<code>Az</code>/<code>phitil
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2952/grhaylet-illinoisgrmhd-convert_-_to_-c'>https://bitbucket.org/einsteintoolkit/tickets/issues/2952/grhaylet-illinoisgrmhd-convert_-_to_-c</a></p>
</html>