[FLASH-USERS] 2D SN Core-Collapse Leakage scheme problem
Evan Patrick O'Connor
evan.oconnor at astro.su.se
Fri May 20 15:47:31 EDT 2022
Hi,
I'm a bit confused as there are multiple EOSs and multiple tables.
Is the following the case:
- The simulation using the original LS220 table and without bypassing the abort stops just before bounce (your original question)
- The simulation using the higher resolution LS220 table and without bypassing the abort also stops just before bounce
- The simulation using the higher resolution LS220 table and with bypassing the abort runs fine and doesn't abort at all.
Have you tried the original LS220 table with the abort bypass? I suspect this will work just as well as with the higher resolution table.
- The simulation using the original LS375 table and without bypassing the abort crashes after bounce with similar error to the original you shared in first email.
Have you tried the original LS375 table with the abort bypass?
EOSmaker takes tabulated EOSs and puts them in the HDF5 format we use, also generating some extra derivatives we use. The original LS EOS come from a code, not a table, so EOSmaker is not used to make those tables. I have a code that runs the LS code to generate our tables. It is not online anywhere and it has also been 10 years since I used it. I can try to find it and make a similarly higher resolution table, but I think if you need to bypass the abort anyways, and if that alone works, then I wouldn't need to.
Evan
________________________________
From: flash-users <flash-users-bounces at flash.rochester.edu> on behalf of kiyarash Taghiniyarami <kiyarash.niyarami at gmail.com>
Sent: Friday, May 20, 2022 12:24:05 PM
To: flash-users at flash.rochester.edu
Subject: Re: [FLASH-USERS] 2D SN Core-Collapse Leakage scheme problem
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<mailto: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<mailto:flash-users-bounces at flash.rochester.edu>> on behalf of kiyarash Taghiniyarami <kiyarash.niyarami at gmail.com<mailto:kiyarash.niyarami at gmail.com>>
Sent: Sunday, May 15, 2022 10:03:41 AM
To: flash-users at flash.rochester.edu<mailto: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/3d13169d/attachment-0001.htm>
More information about the flash-users
mailing list