Thank you very much!
Send Users mailing list submissions to users@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@einsteintoolkit.org
You can reach the person managing the list at users-owner@einsteintoolkit.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..."
Today's Topics:
- Re: (no subject) (Zach Etienne)
- Re: (no subject) (Zach Etienne)
Message: 1 Date: Wed, 12 Feb 2020 23:14:50 -0500 From: Zach Etienne zachetie@gmail.com Subject: Re: [Users] (no subject) To: ZhiChao Zhao yanyuechuixue@gmail.com Cc: Einstein Toolkit Users users@einsteintoolkit.org Message-ID: < CAP6hNvzOc_XR-M33McaNH6bMBu76uc1yrXZaX0B6E5NpzZmQJw@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@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@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_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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
ZhiChao Zhao