[Users] Contributing staggered prolongation/restriction operators to ET

[Zach Etienne]

Dear ET folks,

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.

Here is our current thinking:


* Background

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.

* Prolongation/Restriction Modifications to Carpet

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.

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].

* Contributing to ET

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?

Sincerely,
The Illinois Numerical Relativity Group
-Zach Etienne
-Yuk Tung Liu
-Vasilis Paschalidis
-Stu Shapiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20111128/373eb506/attachment.html