<html>#2516: Different simulation result with different number of cores setting
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td></td></tr>
<tr><td style='text-align:right'> Status:</td><td>open</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td></td></tr>
<tr><td style='text-align:right'> Version:</td><td>ET_2019_10</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></td></tr>
</table>
<p>Comment (by Ken Hui):</p>
<p>That really sounds bad.. I shall assume this potential “bug” is not easy to be found.. My original thought on this after seeing the separate self-consistent data group was that there might be somehow some intrinsic selection rules on the core number, that’s why I have tried using 17 cores to run while hoping to see it give weird results, but out of expectation the data from this also fit into one of the two data groups.</p>
<p>Well at least allow me to make sure I have understood the following correctly:</p>
<ol>
<li>The MoL parameter you mentioned earlier looks to be related to recovery, so there is no need to try setting that to test.</li>
<li>The “<em>The grid structure is inconsistent. It is impossible to continue.”</em> error I had for using 64 cores is probably simply because I have request too many cores.</li>
<li>There is no explicit rule for choosing the number of cores in Cactus. I had thought that setting some ugly number N (let say 17) might give me bad result because the domain cannot be well divided into N parts.</li>
</ol>
<p></p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2516/different-simulation-result-with-different'>https://bitbucket.org/einsteintoolkit/tickets/issues/2516/different-simulation-result-with-different</a></p>
</html>