<div dir="ltr"><div style>Following up on my previous email: I want to clean up McLachlan along the lines described below. I have been holding back on this because of the other, unmerged changes, and didn't want to complicate things more.</div>
<div><br></div><div>I want to suggest a simplification of the McLachlan code base that should make it easier to modify/maintain it, and to handle the scheduling. I am thinking of the following approach:</div><div><br></div>
<div>1. There is one master calculation that calculates everything, starting from a full BSSN state vector, and calculating ADMBase variables, RHS, gauges, constraints, etc. This should support all BSSN variants and multiple gauge conditions, probably introducing shorthands to keep things simple (e.g. different shorthands for the RHS for different lapse conditions).</div>
<div><br></div><div>2. From this master calculation, we derive (via PartialCalculation) the individual scheduled routines to calculate the ADMBase variables, to calculate the RHS (combined, split, only lapse, only shift, etc.), constraints, advection terms, dissipation etc.</div>
<div><br></div><div>This will nicely separate physics (the master calculation) from parameter handling (choosing formulation, gauges etc) and optimisation (splitting for performance). It will ensure that there is a single definition of all quantities, avoid duplication, and reduce code size.</div>
<div><br></div><div>This will also simplify optimising the code, if we e.g. need to split the RHS evaluation into three routines, or want to combine it again into a single routine. This will also simplify life for those who want to create a custom version of McLachlan that is e.g. optimised for a particular setup or a particular machine.</div>
<div><br></div><div>-erik<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 29, 2013 at 12:20 PM, Erik Schnetter <span dir="ltr"><<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Please keep all discussion on the McLachlan BSSN code on this mailing list. This ensures that everybody knows about everything that is going on, and avoid duplicate work.</div>
<div><br></div>
<div>At the moment, we seem to have approximately three different versions of the BSSN code that seem to be incompatible:</div><div>- the (official) trunk version</div><div>- a version (potentially faster and more accurate) by Jim van Meter</div>
<div>- a more flexible version (regarding gauge conditions) by Peter Diener</div><div><br></div><div>I would suggest that we discuss things on this list before we proceed.</div><div><br></div><div>
John, Peter, could you describe your changes here?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-erik</div><div><br></div>-- <br>Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br>
<a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a>
</div>