[Users] (no subject)

Wed Feb 12 23:00:17 CST 2020

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-0001.html 