[Users] Problem with CarpetRegrid2/AMR

Hal Finkel hfinkel at anl.gov
Thu Dec 15 14:14:03 CST 2011


On Thu, 2011-12-15 at 11:17 -0500, Erik Schnetter wrote:
> Eloisa
> 
> 
> Thanks for digging into this.
> 
> 
> I didn't think of syncing, but yes, syncing would be necessary, and so
> would be setting all boundaries. In your case, this would be applying
> periodic boundary conditions only (and not setting anything to zero
> since you don't have an outer boundary). Of course, you need to use
> sufficiently many processes for this because of the bug in thorn
> Periodic.

Erik, Eloisa, et al.,

Thank you very much for looking at this. Just so that I'm clear, is
there a way that I can get this to work now, or am I waiting on another
bug fix?

 -Hal

> 
> 
> -erik
> 
> On Thu, Dec 15, 2011 at 9:39 AM, Eloisa Bentivegna
> <bentivegna at cct.lsu.edu> wrote:
>         On Dec 15, 2011, at 5:58 AM, Hal Finkel wrote:
>         
>         > On Wed, 2011-12-14 at 19:48 -0500, Erik Schnetter wrote:
>         >> On Wed, Dec 14, 2011 at 6:53 PM, Hal Finkel
>         <hfinkel at anl.gov> wrote:
>         >>        On Wed, 2011-12-14 at 18:27 -0500, Erik Schnetter
>         wrote:
>         >>> You are not setting any values on the boundary. Is that
>         >>        intentional?
>         >>
>         >>
>         >>        Currently, this is because I am using neighboring
>         values in
>         >>        the
>         >>        calculation, so I can't do that on the boundary.
>         Should I do
>         >>        that some
>         >>        other way?
>         >>
>         >>
>         >> Setting the boundary to zero should be good enough. (The
>         boundary
>         >> values should not be used -- but I don't recall whether
>         this is the
>         >> case.)
>         >
>         > Maybe this is another problem with the periodic boundary
>         conditions?
>         > The problem seems to appear in other fields too. I've
>         attached some
>         > images from my test problem. One shows the field
>         configuration (this one
>         > looks like a ring -- it is a slice through  a bubble). The
>         second one
>         > shows the T_00 computed from that. As you can see, the
>         values near the
>         > extremal indicies are wrong. At the next (half) time step,
>         looking at
>         > the field data from level 1, the same phenomonon can be seen
>         in the
>         > level 1 boxes.
>         >
>         > These were all done in Kranc, so I did not do any real
>         coding myself ;)
>         >
>         > What do you think?
>         
>         
>         Hi all!
>         
>         I believe that what Hal is doing with the allocation of
>         level_mask is correct; what seems to be problematic is setting
>         its value.
>         
>         The problem is that this function cannot be calculated
>         pointwise, and the way it's currently set leaves some parts of
>         the grid uninitialized, which then leads to poison and
>         ultimately to all sorts of weird behavior including nans at
>         the boundaries, lack of regridding when expected, and so on. I
>         wouldn't pay too much attention to all these symptoms
>         (although it would be nice of course for the AMR logic to
>         detect that the mask is nan and issue an error message). The
>         origin is in the incomplete initialization of the mask.
>         
>         To convince myself of this, I switched poisoning off, and
>         observed no odd behavior. I then switched it back on and ran a
>         number of grid configurations where the mask was set pointwise
>         (say, to coincide with one of the evolution variables), and
>         again I had no trouble. As for the actual mask (based on the
>         derivative of a grid function), I played a long time with
>         scheduling the filling of interior points and boundaries, but
>         always observed the issue that Hal is reporting. Ideally, I'd
>         think that filling the interior, syncing, and finally applying
>         outer/symmetry boundary conditions would work, but that
>         doesn't seem to be the case.
>         
>         Erik: when you suggest to set the boundary explicitly, do you
>         mean the outer boundary? Since in this case we only have a
>         symmetry boundary (periodic), do you mean we should populate
>         that part of the grid independently of the symmetry thorn?
>         
>         Thanks,
>         Eloisa
> 
> 
> 
> 
> -- 
> Erik Schnetter <schnetter at cct.lsu.edu>
> http://www.cct.lsu.edu/~eschnett/
> 
> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory



More information about the Users mailing list