Hi Peter, I can. I'd like to test it out a little bit though. Give me a day or two. John.
On 2/18/13 10:59 AM, Peter Diener wrote:
Hi John,
If you can give me a patch against the current release version of Jim's changes, I can attempt to generate a patch against the development version that can be applied separately from my patch regarding the gauge evolution. The patches could then be evaluated, tested and potenitally applied separately.
Cheers,
PeterOn Tue, 29 Jan 2013, John Baker wrote:
Hi, Erik mentioned changes that were suggested by Jim van Meter. The variant of the BSSN equations that our group has used for the last several years is slightly different than what is implemented in the trunk version of McLachlan. I'll just copy Jim's description of his original changes:
- You are not taking full advantage of the chi=exp(-2phi) variable. There
are several terms you divide by chi or chi2 in expressions with overall factors exp(-4phi). I rewrote the BSSN equations to make these cancellations before coding. So where you have an expression of the form chi2(A+B/chi2), I have chi2A+B. This gives a slight but noticeable advantage in both accuracy and performance. 2. I added Hamiltonian-constraint-damping terms due to Duez et al. These terms don't seem to be well-known but they are effective. 3. I added a Gamma-constraint-damping term due to Yo et al. 4. I enforce det(g)=1.
Unfortunately McLachlan has evolved for a year since Jim produced his version. Recently I have merged Jim's changes with the current (release) version, though I haven't yet verified the results in simulation tests.
John.
On 1/29/13 12:38 PM, Peter Diener wrote:
Hi all,
On Tue, 29 Jan 2013, Erik Schnetter wrote:
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.
At the moment, we seem to have approximately three different versions of the BSSN code that seem to be incompatible:
- the (official) trunk version
- a version (potentially faster and more accurate) by Jim van Meter
- a more flexible version (regarding gauge conditions) by Peter Diener
I would suggest that we discuss things on this list before we proceed.
John, Peter, could you describe your changes here?
Sure. In response to a long standing ticket #590, I split the gauge evolution routines out from the main RHS routines, in order to be able to schedule gauge evolution routines conditionally on the values of lapse_evolution_method and shift_evolution_method instead of unconditionally always evolve the gauges. This should allow us to evolve spacetimes with static gauges or gauges set by other thorns (for example EinsteinExact). It also makes it easier to add new gauge evolution routines to McLachlan and have the code be more readable. In the process I also moved the advection terms into the new gauge evolution routines since these should only be added if McLachlan is actually evolving the gauge. The dissipation routine was handled similarly.
Cheers,
Peter-erik
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users