AHFinderDirect fails if one increases the number of horizons after recovery

Issue #1114 closed
Roland Haas created an issue

eg. modifying the AHFinderDirect test recoverML like so:

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.

Keyword: AHFinderDirect

Comments (5)

  1. Erik Schnetter
    • removed comment

    I believe this patch is safe. Have you performed restarted BBH simulations with this patch?

  2. Roland Haas reporter
    • removed comment

    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.

  3. Roland Haas reporter
    • changed status to resolved
    • removed comment

    I tested the patch with a qc0-mclachlan.par test and things seem to work fine there.

    Applied as revision 1569 of AHFinderDirect.

  4. Log in to comment