implement buffer mask in CarpetEvolutionMask

Create issue
Issue #1238 open
Roland Haas created an issue

the attached patch implements a new integer valued grid function carpetevolutionmask::buffer_mask which is set to 1 in buffer regions and 0 otherwise. It provides a testcase. Eventually I would like to add other values such that the number correlates with the last MoL step for which this point needs to be valid before MoL_CalcRHS but for which one cannot compute a RHS in MoL_CalcRHS.

Keyword: CarpetEvolutionMask

Comments (12)

  1. Ian Hinder
    • removed comment

    Excellent! This will be useful for stripping buffer points during visualisation and analysis of data.

  2. Roland Haas reporter
    • removed comment

    Unless objections are raised I will take Ian's excellent as a "please commit" and commit this patch on Sunday or with the next batch of GRHydro patches.

  3. Ian Hinder
    • removed comment

    Ahem. That was not my intention! I have just looked at the code though, and I don't see anything particularly objectionable. Would it be useful to add a parameter controlling storage of the mask, so that people who don't want/need it don't have it taking up more memory? Probably best if someone who knows more about the internals of carpet reviewed it as well though. For example, I have no idea if the calculation of which points are "buffer points" is accurate. I had always thought that this was a very fuzzy concept.

  4. anonymous
    • removed comment

    I was half hoping to provoke someone with Carpet internal knowledge to look at it (Erik however said he'd be busy today so I only threatened to commit on Sunday). I'll hold of for proper please apply. :-)

    The buffer calculation is copied out of so is hopefully consistent with what Carpet uses for its communication schedule.

    Being able to control storage might be useful yes. I had briefly thought about it and then rejected it due to causing too many new parameters to be around ("if you don't want the masks, don't activate the mask thorn"). Adding a parameter is simple enough though. I will likely make the parameter default to "yes" though since likely if you benefit from the evolution mask you also benefit from the buffer mask (the buffers do show up as "evolved" points in the evolution mask since at least for some RK substeps their RHS needs to be evaluated and the results their would show up in the restricted output [via the stencils]).

  5. Erik Schnetter
    • removed comment

    I notice that you calculate the buffer points. Isn't there a variable you could look at instead?

  6. Roland Haas reporter
    • removed comment

    I had not really though of it but yes there is a variable that holds an ibset of the local buffers. Patch 0002 uses it and would have the decided advantage of not copying the logic to create the buffer region description to several places in the code.

    However I found that using these buffers is not really what I want. They are computed using the owned points so that ghost zones that are also buffer zones are flagged as non-buffers which is not what I want. My intention is to use the buffer mask to find out where eg. con2prim does not have to run. Since con2prim runs everywhere (also in ghosts and buffers) since it runs after SYNC (since con2prim scales better than a SYNC of the primitives) I need to know if a point is both a buffer and a ghost zone. This seems due to dh::regrid constructing buffers using the "owned" region rather than the "exterior".

    buffers is used in dh::regrid in line 956

              // Prolongation must fill what cannot be synchronised, and
              // also all buffer zones
              needrecv += box.buffers;

    where I believe one currently could use buffers constructed using "exterior" instead of "owned". However this depends on needrecv being set up in the "#else" branch of line 936.

  7. Erik Schnetter
    • removed comment

    If you want to run in buffers or ghosts, then you can take the ibset corresponding to buffers and union it with the bboxes corresponding to ghosts. Ghosts are easy to identify; they are at the faces identified by cctk_bbox and have a width of cctk_nghostzones.

    On the other hand, if you need a weird combination of points which Carpet doesn't already identify, then you may as well use your own logic here.

    Note: The notion of "buffer points" is well defined in Carpet. The regridding algorithm (i.e. CarpetRegrid2) is supposed to specify a refined region that includes buffer points. Carpet will then take the outermost layer nbufferzones wide, and call these "buffer points". The remaining points are called "active".

    The exact rules are slightly more complex. For example, ghost points are added around the buffer points except at outer boundaries. Also, buffer points exist only near refinement boundaries, not near outer boundaries. Furthermore, there are "overlap points" between the active and the buffer points that I ignored in my description above. However, there is a well-defined algorithm determining which points are classified as what.

  8. Roland Haas reporter
    • removed comment

    I seem to want something non-standard. What I would like is the intersection of allbuffers (as defined in dh::regrid) and local_boxes...exterior. What is stored in local_boxes.buffers is allbuffers intersected with local_boxes...owned (and the difference between owned and exterior are the ghosts, yes?). Using just the information in local_boxes I guess I could get what I want by first setting up the buffer_mask using local_boxes...buffers, then do a low-level sync() call (or set prolongation_type = copy and do a SYNC in schedule.ccl). Would that be an acceptable method?

  9. Erik Schnetter
    • removed comment

    I suggest that you experiment with CarpetEvolutionMask until you have something that fits your needs, then we clean up the code. That is, commit your changes if they don't break the build and if they don't interfere with others who are using this thorn. Since I don't, I will let someone else approve this patch, or let you commit if you think the patch is ready (in this sense).

  10. Roland Haas reporter
    • changed status to open
    • assigned issue to
    • removed comment

    I applied option 1 together with a controlling parameter to CarpetEvolutionMask in commit 4e166b68d40ec9ced2acdbebaccace667f6f6eeb "CarpetEvolutionMask: compute a mask indicating where buffers are". Keeping the ticket open until a final state is reached.

  11. Roland Haas reporter
    • removed comment

    The current attempt (option 1) is incorrect since it does not properly take the outer layer of ghost zones in a mesh refined level into account (got confused by the VisIt not showing the outer layer of ghost zones). I have a more functional version that I am testing, one that also shows the MoL substep.

  12. Log in to comment