[Users] issue with Outflow after BHB merger

[Bruno Giacomazzo]

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 at 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 at 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
----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20200224/38aeaed1/attachment.html