Dear ET folks,<br><br>This email is to continue the discussion we
started during our seminar earlier today. The main reason we could not
comment about collaborating more closely with ET is because we had not
discussed this previously and furthermore not all of us were present on
the conference call. (We have agreed that all of us should give input
before making big decisions, such as contributing our code.) Having now
discussed the issue with everyone, we are all very keen to contribute to
the ET project where we can, as its success will be useful for our own
future work, much as the basic Cactus-Carpet infrastructure has proven
helpful in the past.<br>
<br>Here is our current thinking:<br><br><br>* Background<br><br>As you
know, our latest GRMHD code evolves the vector potential A. The vector
potential prescription we use carefully staggers all four components of
the vector potential A, so that in unigrid the magnetic field B^i
evolution is _equivalent_ to the standard, staggered
constrained-transport scheme. A-field evolutions enable us to use any
interpolation scheme we like at AMR refinement boundaries. However,
there is a subtlety: Carpet does not have built-in
prolongation/restriction operators for these staggered gridfunctions.<br>
<br>* Prolongation/Restriction Modifications to Carpet<br><br>To handle
this problem, we modified some of the existing Carpet Lagrange
prolongation/restriction code to instead interpolate the gridfunctions
at the appropriate staggered gridpoints. Each of the four A-field
components has its own staggering, so there are eight new pieces of code
-- one for prolongating & restricting each component of A. We also
have multiple interpolation schemes coded up, and each one may be
switched on by a #define statement.<br>
<br>In terms of infrastructure, the rest is pretty much bookkeeping;
each A-field component is stored as any other gridfunction, but we must
be careful when using A-field information because e.g., Ax[i,j,k] on the
grid actually stores Ax[i,j+1/2,k+1/2].<br>
<br>* Contributing to ET<br><br><span style="color: rgb(0, 0, 0);">Though it may not be compliant with the ET coding standards (e.g., we only handle the "double" data type), our
changes to the Carpet infrastructure have been thoroughly tested, and we
would be willing to contribute this code to the ET SVN. In return, we
would like to work more closely with those of you who have access to the
multipatch "cubed-spheres" code. Would you be willing to share this
code with us?</span><br style="color: rgb(0, 0, 0);">
<br>Sincerely,<br>The Illinois Numerical Relativity Group<br>-Zach Etienne<br>-Yuk Tung Liu<br>-Vasilis Paschalidis<br>-Stu Shapiro<br>