[Users] issue with Outflow after BHB merger

[Federico Cattorini]

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 at 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 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/305006d8/attachment.html