[ET Trac] [Einstein Toolkit] #590: McLachlan should allow other thorns to set the gauge

Einstein Toolkit trac-noreply at einsteintoolkit.org
Fri Dec 14 09:37:03 CST 2012

#590: McLachlan should allow other thorns to set the gauge
  Reporter:  bmundim                |       Owner:            
      Type:  defect                 |      Status:  new       
  Priority:  major                  |   Milestone:  ET_2013_05
 Component:  EinsteinToolkit thorn  |     Version:            
Resolution:                         |    Keywords:            

Comment (by eschnett):

 The evolution and gauge equations are combined because one cannot combine
 arbitrary gauge and evolution conditions; stable formulations come as a
 package. Also, in the past, there were not many different gauge conditions
 available -- the choices were essentially whether A and B^i are evolved or
 not, or whether lapse and shift have advection terms.

 We can try splitting thing apart, and look at the performance impact.

 When splitting calculations apart, I worry about repetitive code. We
 already have some of this, e.g. the definition of the inverse metric,
 Christoffel symbols, and Ricci tensor; these are repeated for the
 evolution and the constraint code. We can try the following:
 - Have one "master" pseudo-calculation that defines all quantities,
 storing them in shorthands
 - Each actual calculation "imports" the master calculation, and then has
 access to these quantities
 - I believe Kranc already optimises away unused shorthands.

 For example, I am worried about repeating e.g. the definitions for dot
 [gamma-tilde], or about a scheduling dependencies if we want to read them
 back from grid functions before/after the advection terms have been
 applied, and doing so correctly when the RHS is evaluated either in
 MoL_RHS or at analysis.

Ticket URL: <https://trac.einsteintoolkit.org/ticket/590#comment:5>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit

More information about the Trac mailing list