[Users] (no subject)

[Zach Etienne]

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/e338fe50/attachment-0001.html