<html>#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Samuel Cupp</td></tr>
<tr><td style='text-align:right'> Status:</td><td>new</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td></td></tr>
<tr><td style='text-align:right'> Type:</td><td>bug</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>major</td></tr>
<tr><td style='text-align:right'>Component:</td><td>Carpet</td></tr>
</table>
<p>Comment (by Samuel Cupp):</p>
<p>I haven’t yet run a simulation with a lot of reflevels, but I verified that this code doesn’t call <code>SyncProlongateGroups</code> except for the current reflevel when coarser levels don’t need to be synced. Thus, it is equivalent to commenting out the loop. The only added time will be from looping over the groups and comparing ints at each reflevel, which should be negligible. I’ll run the BaikalVacuum with this and check performance.</p>
<p>Since I don’t have a code where the coarser levels aren’t synced before getting to the finer level, I can’t do a ‘real’ test of the case where this loop is actually necessary. I’m still not convinced that’s something that can happen without a thorn having incorrect reads/writes.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-triggering-syncs-for-all'>https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-triggering-syncs-for-all</a></p>
</html>