Roland
Not, it isn't! The dh class stores
light_mboxes light_boxes; // grid hierarchy [ml][rl][c] local_mboxes local_boxes; // grid hierarchy [ml][rl][lc] fast_mboxes fast_boxes; // grid hierarchy [ml][rl][p]
where the light boxes (light, little content) contain information about every component (even remote ones), the local boxes contain (much more) information about the process-local components, and the fast boxes (misnomer) contain the (process-local relevant part of the) communication schedule.
We could store also the per-level information. I assume it is much smaller, since it contains information only about levels (and not components):
level_mboxes level_boxes; // grid hierarchy [ml][rl]
and then clear the data structure instead of declaring it in dh::regrid, i.e. treat it similar to fast_mboxes instead of similar to full_mboxes.
There is another data structure, full_mboxes, which contains all the information you ever wanted to know about everything in the grid hierarchy. However, this costs too much memory, and is therefore only allocated temporarily for a single level, and is freed again right after it has been used. This distinction between these different kinds of information and not storing all of it is what makes hg Carpet faster and use less memory.
-erik
On Mon, Jun 6, 2011 at 6:44 AM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello Ian, Erik,
Could the routine GetAllActive be replaced by just accessing level_dboxes::active?
It could yes. GetAllActive computes level_dboxes::active (it dpulicates code from dh.cc, expanding the code in one of the bboxset constructors taking a vector and a pointer-to-member as arguments). I am not sure though if this information is actually stored anywhere outside of dh::regrid (in level_boxes and the various references to parts of it). Erik: is the "active" information stored permanently anywhere?
Yours, Roland
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users