<html>#2549: inlcude FLRWSolver in ET
<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>ET_2022_05</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>major</td></tr>
<tr><td style='text-align:right'>Component:</td><td></td></tr>
</table>
<p>Comment (by Hayley Macpherson):</p>
<p>Chi - thanks for your review! I’ve addressed your comments, see below:<br>
1. Thanks for this, you’re right there was a minus sign missing which I’ve now fixed<br>
2. I’ve changed the name of this variable from kvalue → kdiag_bg, since it represents the diagonal value of the extrinsic curvature K_ij for the background (not the trace)<br>
3. Yes, you are correct that this choice of gauge means that for the background we have alpha → a and therefore coordinate time can be more or less interpreted as conformal time. I don’t think this choice of evolving lapse will give numerical errors (which I don’t see, as far as I can tell), because the actual time evolution is dependent on the time step in terms of coordinate time, dt, which is set via the grid spacing and the chosen Courant factor. This time step does not change as the lapse evolves, and I don’t think the lapse will have an impact here. I could be wrong, so <span class="ap-mention" data-atlassian-id="557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22">@Roland Haas</span> please correct me if so! </p>
<p>Thanks again for your time and for helping with this on such short notice!</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolver-in-et'>https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolver-in-et</a></p>
</html>