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
