[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