<div dir="ltr">Yosef<div><br></div><div>One easy way is to look at CarpetReduce: It will ignore points that are invalid. There is a grid function CarpetReduce::weight that specifies how much a point should contribute towards reductions; if the weight is zero, then the points is either an outer boundary, a buffer zone, or will be overwritten by restriction. The sum of all weights (modulo the level's grid spacing) is the volume of the simulation domain. The weight is 1 for "regular points", 0 for points that should be ignored, and a fraction of 1 for points near refinement and near outer boundaries.</div><div><br></div><div>I don't recall whether the weight is zero in inter-process boundaries and symmetry boundaries; it may not be, but you can use cctk_bbox and cctk_nghostzones in the usual way to exclude these.</div><div><br></div><div>-erik</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 19, 2015 at 10:51 AM, Yosef Zlochower <span dir="ltr"><<a href="mailto:yosef@astro.rit.edu" target="_blank">yosef@astro.rit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm working on a thorn that uses local interpolations to<br>
get the RHS for the geodesic evolution. I have an issue when points<br>
get too close (or inside of) buffer zones (because then the RHS won't<br>
contain correct data during the MoL ministeps). How can I determine<br>
if the interpolation stencil around a given point contains any buffer<br>
zone points?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 08/11/2015 03:06 PM, Yosef Zlochower wrote:<br>
> Thanks for the help. I guess if I used interpolation in time the<br>
> geodesics would only be accurate to 2nd order.<br>
><br>
> On 08/11/2015 09:15 AM, Ian Hinder wrote:<br>
>><br>
>> On 6 Aug 2015, at 16:48, Yosef Zlochower <<a href="mailto:yosef@astro.rit.edu">yosef@astro.rit.edu</a><br>
>> <mailto:<a href="mailto:yosef@astro.rit.edu">yosef@astro.rit.edu</a>>> wrote:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> I was looking for advice on implementing an integrator for timelike<br>
>>> and null geodesics during an ET simulation. The confusion I have is<br>
>>> how to deal with AMR. Ideally, I'd like to use RK4 and MoL, but I<br>
>>> foresee several issues with geodesics crossing from coarser to finer<br>
>>> and finer to coarser zones. I do have a horrible hack that may possibly<br>
>>> be used, but it seems overly convoluted to me. Basically, I update the<br>
>>> grid arrays in MoL in local mode, and unless the local grid happens to<br>
>>> be the finest grid that owns the geodesic, I set RHS to zero (there are<br>
>>> additional hacks because MoL copies the past time level onto the<br>
>>> current one automatically). But<br>
>>> still there is the issue of geodesics crossing AMR boundaries. In<br>
>>> particular, when moving from fine to coarse, the geodesic may end up<br>
>>> being behind because the finer grid may be at an earlier time than the<br>
>>> coarser one.<br>
>>><br>
>>> One possible workaround would be to update<br>
>>> the geodesics during every iteration on the finest level. This would<br>
>>> imply that I would need to interpolate the metric, shift, and lapse<br>
>>> (and their derivatives) during each ministep of the finest level even<br>
>>> if the point being interpolated doesn't exist on the finest level.<br>
>><br>
>>> This, in turn, means that the carpet would need to interpolate those<br>
>>> points in time during the ministep where the local time will at some<br>
>>> intermediate time between cctk_time(old) and cctk_time(new). I don't<br>
>>> think this works correctly in the current version of carpet.<br>
>><br>
>> Correct. The time used by the interpolator for time interpolation is<br>
>> not consistently cctk_time, so when MoL modified this variable during<br>
>> MoL_CalcRHS, this is ignored by CarpetInterp. See the discussion in<br>
>> <a href="https://trac.einsteintoolkit.org/ticket/1656" rel="noreferrer" target="_blank">https://trac.einsteintoolkit.org/ticket/1656</a>, and a patch with a<br>
>> parameter which makes it use cctk_time.<br>
>><br>
>>> An alternative method I was considering was a second-order in time<br>
>>> integration. For this, I would need to be able to interpolate the<br>
>>> metric and its derivatives during the current (finest level) time and<br>
>>> the previous (finest level) time. For the moment, I'd be happy to<br>
>>> assume that the finest refinement level will not change during the<br>
>>> evolution.<br>
>><br>
>> "It's complicated".<br>
>><br>
>> I describe an approach in<br>
>> <a href="http://lists.einsteintoolkit.org/pipermail/users/2013-November/003280.html" rel="noreferrer" target="_blank">http://lists.einsteintoolkit.org/pipermail/users/2013-November/003280.html</a><br>
>> (the archive page seems to not know about line wrapping).<br>
>><br>
>> --<br>
>> Ian Hinder<br>
>> <a href="http://members.aei.mpg.de/ianhin" rel="noreferrer" target="_blank">http://members.aei.mpg.de/ianhin</a><br>
>><br>
><br>
><br>
<br>
<br>
--<br>
Dr. Yosef Zlochower<br>
Center for Computational Relativity and Gravitation<br>
Associate Professor<br>
School of Mathematical Sciences<br>
Rochester Institute of Technology<br>
85 Lomb Memorial Drive<br>
Rochester, NY 14623<br>
<br>
Office:74-2067<br>
Phone: <a href="tel:%2B1%20585-475-6103" value="+15854756103">+1 585-475-6103</a><br>
<br>
<a href="mailto:yosef@astro.rit.edu">yosef@astro.rit.edu</a><br>
<br>
CONFIDENTIALITY NOTE: The information transmitted, including<br>
attachments, is intended only for the person(s) or entity to which it<br>
is addressed and may contain confidential and/or privileged material.<br>
Any review, retransmission, dissemination or other use of, or taking<br>
of any action in reliance upon this information by persons or entities<br>
other than the intended recipient is prohibited. If you received this<br>
in error, please contact the sender and destroy any copies of this<br>
information.<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a><br>
<a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">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></div>
</div>