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

Mon May 16 00:56:36 CDT 2022

Hi Erik,

I have tried a very coarse grid and found that things diverge slower in Python. So clearly increasing resolution/lowering CFL is not going to help here.

I attach four plots.

-- A plot of \alpha-1 over time at a boundary point in both Python and Einstein toolkit with the coarse grid (11 grid points).
-- A plot of K over time at a boundary point in both Python and Einstein toolkit with the coarse grid (11 grid points).
-- The same as above but with a finer grid (101 grid points).

I have compared the output after one Euler step between ET and Python, and find that the same variables obtain some noise after the first step. For the ET this is around 1e-16 while Python is 1e-13.

As this originates from the boundary, is the Einstein toolkit doing anything other than leaning over the FD stencil when calculating derivatives close to the boundary in my .par file?

Thanks,

Chris

[cid:98cedb4e-cbd5-4959-9b79-826e17767625]

[cid:261600d4-1101-460d-902d-18b65e43dec5]

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<http://www.chrisdoesmaths.com/>

Director
SCRI Ltd
http://www.scri.co.nz<http://www.scri.co.nz/>

________________________________
From: Chris Stevens <chris.stevens at canterbury.ac.nz>
Sent: 14 May 2022 15:22
To: Erik Schnetter <schnetter at gmail.com>
Cc: Einstein Toolkit Users <users at einsteintoolkit.org>
Subject: Re: [Users] Implementing a simple 1+1 BSSN in Python

Hi Erik,

Thanks for your quick response!

I use the none bc type for now, rather than the more complicated radiative bc. I use a stencil that leans over as you approach the boundary. Currently this is a 4th order interior 3rd order sbp fd operator of Strand.

By looking at the output on the boundary in both codes, there are round off level numbers appearing after the first Euler step in multiple variables. There is no use comparing these exactly as they're so small but note that the same variables have these in both codes. These come from taking spatial derivatives.

Sorry, the lapse is initially one.

I have compared output by saving the data in both codes. It seems like, since the first few time steps everything is round off errors, it is hard to see exactly where things start to go wrong.

I will try your small grid and see if that yields anything more obvious.

Thanks,

Chris

________________________________
From: Erik Schnetter <schnetter at gmail.com>
Sent: Saturday, May 14, 2022 3:09:17 PM
To: Chris Stevens <chris.stevens at canterbury.ac.nz>
Cc: Einstein Toolkit Users <users at einsteintoolkit.org>
Subject: Re: [Users] Implementing a simple 1+1 BSSN in Python

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<mailto: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

[cid:180c08545639cddf49f1]

[cid:180c085456481d7e37e2]

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<http://www.chrisdoesmaths.com/>

Director
SCRI Ltd
http://www.scri.co.nz<http://www.scri.co.nz/>

_______________________________________________
Users mailing list
Users at einsteintoolkit.org<mailto:Users at einsteintoolkit.org>
http://lists.einsteintoolkit.org/mailman/listinfo/users

--
Erik Schnetter <schnetter at gmail.com<mailto: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/20220516/c76644b3/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-zot52qe4.png
Type: image/png
Size: 13436 bytes
Desc: Outlook-zot52qe4.png
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220516/c76644b3/attachment-0008.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-sdnm0er0.png
Type: image/png
Size: 17337 bytes
Desc: Outlook-sdnm0er0.png
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220516/c76644b3/attachment-0009.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-lzfreatj.png
Type: image/png
Size: 13436 bytes
Desc: Outlook-lzfreatj.png
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220516/c76644b3/attachment-0010.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-dpmljxrf.png
Type: image/png
Size: 17337 bytes
Desc: Outlook-dpmljxrf.png
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220516/c76644b3/attachment-0011.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alp_coarsegrid.png
Type: image/png
Size: 19224 bytes
Desc: alp_coarsegrid.png
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220516/c76644b3/attachment-0012.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alp_finegrid.png
Type: image/png
Size: 19810 bytes
Desc: alp_finegrid.png
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220516/c76644b3/attachment-0013.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: K_coarsegrid.png
Type: image/png
Size: 18993 bytes
Desc: K_coarsegrid.png
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220516/c76644b3/attachment-0014.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: K_finegrid.png
Type: image/png
Size: 21729 bytes
Desc: K_finegrid.png
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20220516/c76644b3/attachment-0015.png 