<div dir="ltr"><div>Roland, Bruno<br></div><div> thank you very much. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>You could request (scalar) output for<br>
SphericalSurface::sf_valid to track the state of the variable.<span class="gmail-im"><br></span></div></blockquote><div><br></div><div>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 <i>-nan</i> before t_merger).</div><div><br></div><div>I also track the SphericalSurface::sf_active variable which is 0 up to t = 1834.67, and 1 from t_merger.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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?</div></blockquote><div><br></div><div>As far as I can tell AHFinderDirect finds the 3rd horizon after the merger. In my scalar output folder I have a <a href="http://BH_diagnostic.ah3.gp">BH_diagnostic.ah3.gp</a> file which yields real values starting from t_merger.</div><div><br></div><div>Federico<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno lun 24 feb 2020 alle ore 09:58 Bruno Giacomazzo &lt;<a href="mailto:bruno.giacomazzo@unimib.it">bruno.giacomazzo@unimib.it</a>&gt; ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Roland,<div>  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?</div><div><br></div><div>  Adding SphericalSurface::sf_valid to the scalar output seems to be a very good suggestion. </div><div><br></div><div>Thank you very much,</div><div>Bruno</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno ven 21 feb 2020 alle ore 19:29 Roland Haas &lt;<a href="mailto:rhaas@illinois.edu" target="_blank">rhaas@illinois.edu</a>&gt; ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Federico, Bruno,<br>
<br>
&gt; let me add the AHFinderDirect correctly finds an AH after merger (the one<br>
&gt; that should be stored in surface 2).<br>
Looking at the source for Outflow (the line number given by the<br>
warning):<br>
<br>
--8&lt;--<br>
957 if (sf_valid[sn]&lt;=0) {<br>
958   CCTK_VWarn(1, __LINE__, __FILE__, CCTK_THORNSTRING,<br>
959              &quot;didn&#39;t find valid detector surface for sn=%d, det=%d&quot;,(int)sn,(int)det);<br>
960   continue;<br>
961 }<br>
--8&lt;--<br>
<br>
this warning is output exactly when the surface is not marked as not<br>
&quot;valid&quot; which AHFinderDirect does if it cannot find a horizon or did<br>
not look for it, in driver/BH_diagnostics.cc (the lack of a &quot;return&quot; in<br>
line 678 looks like a bug to me):<br>
<br>
--8&lt;--<br>
674 if ((my_dont_find_after &gt;= 0 and cctk_iteration &gt; my_dont_find_after) or<br>
675     (my_dont_find_after_time &gt; my_find_after_time and cctk_time &gt; my_dont_find_after_time))<br>
676 {<br>
677   assert (! AH_data.search_flag);<br>
678   sf_active[surface_number] = 0;<br>
679 }<br>
680<br>
681 // only try to copy AH info if we&#39;ve found AHs at this time level<br>
682 if (! AH_data.search_flag) {<br>
683   sf_valid[surface_number] = 0;<br>
684   return;<br>
685 }<br>
686<br>
687 // did we actually *find* this horizon?<br>
688 if (! AH_data.found_flag) {<br>
689   sf_valid[surface_number] = -1;<br>
690   return;<br>
691 }<br>
692<br>
693 sf_active       [surface_number] = 1;<br>
--8&lt;--<br>
<br>
&gt; Moreover, Federico also run a sim in which AHFinderDirect was writing on<br>
&gt; surfaces 0, 1, and 2 while PunctureTracker was writing on surfaces 3 and 4.<br>
&gt; In this case Outflow was giving the same error on all three surfaces 0, 1,<br>
&gt; and 2.<br>
So as far as I can tell AHFinderDirect did indeed not find it or not try to<br>
find it. <br>
<br>
&gt; My naive impression is that we are missing something and AHFinderDirect is<br>
&gt; not saving the surfaces properly and therefore Outflow is not able to read<br>
&gt; them.<br>
Are you perhaps asking it to stop searching (the parfile does not seem<br>
to indicate this but still)? In that case valid=0 and Outflow will no<br>
longer use that surface. You could request (scalar) output for<br>
SphericalSurface::sf_valid to track the state of the variable.<br>
<br>
&gt; I had a look at previous par files from my BNS simulations (where Outflow<br>
&gt; worked) and the only difference I saw was in the number of points in theta<br>
&gt; and phi for the surfaces.<br>
That would not make a difference to Outflow.<br>
<br>
Yours,<br>
Roland<br>
<br>
-- <br>
My email is as private as my paper mail. I therefore support encrypting<br>
and signing email messages. Get my PGP key from <a href="http://pgp.mit.edu" rel="noreferrer" target="_blank">http://pgp.mit.edu</a> .<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><p><font color="#000000">Pr<font face="arial, sans-serif">of. Bruno Giacomazzo<br>Department of Physics<br>University of Milano-Bicocca<br></font></font><span style="color:rgb(0,0,0)"><font face="arial, sans-serif">Piazza della Scienza 3<br></font></span><span style="color:rgb(0,0,0)"><font face="arial, sans-serif">20126 Milano<br></font></span><span style="font-size:12.8px;color:rgb(0,0,0)">Italy</span></p><p><font color="#000000"><span style="font-size:12.8px">email: </span><span style="font-size:12.8px"><a href="mailto:bruno.giacomazzo@unimib.it" target="_blank">bruno.giacomazzo@unimib.it</a><br></span><span style="font-size:12.8px">phone: (+39) 02 6448 2321</span></font><br><font color="#000000"><span style="font-size:12.8px">web: </span></font><span style="color:rgb(0,0,0);font-size:12.8px"><a href="http://www.brunogiacomazzo.org/" style="font-size:12.8px" target="_blank">http://www.brunogiacomazzo.org</a></span></p><p><font color="#000000">----------------------------------------------------------------------<br><span style="font-size:12.8px">There are only 10 types of people in the world:<br></span><span style="font-size:12.8px">Those who understand binary, and those who don&#39;t<br></span><span style="font-size:12.8px">----------------------------------------------------------------------<br></span></font></p></div></div></div></div></div></div></div>
</blockquote></div>