[Users] Implementing a simple 1+1 BSSN in Python

[Erik Schnetter]

Chris

What do you mean by "Boundary conditions are not applied"? What do you do
at the boundaries? Are you using one-sided differencing there?

Given your description, I assume that all derivatives would be identically
zero, that there would not even be a floating-point round-off error. Is
that so? If not, why not?

Are you really setting the lapse to zero initially? It should be one for
Minkowski, same as e.g. g_xx.

What happens if you choose a very small grid size (e.g. just 10 points) and
compare the initial conditions between the Einstein Toolkit and the Python
code? Are they identical? You would need to compare ASCII output and
compare all the digits.

What happens if you take a single Euler time step? Are the values still all
identical? Try to find out and which iteration the first grid point differs
between the two codes.

-erik



On Fri, May 13, 2022 at 9:59 PM Chris Stevens <
chris.stevens at canterbury.ac.nz> wrote:

> Hi all,
>
> I've been having trouble implementing the BSSN equations, as given by
> CTGamma, in Python using the package COFFEE, which I am very familiar with:
>
> https://gitlab.com/thebarista/coffee
> https://doi.org/10.1016/j.softx.2019.100283
>
> The main comments are:
>
> -- For simplicity, I am starting with a 1+1 code (set 2/3 spatial
> derivatives to be exactly zero).
> -- The 1+log slicing for the lapse and a zero shift.
> -- The "phi" conformal factor type
> -- The evolution equations are written to Python by a very slight
> modification of the .m file in CTGEvolution. I've confirmed this .m file
> outputs the same file that is in the src directory.
> -- The vanishing of the trace of A is enforced after each full timestep in
> the same way as CTGamma.
> -- Boundary conditions are not applied.
> -- Fourth order SBP operators that lean over toward the boundaries are
> used.
> -- Minkowski initial data with all fields zero except \gamma11/22/33.
> -- Euler step is used for time integration to easier compare between
> Python and the Einstein toolkit.
>
> This leads to a stable evolution in the Einstein toolkit with the attached
> .par file using a simple one patch Cartesian grid. However, in Python, I
> get that fields diverge, starting at the boundaries and then propagating
> inward (including with RK4). This behaviour does not go away with higher
> resolution or reduced CFL. It is however, fixed completely by setting the
> second spatial derivative of \alpha to be exactly zero. Trying many
> different SBP FD operators that have proved successful for other projects
> has not changed the behaviour.
>
> The COFFEE code has been used and tested in a variety of projects and so
> there should not be a problem here. Thus, the only thing I can think of, is
> that the Einstein toolkit is doing something that I am not realizing, that
> is helping it remain stable. Hopefully, somebody on this mailing list might
> have an idea?
>
> Thanks in advance,
>
> Chris
>
>
>
>
>
>
>
> *Dr Chris Stevens*
>
> *Lecturer in Applied Mathematics*
>
> Rm 602, Jack Erskine building
>
> School of Mathematics and Statistics
>
> T: +64 3 369 0396 (Internal 90396)
>
> University of Canterbury | Te Whare Wānanga o Waitaha
>
> Private Bag 4800, Christchurch 8140, New Zealand
>
> http://www.chrisdoesmaths.com
>
> *Director*
> SCRI Ltd
> http://www.scri.co.nz
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>


-- 
Erik Schnetter <schnetter at gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20220513/e74d90b4/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-zot52qe4.png
Type: image/png
Size: 13436 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220513/e74d90b4/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-sdnm0er0.png
Type: image/png
Size: 17337 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220513/e74d90b4/attachment-0003.png