<html>#1805: triggers statement does not include reductions output
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Wolfgang Kastaun</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>ET_2014_05</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>Other</td></tr>
</table>
<p>Comment (by Roland Haas):</p>
<p>I note that computing variables whose reductions are being computed (for output or otherwise) only every once in a while and not at every timestep is very firmly in the “<a data-is-external-link="true" href="https://motd.ambians.com/quotes.php/name/linux_computers/toc_id/1-1-4/s/881#882" rel="nofollow">give you rope to hang yourself with, and then some more</a>” territory. Technically should be supported though (and I thought there are the required <code>CCTJ_TriggerFoo</code> calls in <code>CarpetIOScalar</code>).</p>
<p>The only way to get away with it somewhat safely is to compute (and output) only every coarse step (if not computing every single step of course). Everything else stands a danger of using stale / invalid data on past timelevels if and when interpolation in time happens. This also implies (well mostly) that the computed quantity must be computable in a pointwise manner, not involving any stencil operations (to avoid having to restrict and prolongate) to avoid different results obtained when computing every step and output every coarse or computing and outputting every coarse.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/1805/triggers-statement-does-not-include'>https://bitbucket.org/einsteintoolkit/tickets/issues/1805/triggers-statement-does-not-include</a></p>
</html>