[Einstein Toolkit] #1114: AHFinderDirect fails if one increases the number of horizons after recovery
#1114: AHFinderDirect fails if one increases the number of horizons after recovery -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: AHFinderDirect | -----------------------------------+---------------------------------------- eg. modifying the AHFinderDirect test recoverML like so:
{{{#!diff Index: test/recoverML.par =================================================================== --- test/recoverML.par (revision 1568) +++ test/recoverML.par (working copy) @@ -123,7 +123,7 @@ AHFinderDirect::geometry_interpolator_name = "Hermite polynomial interpolation" AHFinderDirect::geometry_interpolator_pars = "order=3"
-AHFinderDirect::N_horizons = 1 +AHFinderDirect::N_horizons = 2 AHFinderDirect::origin_x[1] = 0.5 AHFinderDirect::origin_y[1] = 0.7 AHFinderDirect::origin_z[1] = 0.0 @@ -133,3 +133,13 @@ AHFinderDirect::initial_guess__coord_sphere__y_center[1] = 0.3 AHFinderDirect::initial_guess__coord_sphere__z_center[1] = 0.0 AHFinderDirect::initial_guess__coord_sphere__radius[1] = 2.0 + +AHFinderDirect::origin_x[2] = 0.5 +AHFinderDirect::origin_y[2] = 0.7 +AHFinderDirect::origin_z[2] = 0.0 + +AHFinderDirect::initial_guess_method[2] = "coordinate sphere" +AHFinderDirect::initial_guess__coord_sphere__x_center[2] = -0.2 +AHFinderDirect::initial_guess__coord_sphere__y_center[2] = 0.3 +AHFinderDirect::initial_guess__coord_sphere__z_center[2] = 0.0 +AHFinderDirect::initial_guess__coord_sphere__radius[2] = 2.0 }}} causes it to fail with {{{ WARNING level -1 in thorn AHFinderDirect processor 0 host horizon.tapir.caltech.edu (line 310 of /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/EinsteinAnalysis/AHFinderDirect/src/driver/initial_guess.cc): -> setup_coord_ellipsoid(): expected exactly one r>0 solution to quadratic, got 0 or 2! +z patch (irho,isigma)=(-9,-9) ==> (rho,sigma)=(-0.785398,-0.785398) direction cosines (xcos,ycos,zcos)=(-0.57735,-0.57735,0.57735) r_plus=-nan r_minus=-nan ==> this probably means the initial guess surface doesn't contain the local origin point, or more generally that the initial guess surface isn't a Strahlkoerper ("star-shaped region") with respect to the local origin point
[1mWARNING level -1 in thorn AHFinderDirect processor 0 host horizon.tapir.caltech.edu (line 310 of /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/EinsteinAnalysis/AHFinderDirect/src/driver/initial_guess.cc): ->[0m setup_coord_ellipsoid(): expected exactly one r>0 solution to quadratic, got 0 or 2! +z patch (irho,isigma)=(-9,-9) ==> (rho,sigma)=(-0.785398,-0.785398) direction cosines (xcos,ycos,zcos)=(-0.57735,-0.57735,0.57735) r_plus=-nan r_minus=-nan ==> this probably means the initial guess surface doesn't contain the local origin point, or more generally that the initial guess surface isn't a Strahlkoerper ("star-shaped region") with respect to the local origin point }}} (this might require poisoning to become obvious).
The reason is that AHFinderDirect attempts to initialize its internal variables from checkpointed data (in particular the patch system origin). Since the new horizons did not exist at the time of checkpoint (and the whole variable is missing) the recovery routine in CarpetIOHDF5 reads in no data which leaves the Cactus group uninitialized which in turn leads to invalid values in AHFinderDirect's internal data structures.
The attached fix circumvents this by having AHFinderDirect initialize the Cactus group from its internal data structures (which it constructed from the parameters) at BaseGrid. This way, any newly created horizon will retain the values from the parameter file, but existing ones have their values overwritten.
#1114: AHFinderDirect fails if one increases the number of horizons after recovery ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: review Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: AHFinderDirect ------------------------------------+--------------------------------------- Changes (by rhaas):
* status: new => review
#1114: AHFinderDirect fails if one increases the number of horizons after recovery ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: review Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: AHFinderDirect ------------------------------------+---------------------------------------
Old description:
eg. modifying the AHFinderDirect test recoverML like so:
{{{#!diff Index: test/recoverML.par =================================================================== --- test/recoverML.par (revision 1568) +++ test/recoverML.par (working copy) @@ -123,7 +123,7 @@ AHFinderDirect::geometry_interpolator_name = "Hermite polynomial interpolation" AHFinderDirect::geometry_interpolator_pars = "order=3"
-AHFinderDirect::N_horizons = 1 +AHFinderDirect::N_horizons = 2 AHFinderDirect::origin_x[1] = 0.5 AHFinderDirect::origin_y[1] = 0.7 AHFinderDirect::origin_z[1] = 0.0 @@ -133,3 +133,13 @@ AHFinderDirect::initial_guess__coord_sphere__y_center[1] = 0.3 AHFinderDirect::initial_guess__coord_sphere__z_center[1] = 0.0 AHFinderDirect::initial_guess__coord_sphere__radius[1] = 2.0
+AHFinderDirect::origin_x[2] = 0.5 +AHFinderDirect::origin_y[2] = 0.7 +AHFinderDirect::origin_z[2] = 0.0
+AHFinderDirect::initial_guess_method[2] = "coordinate sphere" +AHFinderDirect::initial_guess__coord_sphere__x_center[2] = -0.2 +AHFinderDirect::initial_guess__coord_sphere__y_center[2] = 0.3 +AHFinderDirect::initial_guess__coord_sphere__z_center[2] = 0.0 +AHFinderDirect::initial_guess__coord_sphere__radius[2] = 2.0 }}} causes it to fail with {{{ WARNING level -1 in thorn AHFinderDirect processor 0 host horizon.tapir.caltech.edu (line 310 of /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/EinsteinAnalysis/AHFinderDirect/src/driver/initial_guess.cc): -> setup_coord_ellipsoid(): expected exactly one r>0 solution to quadratic, got 0 or 2! +z patch (irho,isigma)=(-9,-9) ==> (rho,sigma)=(-0.785398,-0.785398) direction cosines (xcos,ycos,zcos)=(-0.57735,-0.57735,0.57735) r_plus=-nan r_minus=-nan ==> this probably means the initial guess surface doesn't contain the local origin point, or more generally that the initial guess surface isn't a Strahlkoerper ("star-shaped region") with respect to the local origin point
[1mWARNING level -1 in thorn AHFinderDirect processor 0 host horizon.tapir.caltech.edu (line 310 of /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/EinsteinAnalysis/AHFinderDirect/src/driver/initial_guess.cc): ->[0m setup_coord_ellipsoid(): expected exactly one r>0 solution to quadratic, got 0 or 2! +z patch (irho,isigma)=(-9,-9) ==> (rho,sigma)=(-0.785398,-0.785398) direction cosines (xcos,ycos,zcos)=(-0.57735,-0.57735,0.57735) r_plus=-nan r_minus=-nan ==> this probably means the initial guess surface doesn't contain the local origin point, or more generally that the initial guess surface isn't a Strahlkoerper ("star-shaped region") with respect to the local origin point }}} (this might require poisoning to become obvious).
The reason is that AHFinderDirect attempts to initialize its internal variables from checkpointed data (in particular the patch system origin). Since the new horizons did not exist at the time of checkpoint (and the whole variable is missing) the recovery routine in CarpetIOHDF5 reads in no data which leaves the Cactus group uninitialized which in turn leads to invalid values in AHFinderDirect's internal data structures.
The attached fix circumvents this by having AHFinderDirect initialize the Cactus group from its internal data structures (which it constructed from the parameters) at BaseGrid. This way, any newly created horizon will retain the values from the parameter file, but existing ones have their values overwritten.
New description:
eg. modifying the AHFinderDirect test recoverML like so:
{{{#!diff Index: test/recoverML.par =================================================================== --- test/recoverML.par (revision 1568) +++ test/recoverML.par (working copy) @@ -123,7 +123,7 @@ AHFinderDirect::geometry_interpolator_name = "Hermite polynomial interpolation" AHFinderDirect::geometry_interpolator_pars = "order=3"
-AHFinderDirect::N_horizons = 1 +AHFinderDirect::N_horizons = 2 AHFinderDirect::origin_x[1] = 0.5 AHFinderDirect::origin_y[1] = 0.7 AHFinderDirect::origin_z[1] = 0.0 @@ -133,3 +133,13 @@ AHFinderDirect::initial_guess__coord_sphere__y_center[1] = 0.3 AHFinderDirect::initial_guess__coord_sphere__z_center[1] = 0.0 AHFinderDirect::initial_guess__coord_sphere__radius[1] = 2.0 + +AHFinderDirect::origin_x[2] = 0.5 +AHFinderDirect::origin_y[2] = 0.7 +AHFinderDirect::origin_z[2] = 0.0 + +AHFinderDirect::initial_guess_method[2] = "coordinate sphere" +AHFinderDirect::initial_guess__coord_sphere__x_center[2] = -0.2 +AHFinderDirect::initial_guess__coord_sphere__y_center[2] = 0.3 +AHFinderDirect::initial_guess__coord_sphere__z_center[2] = 0.0 +AHFinderDirect::initial_guess__coord_sphere__radius[2] = 2.0 }}} causes it to fail with {{{ WARNING level -1 in thorn AHFinderDirect processor 0 host horizon.tapir.caltech.edu (line 310 of /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/EinsteinAnalysis/AHFinderDirect/src/driver/initial_guess.cc): -> setup_coord_ellipsoid(): expected exactly one r>0 solution to quadratic, got 0 or 2! +z patch (irho,isigma)=(-9,-9) ==> (rho,sigma)=(-0.785398,-0.785398) direction cosines (xcos,ycos,zcos)=(-0.57735,-0.57735,0.57735) r_plus=-nan r_minus=-nan ==> this probably means the initial guess surface doesn't contain the local origin point, or more generally that the initial guess surface isn't a Strahlkoerper ("star-shaped region") with respect to the local origin point
[1mWARNING level -1 in thorn AHFinderDirect processor 0 host horizon.tapir.caltech.edu (line 310 of /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/EinsteinAnalysis/AHFinderDirect/src/driver/initial_guess.cc): ->[0m setup_coord_ellipsoid(): expected exactly one r>0 solution to quadratic, got 0 or 2! +z patch (irho,isigma)=(-9,-9) ==> (rho,sigma)=(-0.785398,-0.785398) direction cosines (xcos,ycos,zcos)=(-0.57735,-0.57735,0.57735) r_plus=-nan r_minus=-nan ==> this probably means the initial guess surface doesn't contain the local origin point, or more generally that the initial guess surface isn't a Strahlkoerper ("star-shaped region") with respect to the local origin point }}} (this might require poisoning to become obvious).
The reason is that AHFinderDirect attempts to initialize its internal variables from checkpointed data (in particular the patch system origin). Since the new horizons did not exist at the time of checkpoint (and the whole variable is missing) the recovery routine in CarpetIOHDF5 reads in no data which leaves the Cactus group uninitialized which in turn leads to invalid values in AHFinderDirect's internal data structures.
The attached fix circumvents this by having AHFinderDirect initialize the Cactus group from its internal data structures (which it constructed from the parameters) at BaseGrid. This way, any newly created horizon will retain the values from the parameter file, but existing ones have their values overwritten.
--
Comment (by eschnett):
I believe this patch is safe. Have you performed restarted BBH simulations with this patch?
#1114: AHFinderDirect fails if one increases the number of horizons after recovery ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: review Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: AHFinderDirect ------------------------------------+---------------------------------------
Comment (by rhaas):
I added this patch for a NSNS case where I initially looked only for a single horizon, then wanted to add more horizons later one since the finder had trouble finding it. So while I have not performed a restarted BBH simulation with it, it was written (and tested) with a NSNS restart. I'll quickly give the qc0-mclachlan.par file a try to see if things work ok there too.
#1114: AHFinderDirect fails if one increases the number of horizons after recovery ------------------------------------+--------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: fixed | Keywords: AHFinderDirect ------------------------------------+--------------------------------------- Changes (by rhaas):
* status: review => closed * resolution: => fixed
Comment:
I tested the patch with a qc0-mclachlan.par test and things seem to work fine there.
Applied as revision 1569 of AHFinderDirect.
trac@lists.einsteintoolkit.org
-
Einstein Toolkit