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