NaNs in ADMBase::gxx using Development Version of ET

Issue #905 new
Yosef Zlochower created an issue

While testing the CCE in the ET, I stumbled across an issue interpolating the admbase::metric at CCTK_POSTSTEP in GLOBAL mode at particular spatial points.

The "bug" (or parfile/scheduling error) seems to be sensitive to the exact grid setup. Basically, when I use the qc0-mclachlan-CCE_Cauchy.par parfile, I get nans for gxx. I made a small test thorn that only interpolates gxx at a particular point. Nans show up at iteration 1.

attached is the parfile I used and the test thorn.

Here is the output from the above test thorn: gxx(3.966899,0.000000,-17.630662) = 1.1160523626974641 at iter 0 on proc 1 gxx(3.966899,0.000000,-17.630662) = 1.1160523626974641 at iter 0 on proc 0 gxx(3.966899,0.000000,-17.630662) = -nan at iter 8 on proc 1 gxx(3.966899,0.000000,-17.630662) = -nan at iter 8 on proc 0 gxx(3.966899,0.000000,-17.630662) = -nan at iter 16 on proc 1 gxx(3.966899,0.000000,-17.630662) = -nan at iter 16 on proc 0

etc....

Keyword:

Comments (3)

  1. Erik Schnetter
    • removed comment

    It may be that the past timelevels are not correctly initialised. Could you output all timelevels of both the ADMBase and the ML_BSSN variables?

  2. Yosef Zlochower reporter
    • removed comment

    Yes. There are nans in ML_BSSN metric at it=0 in the past two timelevels. They go away if I replace carpet::init_3_timelevels=yes with carpet::init_fill_levels=yes.

    The nans are not in rl=0. They start on rl=1 at the boundary and up to 11 points in for tl=1. for tl=2, the nans are not on the boundary , but start 12 points in.

  3. Log in to comment