<div dir="ltr">Hi Erik,<div><br></div><div>On Sun, Nov 2, 2014 at 11:24 AM, Erik Schnetter <span dir="ltr"><<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Whether A^i lives on the same grid points as the metric or is<br>
staggered is part of its definition. Differing definitions should be<br>
stored in different grid functions, even if this seems to lead to a<br>
duplication. Cactus used to have different definitions of the metric,<br>
and used to store them in the same grid functions. There was a<br>
(slightly complex) mechanism that defined and recorded which<br>
definition was currently active. This led to errors, as people either<br>
didn't get the mechanism for choosing the metric definition right, or<br>
didn't add the respective checks and conversions into their code.<br>
<br>
Defining a new grid function is cheap, and we should store the<br>
different discretizations of A^i in such a way.<br></blockquote><div><br></div><div>Sounds good. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Currently, Carpet cannot handle different prolongation operators for<br>
different grid variables in the same group. This should probably<br>
change. (Does it with your proposed changes?) We also need to see how<br>
this affects symmetry conditions.<br></blockquote><div><br></div><div>Currently in IllinoisGRMHD, we define four groups for A_{\mu}, each containing one gridfunction that stores a single component of A_{\mu}. We do this because each component is staggered differently, and Carpet does not support individually different staggerings for variables within a single group, even with our changes. As a first step, I prefer keeping it this way, so as to avoid introducing any bug into Carpet prior to release, but in the end it's up to you. </div><div><br></div><div>Regarding symmetry conditions, we had to write our own symmetry conditions to handle A_{\mu}, and at best only bitant symmetry across the z=0 plane is supported. Better symmetry support is planned for IllinoisGRMHD, moving away from the CartSymGN() function calls. In the meantime, IllinoisGRMHD is in a feature freeze until the code announcement paper is completed.</div><div> </div><div>-Zach</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
<br>
On Thu, Oct 30, 2014 at 1:51 PM, Zach Etienne <<a href="mailto:zachetie@gmail.com" target="_blank">zachetie@gmail.com</a>> wrote:<br>
> Dear ET folks,<br>
><br>
> I have written a small thorn that converts HydroBase and ADMBase variables<br>
> into the variables IllinoisGRMHD needs to perform a GRMHD evolution. This<br>
> conversion works just fine on all variables... except the vector potential.<br>
><br>
> As you may be aware, IllinoisGRMHD requires that A_t (=\sqrt{\gamma} \Phi),<br>
> A_x, A_y, and A_z each be staggered differently (a la Table I of<br>
> <a href="http://arxiv.org/abs/1007.2848" target="_blank">http://arxiv.org/abs/1007.2848</a>).<br>
><br>
> However, HydroBase does not support defining such staggered A-fields. Thus<br>
> it is currently impossible to modify/create GRMHD initial data thorns so<br>
> that vector potential data produced by them can be directly read in by<br>
> IllinoisGRMHD. For example, if an initial data thorn only outputs the vector<br>
> potential on grid vertices, then an interpolation will need to be performed<br>
> to staggered gridpoints. This will introduce truncation errors that,<br>
> depending on the A-field structure and needed grid resolutions, may be<br>
> severe. I conclude that this is _not_ The Right Strategy. The Right Strategy<br>
> would not break any existing thorn as a first step, either.<br>
><br>
> So as a first step, I believe we should modify HydroBase so that<br>
> 1) A new set of four, 3-timelevel groups are defined, one for each component<br>
> of the vector potential<br>
> 2) The prolongation type can be specified differently for each of the four<br>
> vector potential gridfunction groups, allowing for arbitrary staggerings of<br>
> the single variable within each of these groups.<br>
><br>
> Variables in these groups will be read in by IllinoisGRMHD and can be used<br>
> directly for evolutions.<br>
><br>
> Regarding the longer-term strategy, we could either<br>
><br>
> 1) modify Carpet so that different components of Avec() (the current<br>
> 3-vector potential group in HydroBase) can accept different<br>
> prolongation/restriction operators (then modifying IllinoisGRMHD to accept<br>
> this new vector gridfunction), or<br>
><br>
> 2) just keep the four, 3-timelevel groups and phase out Avec() and Aphi<br>
> altogether.<br>
><br>
> Even the latter strategy would not be difficult to implement in current<br>
> publicly available thorns:<br>
><br>
> After a simple grep, I could only find a single initial data thorn that<br>
> actually sets Avec, so the needed changes to public initial data thorns<br>
> should be minimal. Further, I am under the impression that Avec evolutions<br>
> are not yet supported in GRHydro anyway, and found only about 40 references<br>
> to the Avec() gridfunctions within GRHydro, so renaming these variables to a<br>
> new style would be trivial.<br>
><br>
> Please let me know your thoughts regarding this proposal. The IllinoisGRMHD<br>
> code announcement paper is nearing completion, and at least having the<br>
> infrastructure for this code in place by the next ET release would be great.<br>
> In this regard, I have already asked Erik if he would be willing to merge<br>
> the staggered prolongation/restriction code into the mainline Carpet for the<br>
> next ET release. The soft freeze is Nov 10, these new features affect none<br>
> of Carpet's other functionality, and I have thoroughly tested these new<br>
> features with GRMHD evolutions, verifying that they work well.<br>
><br>
> Please consider the possibility of adding these small infrastructure<br>
> enhancements prior to the freeze.<br>
><br>
> Sincerely,<br>
><br>
> -Zach<br>
><br>
> * * *<br>
> Zachariah Etienne<br>
> Assistant Professor of Mathematics<br>
> West Virginia University<br>
><br>
</div></div>> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@einsteintoolkit.org" target="_blank">Users@einsteintoolkit.org</a><br>
> <a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br>
><br>
<span><font color="#888888"><br>
<br>
<br>
--<br>
Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br>
<a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a><br>
</font></span></blockquote></div><br></div></div>