I'm working on a thorn that uses local interpolations to get the RHS for the geodesic evolution. I have an issue when points get too close (or inside of) buffer zones (because then the RHS won't contain correct data during the MoL ministeps). How can I determine if the interpolation stencil around a given point contains any buffer zone points?
On 08/11/2015 03:06 PM, Yosef Zlochower wrote:
Thanks for the help. I guess if I used interpolation in time the geodesics would only be accurate to 2nd order.
On 08/11/2015 09:15 AM, Ian Hinder wrote:
On 6 Aug 2015, at 16:48, Yosef Zlochower <yosef@astro.rit.edu mailto:yosef@astro.rit.edu> wrote:
Hi,
I was looking for advice on implementing an integrator for timelike and null geodesics during an ET simulation. The confusion I have is how to deal with AMR. Ideally, I'd like to use RK4 and MoL, but I foresee several issues with geodesics crossing from coarser to finer and finer to coarser zones. I do have a horrible hack that may possibly be used, but it seems overly convoluted to me. Basically, I update the grid arrays in MoL in local mode, and unless the local grid happens to be the finest grid that owns the geodesic, I set RHS to zero (there are additional hacks because MoL copies the past time level onto the current one automatically). But still there is the issue of geodesics crossing AMR boundaries. In particular, when moving from fine to coarse, the geodesic may end up being behind because the finer grid may be at an earlier time than the coarser one.
One possible workaround would be to update the geodesics during every iteration on the finest level. This would imply that I would need to interpolate the metric, shift, and lapse (and their derivatives) during each ministep of the finest level even if the point being interpolated doesn't exist on the finest level.
This, in turn, means that the carpet would need to interpolate those points in time during the ministep where the local time will at some intermediate time between cctk_time(old) and cctk_time(new). I don't think this works correctly in the current version of carpet.
Correct. The time used by the interpolator for time interpolation is not consistently cctk_time, so when MoL modified this variable during MoL_CalcRHS, this is ignored by CarpetInterp. See the discussion in https://trac.einsteintoolkit.org/ticket/1656, and a patch with a parameter which makes it use cctk_time.
An alternative method I was considering was a second-order in time integration. For this, I would need to be able to interpolate the metric and its derivatives during the current (finest level) time and the previous (finest level) time. For the moment, I'd be happy to assume that the finest refinement level will not change during the evolution.
"It's complicated".
I describe an approach in http://lists.einsteintoolkit.org/pipermail/users/2013-November/003280.html (the archive page seems to not know about line wrapping).
-- Ian Hinder http://members.aei.mpg.de/ianhin