Roland, thank you for your feedback. It is my understanding that AHFinderDirect was able to find the horizons since it produced the BH diagnostic files. Federico: can you double check it?
Adding SphericalSurface::sf_valid to the scalar output seems to be a very good suggestion.
Thank you very much, Bruno
Il giorno ven 21 feb 2020 alle ore 19:29 Roland Haas rhaas@illinois.edu ha scritto:
Hello Federico, Bruno,
let me add the AHFinderDirect correctly finds an AH after merger (the one that should be stored in surface 2).
Looking at the source for Outflow (the line number given by the warning):
--8<-- 957 if (sf_valid[sn]<=0) { 958 CCTK_VWarn(1, __LINE__, __FILE__, CCTK_THORNSTRING, 959 "didn't find valid detector surface for sn=%d, det=%d",(int)sn,(int)det); 960 continue; 961 } --8<--
this warning is output exactly when the surface is not marked as not "valid" which AHFinderDirect does if it cannot find a horizon or did not look for it, in driver/BH_diagnostics.cc (the lack of a "return" in line 678 looks like a bug to me):
--8<-- 674 if ((my_dont_find_after >= 0 and cctk_iteration > my_dont_find_after) or 675 (my_dont_find_after_time > my_find_after_time and cctk_time > my_dont_find_after_time)) 676 { 677 assert (! AH_data.search_flag); 678 sf_active[surface_number] = 0; 679 } 680 681 // only try to copy AH info if we've found AHs at this time level 682 if (! AH_data.search_flag) { 683 sf_valid[surface_number] = 0; 684 return; 685 } 686 687 // did we actually *find* this horizon? 688 if (! AH_data.found_flag) { 689 sf_valid[surface_number] = -1; 690 return; 691 } 692 693 sf_active [surface_number] = 1; --8<--
Moreover, Federico also run a sim in which AHFinderDirect was writing on surfaces 0, 1, and 2 while PunctureTracker was writing on surfaces 3 and
In this case Outflow was giving the same error on all three surfaces 0,
1,
and 2.
So as far as I can tell AHFinderDirect did indeed not find it or not try to find it.
My naive impression is that we are missing something and AHFinderDirect
is
not saving the surfaces properly and therefore Outflow is not able to
read
them.
Are you perhaps asking it to stop searching (the parfile does not seem to indicate this but still)? In that case valid=0 and Outflow will no longer use that surface. You could request (scalar) output for SphericalSurface::sf_valid to track the state of the variable.
I had a look at previous par files from my BNS simulations (where Outflow worked) and the only difference I saw was in the number of points in
theta
and phi for the surfaces.
That would not make a difference to Outflow.
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .