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

[kiyarash Taghiniyarami]

Dear Evan,
I tried the new EOS file but got the same error. Then by bypassing L162 in
eos_nuclear.F90  and calling EOS by the temp instead of internal energy, it
could manage to get the bounce (despite a few flags pop up about internal
energy pumping).
I also could get the bounce with LS375 with lrefine_max=10 without
changing in eos_nuclear.F90.

Can I get an EOS table with higher resolution to avoid this issue by the
EOS driver or EOS maker you provided in your personal website?
Because I am now trying to evolve postbounce from checkpoints files and got
the following (3ms after the bounce):

 i,rl,logrho,logtemp0,lt,ye,eps,eps0,abs(eps-eps0)/eps0
          21           0   14.188184188353635      -0.61304754054343624
 -0.61304754054343624       0.27795080232191288        19.542939200343021
     19.530696364609064        6.2685095837863099E-004
 d2=                       NaN
 Tried calling bisection... didn't help... :-/
 Bisection error:          667
 DRIVER_ABORT: [Eos_putData] ERROR Density or Internal Energy are zero
after a call to EOS!
 EOS: Did not converge in findtemp!
 i,rl,logrho,logtemp0,lt,ye,eps,eps0,abs(eps-eps0)/eps0
          21           0   14.159389155587279      -0.43346281291235161
 -0.43346281291235161       0.27796184415346487        19.534894764509421
     19.529483548477000        2.7707932055596459E-004
 d2=                       NaN
 Tried calling bisection... didn't help... :-/
 Bisection error:          667
 EOS: Did not converge in findtemp!
 i,rl,logrho,logtemp0,lt,ye,eps,eps0,abs(eps-eps0)/eps0
          21           0   14.323881185734283      -0.56350764342967907
 -0.56350764342967907       0.27795290984794996        19.583574339654572
     19.566803819457075        8.5709042479489340E-004
 d2=                       NaN
 Tried calling bisection... didn't help... :-/
 Bisection error:          667
Abort(1) on node 4 (rank 4 in comm 0): application called
MPI_Abort(MPI_COMM_WORLD, 1) - process 4

real    7m37.613s
user    0m0.045s
sys     0m0.100s



Kind Regards,

On Wed, May 18, 2022 at 12:43 AM 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).
> https://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 (https://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20220520/3de0a7ba/attachment-0001.htm>