#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.