One quick clarification: When I said > "[integrated measures of rest mass over a volume] can become completely unreliable at the time of black hole formation"
I meant that the conservative nature of GRMHD schemes can and do break down inside black holes, so mass might be lost after it passes inside a black hole horizon. This should have no ill effect outside the horizon, as "what happens in the horizon stays in the horizon". Generally you'd want to perform a surface integral to monitor the rest mass passing into the horizon and combine it with a volume integral outside the horizon to measure the total rest mass after black hole formation. -Zach * * * Prof. Zachariah Etienne Physics & Astronomy Dept. West Virginia University http://astro.phys.wvu.edu/zetienne/ http://blackholesathome.net <https://blackholesathome.net> On Wed, Feb 12, 2020 at 11:05 PM Zach Etienne <[email protected]> wrote: > Hi ZhiChao, > > > The program runs without error, however there is no eject during the > merge. > > Typical ejecta from BNS mergers amount to a very tiny fraction of the > total initial mass, with values of 1e-3 Msun from BNS merger simulations > being reported in the literature (https://arxiv.org/abs/1809.11161). This > value is highly dependent on the equation of state however. Further most > simulations reporting ejecta are not performed at multiple numerical > resolutions, meaning that the values may be adjusted downwards with > subsequent simulations. Indeed in most simulations I saw for which more > than one resolution was performed in that paper, the higher resolution > simulation has less ejecta (see Table 2)--sometimes significantly less > (e.g., LS220_M140140_LK). > > Bottom line, I am not surprised you didn't see any ejecta. Ejecta > measurements are often dominated by numerical error, and depend sensitively > on equation of state. The very simple equation of state you chose (simple > Gamma=2 polytrope) might not exhibit much, if any, ejecta in the limit of > very high resolution. > > A recent update to IllinoisGRMHD supports more sophisticated (piecewise > polytrope/"hybrid") equations of state. It exists within the IllinoisGRMHD > subdirectory of https://github.com/zachetienne/nrpytutorial . You might > have more luck getting ejecta from BNS initial data with > piecewise-polytrope equations of state. > > > And "restmass. Init. IN sphere @ > (0.000000e+00,0.000000e+00,0.000000e+00), r=2.708902e+02. Moves/Tracks AMR > Centre -1/-1" is increasing. > > If I'm interpreting this correctly (I might not be), you are measuring > total rest mass within 270.89 in code units. You seem to observe an > increase of 0.06% over the course of the simulation. That's not much, and > can happen due to interpolation errors at AMR refinement boundaries (matter > crosses AMR refinement boundaries and tiny errors add up to a small boost > in mass), or become completely unreliable at the time of black hole > formation. Performing another simulation at higher or lower resolution and > additional volume integral regions may help diagnose this measurement. I > think you'd want to analyze the rest mass *outside* an interior volume to > estimate ejecta anyway. > > A more sophisticated interpolation treatment at AMR refinement boundaries > might help reduce this error, which amounts to a different prolongation > type (e.g., ENO) being chosen for evolved GRMHD variables. > > Hope this helps. > > -Zach > > * * * > Prof. Zachariah Etienne > Physics & Astronomy Dept. > West Virginia University > http://astro.phys.wvu.edu/zetienne/ > http://blackholesathome.net > <https://blackholesathome.net> > > > On Wed, Feb 12, 2020 at 9:25 PM ZhiChao Zhao <[email protected]> > wrote: > >> Hello everyone, >> >> I am Zhi-Chao Zhao from Beijing Normal University, China. >> I am using EinsteinToolkit and IllinoisGRMHD to simulate BNS merge. >> >> I use a par file modified from >> https://bitbucket.org/zach_etienne/wvuthorns_diagnostics/src/master/NSNS_parameter_files/nsns_test.par >> . >> I just add one line >> "VolumeIntegrals_GRMHD::volintegral_inside_sphere__radius[6] = >> 270.89015422746235". >> >> The initial data is got from Zach Etienne. >> >> The program runs without error, however there is no eject during the >> merge. >> Two videos: >> https://gogo.treenew.be/rho_b_movie.mpg >> https://gogo.treenew.be/rho_b_log_movie.mpg >> >> >> And "restmass. Init. IN sphere @ >> (0.000000e+00,0.000000e+00,0.000000e+00), r=2.708902e+02. Moves/Tracks AMR >> Centre -1/-1" is increasing. >> One figure: >> https://gogo.treenew.be/newplot.png >> >> I don't know where I went wrong. Can anyone help me? >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.einsteintoolkit.org/mailman/listinfo/users >> >
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
