Roland, Bruno thank you very much.
You could request (scalar) output for
SphericalSurface::sf_valid to track the state of the variable.
I already track the SphericalSurface::sf_valid variable (line 570 of the parfile). The sf_valid[2] ascii yields a -1 for each timestep, even after t_merger = 1835.33. Yet, the other sf scalar outputs for the [2] surface yield real numbers after t_merger (e.g., sf_max_radius[2] yields r = 0.934217920021859 which is constant from the 13th iteration after the merger onwards, and is *-nan* before t_merger).
I also track the SphericalSurface::sf_active variable which is 0 up to t = 1834.67, and 1 from t_merger.
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?
As far as I can tell AHFinderDirect finds the 3rd horizon after the merger. In my scalar output folder I have a BH_diagnostic.ah3.gp file which yields real values starting from t_merger.
Federico
Il giorno lun 24 feb 2020 alle ore 09:58 Bruno Giacomazzo < bruno.giacomazzo@unimib.it> ha scritto:
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 4.
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 .
--
Prof. Bruno Giacomazzo Department of Physics University of Milano-Bicocca Piazza della Scienza 3 20126 Milano Italy
email: bruno.giacomazzo@unimib.it phone: (+39) 02 6448 2321 web: http://www.brunogiacomazzo.org
There are only 10 types of people in the world: Those who understand binary, and those who don't