<html>#2651: New warning message for missing boundary conditions
<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>task</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td>Carpet</td></tr>
</table>
<p>Changes (by Samuel Cupp):</p>
<p>I have made a pull request adding a warning inside ApplyPhysicalBCsForGroupI for when variables have no boundary conditions registered. Originally, there was a <em>cout</em> statement only if a preprocessor flag was defined. I have found that this warning helped me discover several mistakes that would have been very difficult to track down without it. The associated pull request is <a data-is-external-link="true" href="https://bitbucket.org/eschnett/carpet/pull-requests/53/carpet-added-warning-for-non-existent" rel="nofollow">here</a>.</p>
<p>For example, it made me realize that I never properly changed over BaikalVacuum’s BC selection to also register boundary conditions with the driver. If I had put this comment in earlier, my confusion about why the code was trying to sync+apply BCs way too often would have been instantly solved.</p>
<p>As another example, one function in BaikalVacuum reads one group everywhere and another interior. I had both everywhere, but the interior-only one has no BCs because it is only ever read on the interior. As such, I was triggering syncs for no reason. This warning pointed me to the real problem in my simulation very quickly, and this was causing my code to sync variables 24 (RK4 * variables in group) times more per iteration.</p>
<p>Finally, it led to me finding that MoL’s scheduling was trying to sync scalars (see <a data-is-external-link="true" href="https://bitbucket.org/einsteintoolkit/tickets/issues/2650/fixing-write-statements-for-mol-scalars" rel="nofollow">Ticket #2650</a>). While not a performance issue like the above, this is incorrect behavior.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2651/new-warning-message-for-missing-boundary'>https://bitbucket.org/einsteintoolkit/tickets/issues/2651/new-warning-message-for-missing-boundary</a></p>
</html>