[Users] question about ML_BSSN::fixAdvectionTerms

[Erik Schnetter]

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 at 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 at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20160929/10ee63be/attachment.html