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 < [email protected]> 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 <[email protected]> > 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: [email protected] > 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 > ---------------------------------------------------------------------- >
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
