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:

   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@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_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@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@gmail.com>
Subject: Re: [Users] (no subject)
To: ZhiChao Zhao <yanyuechuixue@gmail.com>
Cc: Einstein Toolkit Users <users@einsteintoolkit.org>
Message-ID:
        <CAP6hNvw=87t3vEDbRw0-q93zEuJsQn2_vZQXJCzYc_dv7S7TKg@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@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@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_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@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@einsteintoolkit.org
http://lists.einsteintoolkit.org/mailman/listinfo/users


End of Users Digest, Vol 119, Issue 10
**************************************