Yes, this (i.e. the work-around of scheduling the RHS in level mode, and then only actually executing the routine if this corresponds to global mode) is how I made things work. I haven't tried this recently, though. Maybe a test case would be in order...
Rather straightforward changes to MoL should allow scheduling the RHS in global mode as well, which would then work elegantly. This would probably require to duplicate MoL's integration logic, so that grid functions are integrated in level mode while grid arrays are integrated in global mode.
-erik
On 2013-09-24, at 5:34 , Ian Hinder ian.hinder@aei.mpg.de wrote:
On 23 Sep 2013, at 18:06, Peter Diener diener@cct.lsu.edu wrote:
Hi,
No, you're right. The examples I mentioned are using either uni-grid or multi-patch without AMR. I didn't think of the complication of adding AMR to the mix.
So unless anything has changed, the latest information I have is from Erik's email from September 2007:
On 28 Sep 2007, at 18:10, Erik Schnetter schnetter@cct.lsu.edu wrote:
I am now evolving geodesics with the following work-around:
I use MoL. Each time the RHS is calculated, I check whether the current refinement level is the finest level. If so, the RHS is calculated, otherwise the RHS is set to zero.
The current refinement level is accessed by
interface.ccl: USES INCLUDE: carpet.hh
#include <carpet.hh>
if (Carpet::reflevel == Carpet::reflevels - 1) // do calculation
This works only from C++. The RHS calculating routine has to be scheduled in level mode.
However, I get stuck well before this stage. I try to register the array variable with MoL, but it complains that it is not an array.
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users