Dear All, a student of mine (Giulia Crotti) is having issues running a NS-BH simulation with GRHydro and McLachlan (parfile attached). The problem we are having is with the metric evolution (see attached image for the lapse produced just before the crash) and I don't think I ever saw such a problem. Does any of you have any suggestio?
Approximately around 2000 iterations the simulation crashes with the following error:
ERROR from host r168c12s01.marconi.cineca.it process 0
while executing schedule bin CCTK_EVOL, routine PunctureTracker::PunctureTracker_Track
in thorn PunctureTracker, file /marconi/home/userexternal/gcrotti0/EinsteinToolkit/ET_2018_09/Cactus/arrangements/EinsteinAnalysis/PunctureTracker/src/puncture_tracker.cc:204:
-> Shift at puncture #0 is (-nan,-nan,-nan). This likely indicates an error in the simulation.
Something is wrong with the metric; indeed the lapse function gets larger than 1. We have 9 refinement levels on the black hole, with a resolution of 0.045 on the finest grid. The initial data have been computed as to get a mass ratio = 3; so the black hole mass is ~4 solar masses. The black hole is non-spinning.
Thanks,
Bruno
Hi Bruno,
Not sure if related, but I vaguely recall that the gamma-driver shift gauge condition can become unstable if the timestep exceeds a critical value related to the damping constant eta in the driver. This might happen with 9 levels if the timestep is also increasing by a factor 2 with each level. The solution I remember was to use the same timestep for the few coarsest levels. Do you know if the first occurrence of NANs in the shift happens on the coarsest level?
Cheers, Wolfgang.
On 11/27/19 12:36 PM, Bruno Giacomazzo wrote:
Dear All, a student of mine (Giulia Crotti) is having issues running a NS-BH simulation with GRHydro and McLachlan (parfile attached). The problem we are having is with the metric evolution (see attached image for the lapse produced just before the crash) and I don't think I ever saw such a problem. Does any of you have any suggestio?
Approximately around 2000 iterations the simulation crashes with the following error:
ERROR from host r168c12s01.marconi.cineca.it http://r168c12s01.marconi.cineca.it process 0
while executing schedule bin CCTK_EVOL, routine PunctureTracker::PunctureTracker_Track
in thorn PunctureTracker, file /marconi/home/userexternal/gcrotti0/EinsteinToolkit/ET_2018_09/Cactus/arrangements/EinsteinAnalysis/PunctureTracker/src/puncture_tracker.cc:204:
-> Shift at puncture #0 is (-nan,-nan,-nan). This likely indicates an error in the simulation.
Something is wrong with the metric; indeed the lapse function gets larger than 1. We have 9 refinement levels on the black hole, with a resolution of 0.045 on the finest grid. The initial data have been computed as to get a mass ratio = 3; so the black hole mass is ~4 solar masses. The black hole is non-spinning.
Thanks,
Bruno
--
Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy
email: bruno.giacomazzo@unimib.it mailto:bruno.giacomazzo@unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org http://www.brunogiacomazzo.org/
There are only 10 types of people in the world: Those who understand binary, and those who don't
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
The issue with the time step size (see probably https://arxiv.org/abs/1003.0859) occurs on the coarsest levels only. If the error occurs near the puncture on the fine grid, then this is not the problem.
Some of the gauge parameters have a dimension (e.g. 1/length). The "standard" settings are optimized for M=1. If your black hole mass is very different, then you might need to change them. If you have a total mass of M=4, then the gauge might try to act four times faster than usual, leading to an instability. The cure would then be increased resolution, or changing the respective parameters.
-erik
On Wed, Nov 27, 2019 at 8:52 AM Wolfgang Kastaun physik@fangwolg.de wrote:
Hi Bruno,
Not sure if related, but I vaguely recall that the gamma-driver shift gauge condition can become unstable if the timestep exceeds a critical value related to the damping constant eta in the driver. This might happen with 9 levels if the timestep is also increasing by a factor 2 with each level. The solution I remember was to use the same timestep for the few coarsest levels. Do you know if the first occurrence of NANs in the shift happens on the coarsest level?
Cheers, Wolfgang.
On 11/27/19 12:36 PM, Bruno Giacomazzo wrote:
Dear All, a student of mine (Giulia Crotti) is having issues running a NS-BH simulation with GRHydro and McLachlan (parfile attached). The problem we are having is with the metric evolution (see attached image for the lapse produced just before the crash) and I don't think I ever saw such a problem. Does any of you have any suggestio?
Approximately around 2000 iterations the simulation crashes with the following error:
ERROR from host r168c12s01.marconi.cineca.it http://r168c12s01.marconi.cineca.it process 0
while executing schedule bin CCTK_EVOL, routine PunctureTracker::PunctureTracker_Track
in thorn PunctureTracker, file /marconi/home/userexternal/gcrotti0/EinsteinToolkit/ET_2018_09/Cactus/arrangements/EinsteinAnalysis/PunctureTracker/src/puncture_tracker.cc:204:
-> Shift at puncture #0 is (-nan,-nan,-nan). This likely indicates an error in the simulation.
Something is wrong with the metric; indeed the lapse function gets larger than 1. We have 9 refinement levels on the black hole, with a resolution of 0.045 on the finest grid. The initial data have been computed as to get a mass ratio = 3; so the black hole mass is ~4 solar masses. The black hole is non-spinning.
Thanks,
Bruno
--
Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy
email: bruno.giacomazzo@unimib.it mailto:bruno.giacomazzo@unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org http://www.brunogiacomazzo.org/
There are only 10 types of people in the world: Those who understand binary, and those who don't
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Bruno Giacomazzo -
Erik Schnetter -
Wolfgang Kastaun