Thank you very much!
> Send Users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.einsteintoolkit.org/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > > Today's Topics: > > 1. Re: (no subject) (Zach Etienne) > 2. Re: (no subject) (Zach Etienne) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 12 Feb 2020 23:14:50 -0500 > From: Zach Etienne <[email protected]> > Subject: Re: [Users] (no subject) > To: ZhiChao Zhao <[email protected]> > Cc: Einstein Toolkit Users <[email protected]> > Message-ID: > < > cap6hnvzoc_xr-m33mcanh6bmbu76uc1yrxzax0b6e5npzzm...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.einsteintoolkit.org/pipermail/users/attachments/20200212/77182a2e/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Thu, 13 Feb 2020 00:00:17 -0500 > From: Zach Etienne <[email protected]> > Subject: Re: [Users] (no subject) > To: ZhiChao Zhao <[email protected]> > Cc: Einstein Toolkit Users <[email protected]> > Message-ID: > <CAP6hNvw= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > Hi ZhiChao, > > One more note: The BNS simulation you performed was an equal-mass case. > You should find that the amount of ejecta will be much larger if you chose > a significantly unequal-mass system. You will want to adjust the AMR grid > structure accordingly before proceeding on this front. > > -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:14 PM Zach Etienne <[email protected]> wrote: > > > 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 > >>> > >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.einsteintoolkit.org/pipermail/users/attachments/20200213/96a0798d/attachment.html > > ------------------------------ > > _______________________________________________ > Users mailing list > [email protected] > http://lists.einsteintoolkit.org/mailman/listinfo/users > > > End of Users Digest, Vol 119, Issue 10 > ************************************** > -- 赵志超 中国科学院高能物理研究所 中国 北京 18401696963 [email protected]
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
