[Users] Problem with CarpetRegrid2/AMR

[Erik Schnetter]

On Thu, Dec 15, 2011 at 4:18 PM, Eloisa Bentivegna
<bentivegna at cct.lsu.edu>wrote:

> On Dec 15, 2011, at 9:50 PM, Hal Finkel wrote:
>
> > Can you be more specific?
>
> I think that what Erik is suggesting is to fill all the grid parts that
> are not covered by the SetLevelMask calculation. These entail:
>
> 1) The interprocessor and mesh refinement boundaries, which are filled by
> requiring that level_mask is synchronised upon exit from SetLevelMask
> (basically this is done by adding "SYNC: level_mask" to the schedule block
> for SetLevelMask in schedule.ccl);
> 2) The symmetry boundaries, which are filled by applying the corresponding
> conditions right after SetLevelMask (this is accomplished by scheduling the
> SelectBoundConds function and ApplyBCs group, in this order, after
> SetLevelMask).
>
> It's worth stressing that this approach doesn't currently work for me; I
> plan on taking a closer look in the next few days.
>
> > And is a sufficient number just to make sure
> > that no one processor holds to opposing faces of the cube?
>
> Yes. I'm not sure whether this number can be calculated a priori,
> especially in the case where the grid is worked out at runtime and may be
> quite dynamical. However, I'm reviewing Erik's patch introducing some login
> in Periodic to check exactly this. With this patch, you'll know (a
> posteriori) whether you have a sufficient number of processors.
>

The rule is that you need at least as many processes as there are
components on a level. Otherwise, one process will hold more than one
component, and this is not handled correctly by the periodic boundary
conditions -- some boundary values will remain unset.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20111215/9e2c9a21/attachment.html