<html>#2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates
<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>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>major</td></tr>
<tr><td style='text-align:right'>Component:</td><td>EinsteinToolkit thorn</td></tr>
</table>
<p>Outflow incorrectly used <code>sf_centroid</code> as the origin point for the spherical surface it computes fluxes on. However for <code>SphericalSurface</code> the surface is defined with respect to <code>sf_origin</code> via <code>sf_radius[ind2d]</code> .</p>
<p>This pull request fixes this and also introduces a runtime parameter to chose between <code>sf_centroid</code> and <code>sf_origin</code>. The former is useful if one also sets <code>override_radius</code>if eg the sphericalsurface is really just a tracker position.</p>
<p>Thankfully for the common case where there are either a set of spheres centered on on the coordinate origin or spheres following a neutron star via tracking we usually have <code>sf_origin</code> and <code>sf_centroid</code> being identical. However flow through an apparent horizon would be incorrect. I would suspect that <code>sf_origin</code> is the centroid of the previous horizon find result.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2889/outflow-uses-incorrect-sf_centroid-to'>https://bitbucket.org/einsteintoolkit/tickets/issues/2889/outflow-uses-incorrect-sf_centroid-to</a></p>
</html>