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

Comment (by rhaas):

only those, you are saying it actually respects evolution_method? I am surprised :-)

#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: ------------------------------------+--------------------------------------- Changes (by knarf):

* milestone: => ET_2013_05

Comment:

Making this a release goal, because this can (but should not) be really surprising for users.

#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.

#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 knarf):

Actually - besides the good reasons already mentioned here, the gamma2 shift evolution of BSSN_MoL can be almost achieved with McLachlan with suitable parameters, except a factor the lapse in the source of the shift. Thus, adding that factor (obviously steered by parameter) would 'solve' the specific issue of the gamma2 shift I had - but not other issues like ignoring ADMBase parameters for example.

Also, in case it comes up: adding an 'if' clause to the code is either not an issue or an already existing problem, because the shift evolution does already contain one - for the switch between the 1+log and the harmonic shifts.

#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 knarf):

For the benefit of others: Peter is working on a patch.

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

Comment (by diener):

The above patch attempts to split out the lapse and shift evolution from the main RHS routines. It also implements simpler and much easier routines for Harmonic and 1+log lapse evolution and a routine that implements the gamma2 evolution scheme from BSSN_MoL. The lapse_evolution_method from ADMBase are extended by the values ML_BSSN_Harmonic and ML_BSSN_1+Log in addition to ML_BSSN and the corresponding routines are scheduled conditionally on those values. The choice ML_BSSN results in the same slicing as before. The shift_evolution_method parameter is similar extended by ML_BSSN_gamma2 in addition to the previously available ML_BSSN. The choice ML_BSSN results in the same shift as before. All gauge routines are scheduled after ML_BSSN_RHS1 and ML_BSSN_RHS2 but before ML_BSSN_Advect. The advection terms for the gauges are moved out from ML_BSSN_Advect and into the gauge evolution routines, since the advection terms should only be added if the gauge is evolved. I also moved dissipation for the lapse and shift variables out of ML_BSSN_Dissipation and into separate ML_BSSN_DissipationLapse and ML_BSSN_DissipationShift routines that are only scheduled if McLachlan is doing the gauge evolutions. Dissipation routines are scheduled after the advection routine.

As far as I can see there is not a significant performance difference. Performance may even be a bit better.

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

Comment (by diener):

All the ML_BSSN_Test tests pass. I haven't run the complete ET testsuite set.

#590: McLachlan should allow other thorns to set the gauge ------------------------------------+--------------------------------------- Reporter: bmundim | Owner: diener Type: defect | Status: assigned Priority: major | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by knarf):

* cc: users@… (added)

Comment:

Testing adding the ET users mailing list as CC to this ticket. But for that to work out in trac neatly would mean to respond in trac, not on the mailing list.

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

Comment (by eschnett):

This does not seem to be advanced enough for this release.

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

Comment (by eschnett):

This is a fairly invasive change to a very fundamental thorn. Such a change needs thorough testing.

Peter says above that he didn't run the full set of test cases yet.

This patch is also missing new test cases, both for the general case (everything handled by McLachlan) as well as the new cases (either lapse and/or shift handled by another mechanism). Presumably, one would not just record the new results, but also test that the results are correct, e.g. ensuring convergence with a gauge wave test case.

What other thorn would make use of this functionality? I assume that those who asked for this functionality would be happy to test it with their additional gauge thorns (even if those are private thorns). If there is no one volunteering for such testing, then it would seem that we are developing functionality that is not actually currently needed.

#590: McLachlan should allow other thorns to set the gauge ------------------------------------+--------------------------------------- Reporter: bmundim | Owner: diener Type: defect | Status: assigned Priority: major | Milestone: ET_2014_05 Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by knarf):

* milestone: ET_2013_11 => ET_2014_05