[Einstein Toolkit] #1238: implement buffer mask in CarpetEvolutionMask

List overview All Threads
Download

newer

older

[Einstein Toolkit] #1397: make...

[Einstein Toolkit] #1391: Remove...

Einstein Toolkit

30 Jan 2013 30 Jan '13

1:22 p.m.

#1238: implement buffer mask in CarpetEvolutionMask ---------------------------------+------------------------------------------ Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: CarpetEvolutionMask | ---------------------------------+------------------------------------------ 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.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Show replies by date

Einstein Toolkit

30 Jan 30 Jan

1:23 p.m.

#1238: implement buffer mask in CarpetEvolutionMask --------------------------+------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: Component: Carpet | Version: Resolution: | Keywords: CarpetEvolutionMask --------------------------+------------------------------------------------- Changes (by rhaas):

* status: new => review

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:1 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

2:36 p.m.

Comment (by hinder):

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

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:2 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

31 Jan 31 Jan

5:49 p.m.

Comment (by rhaas):

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.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:3 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

1 Feb 1 Feb

2:06 a.m.

Comment (by hinder):

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.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:4 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

2:13 a.m.

Comment (by anonymous):

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 dh::regrid.cc 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]).

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:5 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

8:29 a.m.

Comment (by eschnett):

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

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:6 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

3:45 p.m.

Comment (by rhaas):

I had not really though of it but yes there is a variable dd.local_boxes.at(mglevel).at(reflevel).at(local_component).buffers 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.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:7 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

3:54 p.m.

Comment (by eschnett):

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.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:8 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

5 p.m.

Comment (by rhaas):

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?

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:9 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

7 Feb 7 Feb

10:38 a.m.

Comment (by eschnett):

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).

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:10 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

11 Feb 11 Feb

3:15 p.m.

#1238: implement buffer mask in CarpetEvolutionMask --------------------------+------------------------------------------------- Reporter: rhaas | Owner: rhaas Type: enhancement | Status: assigned Priority: minor | Milestone: Component: Carpet | Version: Resolution: | Keywords: CarpetEvolutionMask --------------------------+------------------------------------------------- Changes (by rhaas):

* owner: eschnett => rhaas * status: review => assigned

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.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:11 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

Einstein Toolkit

29 Jun 29 Jun

8:55 p.m.

Comment (by rhaas):

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.

-- Ticket URL: https://trac.einsteintoolkit.org/ticket/1238#comment:12 Einstein Toolkit http://einsteintoolkit.org The Einstein Toolkit

4849

Age (days ago)

5000

Last active (days ago)

trac@lists.einsteintoolkit.org

12 comments

1 participants

tags (0)

participants (1)

Einstein Toolkit