[Users] (no subject) (Zach Etienne)
ZhiChao Zhao
yanyuechuixue at gmail.com
Wed Feb 12 23:21:11 CST 2020
Thank you very much!
> Send Users mailing list submissions to
> users at einsteintoolkit.org
>
> 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
> users-request at einsteintoolkit.org
>
> You can reach the person managing the list at
> users-owner at einsteintoolkit.org
>
> 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 <zachetie at gmail.com>
> Subject: Re: [Users] (no subject)
> To: ZhiChao Zhao <yanyuechuixue at gmail.com>
> Cc: Einstein Toolkit Users <users at einsteintoolkit.org>
> Message-ID:
> <
> CAP6hNvzOc_XR-M33McaNH6bMBu76uc1yrXZaX0B6E5NpzZmQJw at 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 <zachetie at gmail.com> 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 <yanyuechuixue at gmail.com>
> > 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
> >> Users at einsteintoolkit.org
> >> 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 <zachetie at gmail.com>
> Subject: Re: [Users] (no subject)
> To: ZhiChao Zhao <yanyuechuixue at gmail.com>
> Cc: Einstein Toolkit Users <users at einsteintoolkit.org>
> Message-ID:
> <CAP6hNvw=
> 87t3vEDbRw0-q93zEuJsQn2_vZQXJCzYc_dv7S7TKg at mail.gmail.com>
> 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 <zachetie at gmail.com> 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 <zachetie at gmail.com>
> 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 <yanyuechuixue at gmail.com>
> >> 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
> >>> Users at einsteintoolkit.org
> >>> 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
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>
> End of Users Digest, Vol 119, Issue 10
> **************************************
>
--
赵志超
中国科学院高能物理研究所
中国 北京
18401696963
yanyuechuixue at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20200213/5090c664/attachment-0001.html
More information about the Users
mailing list