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?
-erik
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.
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:
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).
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.
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.
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.
-erik
On Tue, Jan 29, 2013 at 12:20 PM, Erik Schnetter schnetter@cct.lsu.eduwrote:
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?
-erik
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
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/
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:
1. 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
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,
Peter
On 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
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
On 29 Jan 2013, at 18:20, Erik Schnetter schnetter@cct.lsu.edu 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.
This brings up a question I've been wondering about for a while. A huge percentage of the discussion of the ET is happening on TRAC rather than on this mailing list. This keeps things tidy, with each conversation attached to a single ticket. Anyone is free to subscribe to the TRAC mailing list (see einsteintoolkit.org) and to view the tickets. However, it means that most of the discussion of the ET is not seen by most of the users. What can we do about this?
One logical distinction is between "users" and "developers" of the ET. Users will subscribe to this mailing list, and developers will see the tickets. Some have said in the past that there should be no distinction between these two groups. I suspect that not everyone currently subscribed to the users' list would like to receive the volume of ticket notifications that we currently generate! Maybe we just need to be better at identifying issues which are of interest to users and well as developers. Would it work to add the users' mailing list to the CC of such tickets?
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Ian Hinder -
John Baker -
Peter Diener