Hello,
I'm wondering if anybody can tell me about the ML_BSSN::fixAdvectionTerms parameter (which I think was new in Somerville). I have been trying to reproduce some old results and discovered this morning that having this parameter set to "off" is what was causing the discrepancy.
What does it do? The description "Modify driver and advection terms to work better?" is vague enough I don't know what to make of it. From McLachlan_BSSN.m it looks like it's switching how the advection terms in the 1+log and Gamma-driver conditions are handled. What changes is it making to these equations? And what is the purpose of them? If setting the parameter to "on" reproduces old results (and if it lives up to its name and fixes things), should "on" be the default behavior?
Thanks.
Kyle Slinker
Hi Kyle,
I am not sure the origin of this parameter, but it is indeed necessary. With fixAdvectionTerms=0, the evolution of the time derivative of the lapse A is given by
partial_t A = (partial_t - Lie_beta) K - A
where K is the trace of the extrinsic curvature, beta is the shift, and Lie is the Lie derivative. It turns out that this prescription is incompatible with 1+log slicing. Worse, if you try to impose 1+log like gauge conditions the gauge for a static black hole will in fact be dynamic. In other words, the coordinates will evolve.
To get 1+log slicing, you need to set fixAdvectionTerms=1, which gives the prescription
( partial_t - Lie_beta ) A = (partial_t - Lie_beta) K
which is compatible with 1+log slicing and with a static coordinate system for a black hole.
As you can see, it's called "fixAdvectionTerms" because it changes the partial time derivative of A into an advective total derivative.
I'm not sure the origin of the parameter so I don't know the reason for the current default settings. Somebody else should have some insight there.
Best, Jonah
On 16-09-29 12:47 PM, Slinker, Kyle Patrick wrote:
Hello,
I'm wondering if anybody can tell me about the ML_BSSN::fixAdvectionTerms parameter (which I think was new in Somerville). I have been trying to reproduce some old results and discovered this morning that having this parameter set to "off" is what was causing the discrepancy.
What does it do? The description "Modify driver and advection terms to work better?" is vague enough I don't know what to make of it. From McLachlan_BSSN.m it looks like it's switching how the advection terms in the 1+log and Gamma-driver conditions are handled. What changes is it making to these equations? And what is the purpose of them? If setting the parameter to "on" reproduces old results (and if it lives up to its name and fixes things), should "on" be the default behavior?
Thanks.
Kyle Slinker _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Kyle
To my knowledge -- and it seems I am mistaken here -- the previous behaviour corresponds to the "off" setting.
The parameter chooses between two variants for handling the advection terms in the lapse and shift evolution equations. Since these are gauge conditions, there is no "right" or "wrong" here, only historic precedence. Both lapse and shift can be evolved as PDEs that are first order in time, or second order in time, introducing new variables A and B^i that correspond to the time derivatives of lapse alpha and shift \beta^i. When this parameter is "on", then switching between first and second order equations does not change the gauge evolution equations, if the driver terms are neglected.
The driver terms in the gauge conditions choose how lapse and shift should look like in equilibrium. This term is different in the first order and second order formulation, and is the reason why people might want to use a second order formulation that otherwise only adds complexity. In a first order formulation, the lapse condition drives the gauge condition towards K=0 (maximal slicing), and the shift condition drives the gauge condition towards \tilde\Gamma^i=0 ("shear free"). Combined, this ensures that a Minkowski spacetime will end up in Minkowski coordinates, given appropriate boundary conditions. In a second order formulation, the gauge condition is looser and only drives towards \dot K=0 and \dot\tilde\Gamma^i=0. This is preferable if you have a coordinate system where e.g. K\ne0 (e.g. Kerr-Schild coordinates) or \tilde\Gamma^i\ne0 (don't know for sure -- maybe a highly spinning black hole?).
In short -- these days, I always set this parameter to "on". The whole reason the parameter is there is that old versions of the code effectively had set it to "off". Maybe this "old version" is so old that it is now irrelevant, and maybe some intermediate version of the code accidentally didn't have this parameter and implicitly set it to "on".
Regarding default behaviours: In Cactus, the default settings for parameters is not what is good for newcomers or what is least surprising, default values are for backward compatibility, as they allow re-running a parameter file two years later and getting the same result. This is eminently important in the long term.
-erik
On Thu, Sep 29, 2016 at 12:47 PM, Slinker, Kyle Patrick <kslink@live.unc.edu
wrote:
Hello,
I'm wondering if anybody can tell me about the ML_BSSN::fixAdvectionTerms parameter (which I think was new in Somerville). I have been trying to reproduce some old results and discovered this morning that having this parameter set to "off" is what was causing the discrepancy.
What does it do? The description "Modify driver and advection terms to work better?" is vague enough I don't know what to make of it. From McLachlan_BSSN.m it looks like it's switching how the advection terms in the 1+log and Gamma-driver conditions are handled. What changes is it making to these equations? And what is the purpose of them? If setting the parameter to "on" reproduces old results (and if it lives up to its name and fixes things), should "on" be the default behavior?
Thanks.
Kyle Slinker _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Thank you Jonah and Erik for your quick replies! I think I understand better what's going on now.
Kyle
On 09/29/2016 01:53 PM, Erik Schnetter wrote: Kyle
To my knowledge -- and it seems I am mistaken here -- the previous behaviour corresponds to the "off" setting.
The parameter chooses between two variants for handling the advection terms in the lapse and shift evolution equations. Since these are gauge conditions, there is no "right" or "wrong" here, only historic precedence. Both lapse and shift can be evolved as PDEs that are first order in time, or second order in time, introducing new variables A and B^i that correspond to the time derivatives of lapse alpha and shift \beta^i. When this parameter is "on", then switching between first and second order equations does not change the gauge evolution equations, if the driver terms are neglected.
The driver terms in the gauge conditions choose how lapse and shift should look like in equilibrium. This term is different in the first order and second order formulation, and is the reason why people might want to use a second order formulation that otherwise only adds complexity. In a first order formulation, the lapse condition drives the gauge condition towards K=0 (maximal slicing), and the shift condition drives the gauge condition towards \tilde\Gamma^i=0 ("shear free"). Combined, this ensures that a Minkowski spacetime will end up in Minkowski coordinates, given appropriate boundary conditions. In a second order formulation, the gauge condition is looser and only drives towards \dot K=0 and \dot\tilde\Gamma^i=0. This is preferable if you have a coordinate system where e.g. K\ne0 (e.g. Kerr-Schild coordinates) or \tilde\Gamma^i\ne0 (don't know for sure -- maybe a highly spinning black hole?).
In short -- these days, I always set this parameter to "on". The whole reason the parameter is there is that old versions of the code effectively had set it to "off". Maybe this "old version" is so old that it is now irrelevant, and maybe some intermediate version of the code accidentally didn't have this parameter and implicitly set it to "on".
Regarding default behaviours: In Cactus, the default settings for parameters is not what is good for newcomers or what is least surprising, default values are for backward compatibility, as they allow re-running a parameter file two years later and getting the same result. This is eminently important in the long term.
-erik
On Thu, Sep 29, 2016 at 12:47 PM, Slinker, Kyle Patrick <kslink@live.unc.edumailto:kslink@live.unc.edu> wrote: Hello,
I'm wondering if anybody can tell me about the ML_BSSN::fixAdvectionTerms parameter (which I think was new in Somerville). I have been trying to reproduce some old results and discovered this morning that having this parameter set to "off" is what was causing the discrepancy.
What does it do? The description "Modify driver and advection terms to work better?" is vague enough I don't know what to make of it. From McLachlan_BSSN.m it looks like it's switching how the advection terms in the 1+log and Gamma-driver conditions are handled. What changes is it making to these equations? And what is the purpose of them? If setting the parameter to "on" reproduces old results (and if it lives up to its name and fixes things), should "on" be the default behavior?
Thanks.
Kyle Slinker _______________________________________________ Users mailing list Users@einsteintoolkit.orgmailto:Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter <schnetter@cct.lsu.edumailto:schnetter@cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Jonah Miller -
Slinker, Kyle Patrick