[Users] issue with Outflow after BHB merger

[Roland Haas]

Hello Federico,

glad to hear that this worked out and that you could correct the cause of the issue.

Yours,
Roland

----- Original Message -----
From: Federico Cattorini <f.cattorini at campus.unimib.it>
Sent: 2020-03-05 - 02:50
To: rhaas at illinois.edu
Subject: Re: [Users] issue with Outflow after BHB merger

> Roland,
>  thank you for your precious suggestions.
> 
> I managed to solve the issue. After setting AHFinderDirect verbose level to
> "algorithm debug" I found out that some points of the horizon surface fell
> on an excised region:
> 
> AHFinderDirect::AHFinderDirect_find_horizons
>>   in thorn AHFinderDirect, file
>> /marconi/home/userexternal/fcattori/EinsteinToolkit/ET_2018_09/Cactus/arrangements/EinsteinAnalysis/AHFinderDirect/src/gr/expansion.cc:949:
>>   -> interpolate_geometry():
>>         one or more points on the trial horizon surface point
>>         is/are in an excised region (or too close to the excision boundary)
>>
> 
> Then I added to the .par file the string
> 
> AHFinderDirect::mask_is_noshrink                         = "false"
>>
> 
> and now everything is working properly: the surface is valid (sf_valid[2] =
> 1 from t_merger onwards) and outflow correctly computes the flow across it.
> 
> Yours,
> Federico
> 
> Il giorno lun 24 feb 2020 alle ore 16:20 Roland Haas <rhaas at illinois.edu>
> ha scritto:
> 
>> Hello Federico,
>>
>> > 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).
>> A value of "-1" means that (see the code snippet I had provided) that
>> the horizon finder tried to look for a horizon and did not find it in
>> that iteration.
>>
>> > 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.
>> If you see "sensible" values in the other fields but sf_valid is -1
>> then this would mean that the horizon finder found the horizon at least
>> once but is not currently finding it. Thus data on the surface if not
>> guaranteed to actually be a good representation of the horizon since
>> the "found it" could have been very long in the past.
>>
>> If you run eg
>>
>> git grep sf_max_radius
>>
>> in repos/einsteinanalysis/AHFinderDirect/src then you can see that
>> sf_max_radius is only accessed in one place, namely in
>> driver/BH_diagnostics.cc:
>>
>> --8<--
>> 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;
>> 694 sf_valid        [surface_number] = 1;
>> 695 sf_origin_x     [surface_number] = this->origin_x;
>> 696 sf_origin_y     [surface_number] = this->origin_y;
>> 697 sf_origin_z     [surface_number] = this->origin_z;
>> 698 sf_mean_radius  [surface_number] = mean_radius;
>> 699 sf_min_radius   [surface_number] = min_radius;
>> 700 sf_max_radius   [surface_number] = max_radius;
>> --8<--
>>
>> and you can see that sf_max_radius is left at its old value if sf_valid
>> is 0 (not trying to find) or -1 (not found).
>>
>> Thus if the horizon was ever found but is no longer then there will be
>> sane values in sf_XXX but sf_valid will be -1.
>>
>> If you would like Outflow to continue using the (now invalid) horizon
>> for a while until after it became invalid (for how long is up to you to
>> decide) then you will have to add some grid scalar
>> "horizon_last_valid_at" or so to Outflow (it must be checkpointed) and
>> track when you last saw a "valid" horizon.
>>
>> 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 .
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20200305/7ca064a5/attachment.bin