[Users] Meeting Minutes

[Ian Hinder]

On 29 Sep 2014, at 10:38, Roland Haas <rhaas at tapir.caltech.edu> wrote:

> * interpolation in MoL substeps: need more input from Ian

Hi Roland,

Could you elaborate on what this means?  I assume this is about https://trac.einsteintoolkit.org/ticket/1656?

Eloisa and I had a long discussion about how to integrate grid arrays in MoL a few days ago, and we came up with a plan.  Regarding the interpolator, it requires that we perform the interpolation in MoL_CalcRHS in level mode, and set the RHS only on the level containing the grid point to be interpolated.  This is necessary, because the MoL_Add must occur directly after the RHSs are set (not in global-last), and the interpolation must happen while MoL has modified the current timelevel to contain, e.g., the k_i variables of RK4.  This is similar to what Erik proposed, but differs in that we need to perform the integration/interpolation on levels other than the finest.  I think you can get this information from Carpet (i.e. which level "owns" a particular point).  So, our requirements are to interpolate in MoL_CalcRHS in level mode, and to make use of data only from the "current" refinement level.  Ideally, the call to the interpolator would enforce this, so that it would be an error to access data from other levels (they won't have been correctly modified by MoL).

For anyone interested, the following is the plan we came up with to allow grid arrays to be integrated using the interpolator and MoL:

	- Evolution thorn asks Carpet which level owns the current interpolation point, and how often (evolve_every) that level is evolved.  
	- Add a tag to each evolved array group to tell Carpet not to cycle timelevels.  This tag also disables poisoning of these groups.  
	- Evolution RHS called in level mode but only does an interpolation on the level that owns the particle (otherwise leaving the RHSs zero as initialised by MoL). 
	- Split out the array integration from MoL_Add into MoL_AddArrays and schedule this in level mode (MoL_Add is in local mode, which means more than one call if you have more than one component per process).  The add will happen on all levels, but the RHS will be zero for all levels except the one we want to evolve on.  The evolution will then use the data which has just been set on the right level.  When it is on the right level, it will add with a timestep appropriate to that level, and hence advance the solution to the next iteration that this level exists on.  
	- At some point, we will want to change the "evolve_every" quantity for a given particle in the evolution thorn, as it moves between refinement levels.  We need to be very careful not to introduce a first order error here.  I think it is enough to make sure that we only CHANGE evolve_every on an "evolved" iteration (according to the old evolve_every)

-- 
Ian Hinder
http://numrel.aei.mpg.de/people/hinder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20140930/0f857ff1/attachment.bin