[FLASH-USERS] 2D SN Core-Collapse Leakage scheme problem
kiyarash Taghiniyarami
kiyarash.niyarami at gmail.com
Fri May 20 16:51:53 EDT 2022
Dear Evan,
Sorry for the confusion. To clarify the situation once again following are
what I have checked:
- Original and high resolution LS220 both without bypass ----> failed
before bounce
- High resolution LS220 with bypass ----> runs fine to produce the bounce
but fails in post bounce (almost 3 ms after the bounce) with the following
error ( also higher lrefine_max did not help):
DRIVER_ABORT: [Eos_putData] ERROR Density or Internal Energy are zero
after a call to EOS!
- Original LS375 without bypass -----> runs fine to the bounce (by
lrefine_max=10 instead of 9) but same error as above for the post bounce.
- Original LS375 with bypass---> runs fine for the bounce but failed in the
post bounce
I have not checked original LS220 with bypass for post bounce evolution yet
(but I will asap).
for all cases above I test the followings but did not help a lot:
the grid refinement are: nblockx = 5 nblocky = 10 nblockz = 1
and hydro time steps between 10^-6 to 10^-7 and cfl between 0.3 and 0.5
If the code for high resolution EOS is not available I do not really want
to take your time to bother you. By the way thanks a lot for your answers.
Kind Regards,
Kiya
On Sat, May 21, 2022 at 12:17 AM Evan Patrick O'Connor <
evan.oconnor at astro.su.se> wrote:
> 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> 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/20220521/505c1531/attachment.htm>
More information about the flash-users
mailing list