Hello Roland,
thanks for the quick reply...
when i did the collapse (with less refinement levels and resolution due to RAM restrictions on my iMac) the code crashes as well after the Bh has been formed...when using AHfinderDirect, the simulation stops upon the following error:
[1mWARNING level 0 in thorn AHFinderDirect processor 0 host permeability.daa.uv.es (line 78 of /Users/vass/programs/Cactus/arrangements/EinsteinAnalysis/AHFinderDirect/src/jtutil/error_exit.cc): -> [0m ***** row_sparse_Jacobian__UMFPACK::solve_linear_system(): error return status=1 from umfpack_numeric() routine
and when running without the AHFinderdirect, the run produces meaningless results (the density maximum and minimum as well as the lapse min and max get set to 1.797693e+308 and -1.797693e+308) however, there are no NaNs caught by the NaNChecker...
thanks for pointing out the trigger thorn, is it triggering more refinement levels once the density has reached a certain threshold?
what about the general stability of simulations after a BH has been formed? is it yet possible to evolve the system for a long time after the formation of a BH, using the current tools available in the ET? i am asking this because we are interested in gravitational collapse of NS triggered by winds past the NS and it would be desirable to observe the long term evolution of the NS-wind and later BH-wind system...
best wishes,
Vassili
On Mon, Jul 23, 2012 at 7:31 PM, Roland Haas <roland.haas@physics.gatech.edu
wrote:
Hello Vassilios,
the plot shows the evolution up to a time of roughly 180 (in M_sun)...my first question is: for how long in total was the simulation running? for how much longer is the evolution stable AFTER the BH has been formed?
does
the code eventually crash or was there only interest in showing the successful collapse and then stop the simulation manually after that point?
I ran the NS collapse run for the paper. Mostly there was only interest in getting the collapse. The code fails shortly after that though (with NaNs inside the AH I think is what it was).
furthermore, in the tov_collapse_vc_l3.par file for the collapse for the paper there the following parameters for a thorn *corecollapsecontrol*
the
following section:
These have to go. I'll put up a replacement that uses public thorns (CoreCollapseControl is not yet public [though there are no objections to making it public from the author]).
what is this *corecollpasecontrol* thorn doing? and where can it be obtained if it is necessary for successful simulations of NS to BH
collapse? It does many things but we only really need functionality to steer some grid functions.
I attach an updated parameter file which uses Frank Loeffler's Trigger thorn (https://docs.einsteintoolkit.org/et-docs/Thorns_we_know_of). Please let me know if this solves your problem (I only tested that I can start it), then I can (barring protests from the other authors), update the parameter file in the repository.
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://keys.gnupg.net.
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users