#2174: Test "Multi Patch Scalar Wave Equation" example
Reporter: Roland Haas
Status: open
Milestone: ET_2022_05
Version: development version
Type: task
Priority: major
Component: EinsteinToolkit website
Comment (by Roland Haas):
Hrishikesh Kalyanaraman will handle this gallery example for ET\_2022\_11
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2174/test-multi-patch-…
#2656: PreSync syncing more than old code
Reporter: Samuel Cupp
Status: new
Milestone:
Version: development version
Type: bug
Priority: major
Component: Carpet
Comment (by Samuel Cupp):
I’m also considering the possibility that this could be because the read/writes on two of the functions aren’t right. I based them on the loops \(everywhere\), but I think the floor\_the\_lapse and enforce\_detgammahat functions actually only need to be read/write \(interior\). I have to carefully count the number of syncs per iteration to figure this out.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2656/presync-syncing-m…
#2173: Test "Poisson equation" example
Reporter: Roland Haas
Status: open
Milestone: ET_2021_11
Version: development version
Type: task
Priority: major
Component: EinsteinToolkit website
Comment (by Roland Haas):
@{6345b6047d10ef7914928a58} will take care of this test for ET\_2022\_11
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2173/test-poisson-equa…
#2173: Test "Poisson equation" example
Reporter: Roland Haas
Status: open
Milestone: ET_2021_11
Version: development version
Type: task
Priority: major
Component: EinsteinToolkit website
Changes (by Roland Haas):
responsible: [] (was )
assignee: Nadine Kuo (was )
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2173/test-poisson-equa…
#2656: PreSync syncing more than old code
Reporter: Samuel Cupp
Status: new
Milestone:
Version: development version
Type: bug
Priority: major
Component: Carpet
Comment (by Samuel Cupp):
As an update, commenting out these set\_valids stops the syncs from happening. So, something here is changing the behavior of the code. Are we sure that this is what we want to do here? @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235}
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2656/presync-syncing-m…
#2656: PreSync syncing more than old code
Reporter: Samuel Cupp
Status: new
Milestone:
Version: development version
Type: bug
Priority: major
Component: Carpet
I have been investigating the source of the slowdown for the evolution of a BBH using BaikalVacuum when PreSync is turned on. The largest problem was reported in [Ticket #2653](https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-triggering-syncs-for-all), but the code is still noticeably slower than without PreSync. I have tracked the extra sync calls to restriction. There is one group which is only written, never read. In the old way, these syncs were manually scheduled in the schedule.ccl. PreSync \(properly\) syncs this group at restriction at every refinement level. The observed behavior shows it
1\. Syncs the group aux\_variables from the coarsest to finest level
Then, it begins heading back up the levels, presumably to begin the restriction operation. However, it then
2\. syncs the groups aux\_variables and evol\_variables from finest to coarsest, skipping the finest level
The syncs in 2 are not present in the old way. Either the old way wasn’t properly syncing during restriction, or PreSync is introducing extra syncs into this operation. I’m inclined to believe the latter. My guess as to the possible source of this is the code
```
// Restrict a refinement level
void ggf::ref_restrict_all(comm_state &state, int const tl, int const rl,
int const ml) {
if (transport_operator == op_none or transport_operator == op_sync)
return;
static Timer timer("ref_restrict_all");
timer.start();
// Require same times
assert(std::fabs(t.get_time(ml, rl, tl) - t.get_time(ml, rl + 1, tl)) <=
1.0e-8 * (1.0 + std::fabs(t.get_time(ml, rl, tl))));
transfer_from_all(state, tl, rl, ml, &dh::fast_dboxes::fast_ref_rest_sendrecv,
tl, rl + 1, ml);
timer.stop(0);
// Update state, both fine and coarse bcome invalid in the boundaries
// coarse b/c fine was restricted to it, fine b/c prologation from coarse
// will change values
int const coarse_old_valid = valid(ml, rl, tl);
set_valid(ml, rl, tl,
coarse_old_valid & ~(CCTK_VALID_GHOSTS|CCTK_VALID_BOUNDARY));
int const fine_old_valid = valid(ml, rl, tl);
set_valid(ml, rl + 1, tl,
fine_old_valid & ~(CCTK_VALID_GHOSTS|CCTK_VALID_BOUNDARY));
}
```
which sets the validities to be interior only at the end. I’ll verify that this code triggers the syncs and comment with more info when I have it.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2656/presync-syncing-m…