#2952: GRHayLET/IllinoisGRMHD convert_*_to_*.c magnetic sector subleties
| Reporter: | Maxwell Rizzo |
| Status: | new |
| Milestone: | |
| Version: | |
| Type: | bug |
| Priority: | minor |
| Component: | EinsteinToolkit thorn |
Comment (by Leonardo Rosa Werneck):
Hi Maxwell! Thanks for pointing these out!
phitilde = Aphi, I agree that this is misleading. Although I don't see anything in the HydroBase documentation that states that Aphi is defined without the sqrt{gamma} 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 Aphi to zero initially. This can definitely be fixed.1/sqrt(4pi), I would point to the discussion surrounding Eqs. (A9) and (A10) of the GRHayL paper. Since this affects only the definition of the magnetic field itself, I think rescaling only Avec is correct, but let me know if you find a reasoning to also rescale Aphi.Ax/Ay/Az being staggered, I don't know of a way to remedy this. Our initial data thorns (such as Seed_Magnetic_Fields) "borrow" Avec as auxiliary storage. Although one can argue this is incorrect and that they could initialize Ax/Ay/Az 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 Avec with either staggered or vertex-centered data. We'd be happy to discuss alternatives, if you'd like to propose any.Avec/Aphi, this can be added, but the usefulness is less clear to me. While having them in the HydroBase -> GRHayLET conversion enables users to more easily utilize our initial data thorns, having them in the GRHayLET -> HydroBase seems less useful/redundant, as users can output Ax/Ay/Az/phitil
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2952/grhaylet-illinoisgrmhd-convert_-_to_-c