- removed comment
NaNs in ADMBase::gxx using Development Version of ET
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)
-
-
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.
-
repo owner - removed comment
Is this still a concern or was it tracked down to invalid data on the previous timelevels? Is this possibly related to http://lists.einsteintoolkit.org/pipermail/users/2013-May/003009.html ?
- Log in to 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?