<html>#1481: Hidden hard-coded limits on max_l_modes and max_vars in Multipole
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Bernard Kelly</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>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td>EinsteinToolkit thorn</td></tr>
</table>
<p>Changes (by Roland Haas):</p>
<p><table>
<tr><td>assignee:</td><td>Roland Haas (was )</td></tr>
<tr><td>responsible:</td><td>[] (was )</td></tr>
</table></p>
<p>The EinsteinAnalysis/Multipole thorn has hard-coded limits (in src/multipole.cc) on the number of grid functions that can be decomposed (max_vars) and how high in polar quantum number this decomposition can go (max_l_modes). However, these are not reflected in the thorn's param.ccl.</p>
<p>In fact, param.ccl contains a parameter "l_max", allowing it to be <em>any</em> positive value, and doesn't test this against max_l_modes until execution of this source. Wouldn't it make more sense to impose max_l_modes immediately at PARAMCHECK?</p>
<p>To make the actual limit on interpolated functions explicit, a number of desired interpolants could be set in param.ccl (like "n_variables") --- limited if necessary to a hard-coded number that appears as a limit in the range. If the user tries to set n_variables too high, it gets caught at PARAMCHECK; if (s)he accidentally includes too many entries in the "variables" parameter, the extra ones would just be silently ignored.</p>
<p><strong>Keyword:</strong> Multipole</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/1481/hidden-hard-coded-limits-on-max_l_modes'>https://bitbucket.org/einsteintoolkit/tickets/issues/1481/hidden-hard-coded-limits-on-max_l_modes</a></p>
</html>