<html>#1636: Check and abort if more timelevels are requested than time hierarchy supports
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Roland Haas</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>development version</td></tr>
<tr><td style='text-align:right'> Type:</td><td>enhancement</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>Comment (by Roland Haas):</p>
<p>This will conflict with <a data-is-external-link="true" href="https://bitbucket.org/cactuscode/cactus/commits/599fdd846130713ccc98a8a8f1c38df697804464" rel="nofollow">599fdd84</a> "Cactus: add support for an unlimited number of timelevels" of <a data-is-external-link="true" href="https://bitbucket.org/cactuscode/cactus" rel="nofollow">cactus</a>.</p>
<p>Carpet already effectively contains such a limit in that it will fail during regrid if more time levels exist compared to what it is stored its time hierarchy.</p>
<p>Carpet assuming that timelevels exist only for its benefit and thus having final say on how many may exist is something to decide as well. In practical terms, Carpet needs to able to recompose these past timelevels after a regrid which requires that it knows there time so that time interpolation is possible.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/1636/check-and-abort-if-more-timelevels-are'>https://bitbucket.org/einsteintoolkit/tickets/issues/1636/check-and-abort-if-more-timelevels-are</a></p>
</html>