Giulia
Let me make a few more guesses:
- How do the lapse gauge driver parameters look like? Did you rescale them as well? - How does the apparent horizon position / shape / coordinate radius behave before this happens?
-erik
On Fri, Nov 29, 2019 at 6:33 AM Giulia Crotti g.crotti1@campus.unimib.it wrote:
Dear all, thanks for the suggestions. Indeed the problem seems to be occurring on the finest grid, because the lapse is wrong on the finest level. We did try changing the ML_BSSN::BetaDriver parameter from 0.71 to 0.25 (in order to make it ~1/M_BH), but the result was pretty much the same.
Cheers, Giulia
Il giorno mer 27 nov 2019 alle ore 16:27 Erik Schnetter schnetter@cct.lsu.edu ha scritto:
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
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Erik,
As for your first question, we are setting the following parameters:
ML_BSSN::harmonicN = 1 ML_BSSN::harmonicF = 2.0 ML_BSSN::ShiftGammaCoeff = 0.75 ML_BSSN::BetaDriver = 0.25 # ~1/M_BH ML_BSSN::advectLapse = 1.0 ML_BSSN::advectShift = 1.0
ML_BSSN::MinimumLapse = 1.0e-8 ML_BSSN::initial_boundary_condition = "extrapolate-gammas" ML_BSSN::rhs_boundary_condition = "NewRad"
As you can see, we are not setting the lapse gauge driver parameter, leaving it to be the default (which is 0). We choose to do this because this was consistent with BNS simulations that Bruno did.
For your second question, I attach two plots of the BH position on the xy plane and its coordinate radius. Thanks again,
Giulia
Il giorno lun 2 dic 2019 alle ore 04:45 Erik Schnetter schnetter@cct.lsu.edu ha scritto:
Giulia
Let me make a few more guesses:
- How do the lapse gauge driver parameters look like? Did you rescale
them as well?
- How does the apparent horizon position / shape / coordinate radius
behave before this happens?
-erik
On Fri, Nov 29, 2019 at 6:33 AM Giulia Crotti g.crotti1@campus.unimib.it wrote:
Dear all, thanks for the suggestions. Indeed the problem seems to be occurring on the finest grid, because the lapse is wrong on the finest level. We did try changing the ML_BSSN::BetaDriver parameter from 0.71 to 0.25 (in order to make it ~1/M_BH), but the result was pretty much the same.
Cheers, Giulia
Il giorno mer 27 nov 2019 alle ore 16:27 Erik Schnetter schnetter@cct.lsu.edu ha scritto:
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
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Giulia
Without knowing more about the setup, I assume that the horizon should have a constant radius. It might grow initially if the gauge condition on the initial conditions is different from the one using during evolution. If you are still stuck with resolving this issue, then we could schedule a brief telecon, as this would allow me to ask questions more directly than here via email.
-erik
On Mon, Dec 2, 2019 at 5:49 AM Giulia Crotti g.crotti1@campus.unimib.it wrote:
Erik,
As for your first question, we are setting the following parameters:
ML_BSSN::harmonicN = 1 ML_BSSN::harmonicF = 2.0 ML_BSSN::ShiftGammaCoeff = 0.75 ML_BSSN::BetaDriver = 0.25 # ~1/M_BH ML_BSSN::advectLapse = 1.0 ML_BSSN::advectShift = 1.0
ML_BSSN::MinimumLapse = 1.0e-8 ML_BSSN::initial_boundary_condition = "extrapolate-gammas" ML_BSSN::rhs_boundary_condition = "NewRad"
As you can see, we are not setting the lapse gauge driver parameter, leaving it to be the default (which is 0). We choose to do this because this was consistent with BNS simulations that Bruno did.
For your second question, I attach two plots of the BH position on the xy plane and its coordinate radius. Thanks again,
Giulia
Il giorno lun 2 dic 2019 alle ore 04:45 Erik Schnetter schnetter@cct.lsu.edu ha scritto:
Giulia
Let me make a few more guesses:
- How do the lapse gauge driver parameters look like? Did you rescale
them as well?
- How does the apparent horizon position / shape / coordinate radius
behave before this happens?
-erik
On Fri, Nov 29, 2019 at 6:33 AM Giulia Crotti g.crotti1@campus.unimib.it wrote:
Dear all, thanks for the suggestions. Indeed the problem seems to be occurring on the finest grid, because the lapse is wrong on the finest level. We did try changing the ML_BSSN::BetaDriver parameter from 0.71 to 0.25 (in order to make it ~1/M_BH), but the result was pretty much the same.
Cheers, Giulia
Il giorno mer 27 nov 2019 alle ore 16:27 Erik Schnetter schnetter@cct.lsu.edu ha scritto:
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
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Giulia Crotti