[FLASH-USERS] [EXTERNAL] 2D SN Core-Collapse Leakage scheme problem

kiyarash Taghiniyarami kiyarash.niyarami at gmail.com
Fri May 20 06:36:03 EDT 2022


Dear Raph,

Thanks for the hint and the literature. The error happened right before the
bounce and no shock yet formed. But the same error will again pop up for
postbounce evolution and by introducing more dissipation factor(just for
about less than 1 ms and the hydro timestep is about 10^-6) leads zero
internal energy error and EOS crash.

Best,

On Wed, May 18, 2022 at 1:29 AM Hix, W Raphael <raph at ornl.gov> wrote:

> Hi All-
>
> Let me ask a question.  Is the zone where this EOS error occurs near the
> shock?
>
> If so, this behavior is something we’ve seen intermittently in supernova
> simulations with CHIMERA, also a PPM code.  While Evan’s suggested solution
> is the absolute solution, it can be tricky to use in a limited enough
> fashion that you don’t inject significant energy and change the problem.
>
> We (actually Steve Bruenn) found by accident that a temporary modification
> of the PPM parameters to introduce a little more dissipation for a couple
> thousand timesteps can avoid these problems.  For more details look at the
> discussion around Equation 193 in
>
> https://ui.adsabs.harvard.edu/abs/2020ApJS..248...11B/abstract
>
> The discussion in the paper centers on reducing post-shock oscillations,
> but this also avoids the too low internal energy that can cause the EOS to
> crash.
>
>                                         Raph
>
> > On May 17, 2022, at 4:13 PM, Evan Patrick O'Connor <
> evan.oconnor at astro.su.se> wrote:
> >
> > Hi,
> >
> > Sorry for the silence, I haven't had a chance to look at this till now.
> >
> > The point this is failing at is not near the edge of the table
> (rho~1.77e14g/cm^3, temp~3.5MeV, and ye=0.278), however, in energy space it
> is very close to the edge.  For that density and ye, I've attached a plot
> of the internal energy vs temperature and there is no temperature where it
> equals (logged, cgs) 19.5587, so the EOS cannot be inverted (the hydro
> solver gives the EOS an energy and the EOS has to find the temperature that
> corresponds to it).
> >
> > We have a different LS220 table that we use for FLASH, I've added it to
> the page you linked (it was there before, but I missed it when moving the
> data around). It has a slightly higher resolution in density and
> temperature.  It may give better results, especially given that we use this
> for some reason (I forget now, it is a decade old). hxxps://
> su.drive.sunet.se/index.php/s/EGP7wFx4XCLT37G
> >
> > If this doesn't work (we still have issues like this some times with
> some progenitors) you can do what Naveen suggested.  With the nuclear EOS
> it is a bit harder since just because the minimum energy (logged, cgs) for
> this rho and ye is 19.5599, at other rho, ye pairs it will be very
> different. We accomplish this by bypassing the abort on L162
> source/physics/Eos/EosNuclear/eos_nuclear.F90 and calling the EOS with the
> incoming temperature instead of the incoming energy, this avoid the
> inversion.  It essentially pumps internal energy into the zone, so be
> careful with it.  We have a parameter file flag to turn this on and keep
> track of any such calls to ensure we don't do it too often.  When it does
> occur it is in the situation you have now, right at bounce.
> >
> > Also, FYI, I had suggested changing the file io_intfTypesModule.F90, not
> Flash.h, you should never edit the Flash.h as it get re generated with each
> setup.
> >
> > Evan
> >
> > From: flash-users <flash-users-bounces at flash.rochester.edu> on behalf
> of kiyarash Taghiniyarami <kiyarash.niyarami at gmail.com>
> > Sent: Sunday, May 15, 2022 10:03:41 AM
> > To: flash-users at flash.rochester.edu
> > Subject: [FLASH-USERS] 2D SN Core-Collapse Leakage scheme problem
> >
> > Dear all FLASH users,
> > I tried to run 2D supernova core collapse for two different nuclear EOS
> of Lattimer and Sewsty (hxxps://ttt.astro.su.se/~eoco/eos.html)  with
> K=180 and K=220 but I got the errors which I attached the images of them.
> > for the case of k=220 it runs into problem after 231 ms (it seems before
> the bounce) and for k=180 just after 24 ms
> > Could anyone tell me what I have done wrong?
> > (changing the resolution also did not resolve the issue)
> >
> > P.S. Trying to compile the FLASH, I also changed the Flash.h file and
> replace the line  as Dr. O'Connor  proposed:
> > #FLASH_HAVE_HDF5_MOD
> > with
> > #define IO_USE_HDF5_MOD 1
> >
> > I also attached the sample flash.par file
> > <eint_vs_temp_ls220.png>_______________________________________________
> > flash-users mailing list
> > flash-users at flash.rochester.edu
> >
> > For list info, including unsubscribe:
> > hxxps://flash.rochester.edu/mailman/listinfo/flash-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20220520/f3d3d000/attachment.htm>


More information about the flash-users mailing list