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

Adam Reyes adam.reyes at rochester.edu
Mon May 16 10:36:27 EDT 2022


Dear Kiya,

You might have better luck lowering the *cfl* number as this more directly
limits the timestep. *dtinit* and *tstep_change_factor *only limits the
initial timestep and subsequent steps by *tstep_change_factor *until you
reach the hydro time step determined by the cfl condition. Here
<https://flash.rochester.edu/site/flashcode/user_support/flash4_ug_4p62/node51.html#SECTION04115000000000000000>
is
the relevant section from the users guide on how FLASH determines the
timestep.



*************************************************************************
Adam Reyes

Code Group Leader, Flash Center for Computational Science
Research Scientist, Dept. of Physics and Astronomy
University of Rochester
River Campus: Bausch and Lomb Hall, 369
500 Wilson Blvd. PO Box 270171, Rochester, NY 14627
Email adam.reyes at rochester.edu
Web https://flash.rochester.edu
 (he / him / his)

*************************************************************************

On Mon, May 16, 2022 at 4:18 AM Naveen Yadav <naveen.phys at gmail.com> wrote:

> Dear Haakon and Kiyarash,
>
> I think the second error is caused by your thermodynamic variables moving
> out of the range of the EoS you are using. You can probably fix it by
> setting limits on the thermodynamic variables (floor values). It seems you
> are running into a low temperature, low Ye regime. You can plot the values
> of temp and Ye on a map of EoS in the T-Ye plane and see if you are outside
> the boundaries. In this case, you might need to patch up with a
> low-temperature EoS. I hope this helps along with a lower value of CFL
> condition.
>
> Regards
> Naveen Yadav
> Post-doctoral Researcher,
> Max Planck Institute For Astrophysics,
> Garching, Germany.
>
> "The purpose of (scientific) computing is insight, not numbers" -- Richard
> Hamming.
>
>
> On Mon, May 16, 2022 at 8:44 AM Haakon Andresen <
> haakon.andresen at astro.su.se> wrote:
>
>> Dear Kiya,
>>
>>
>> I do not have a particular parfile nor a concrete FLASH setup to
>>
>> recommend, I am still somewhat of a FLASH novice. I am not sure
>>
>> what exact spatial resolution your setup results in, what are the smallest
>>
>> and largest grid cells you have in the core during bounce?
>>
>>
>> Changing the timestep factor might not have solved your problem, but it
>>
>> improved it. Your simulation now progresses further and I am willing to
>> bet
>>
>> that a greater constraint on the timestep will allow even further
>> progress.
>>
>> I suspect that the problem is indeed related to the rapid changes
>> occurring during
>>
>> bounce. Plotting the central density, temperature and pressure might help
>> you
>>
>> check if is indeed the case. You can also continue to increase your
>> temporal and
>>
>> spatial resolution and check if your simulation progresses further and
>> further.
>>
>>
>> Best,
>> Haakon
>>
>>
>>
>>
>>
>> ------------------------------
>> *From:* kiyarash Taghiniyarami <kiyarash.niyarami at gmail.com>
>> *Sent:* 15 May 2022 19:09:59
>> *To:* Haakon Andresen; flash-users at flash.rochester.edu
>> *Subject:* Re: [FLASH-USERS] 2D SN Core-Collapse Leakage scheme problem
>>
>> Dear Haakon Andresen,
>>
>> Thanks for your reply. for the second error do you have any parfile or
>> time and resolution available to suggest?
>> I changed the resolution to:
>> # Grid / Refinement
>> nblockx = 15
>> nblocky = 30
>> nblockz = 1
>>
>> gr_lrefineMaxRedDoByLogR   = .true.
>> gr_lrefineMaxRedDoByTime   = .FALSE.
>> gr_lrefineMaxRedLogBase    = 10.0
>> gr_lrefineMaxRedRadiusFact = 0.15
>> gr_lrefineMaxRedTRef   = 2.0
>> gr_lrefineMaxRedTimeScale  = 0.5
>> lrefine_max   = 11
>> nrefs   = 2
>> lrefine_min   = 1
>> refine_var_1   =     "dens"
>> refine_var_2               = "pres"
>> refine_var_3               = "entr"
>> refine_var_4               = "none"
>> refine_cutoff_1   = 0.8
>> refine_cutoff_2   = 0.8
>> refine_cutoff_3            = 0.8
>> refine_cutoff_4            = 0.8
>>
>> but this time instead of 231 ms it gave me the same error at later time
>> (260 ms). changing the  *tstep_change_factor * , and *dtinit* did not
>> resolve the issue.
>>
>> Kind regards,
>> Kiya
>>
>> On Sun, May 15, 2022 at 1:42 PM Haakon Andresen <
>> haakon.andresen at astro.su.se> wrote:
>>
>>> Dear Kiyarash Taghiniyarami,
>>>
>>>
>>> The first error (for LS180) seem to indicate a lack of storage space on
>>> your drive.
>>>
>>> You see this written by the error handler in your first screenshot. Make
>>> sure that there is space
>>>
>>> and that you are not trying to create files larger than the maximum
>>> filesize allowed by your system.
>>>
>>>
>>> The second errors seems to be related to physics. During bounce things
>>> change very fast and it
>>>
>>> might be that you need to reduce your timestep during this time.
>>> However, I am not sure about this
>>>
>>> because I do not know exactly how flash regulates the timestep. The
>>> error is in the EOS module where the
>>>
>>> routine fails to converge, I have seen this happen around bounce and for
>>> me it always helped to restrict dt or
>>>
>>> the resolution. However, I was working with an other code at the time.
>>>
>>>
>>> Best,
>>> Haakon Andresen
>>> ------------------------------
>>> *From:* flash-users <flash-users-bounces at flash.rochester.edu> on behalf
>>> of kiyarash Taghiniyarami <kiyarash.niyarami at gmail.com>
>>> *Sent:* 15 May 2022 10:03:41
>>> *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
>>>
>> _______________________________________________
>> flash-users mailing list
>> flash-users at flash.rochester.edu
>>
>> For list info, including unsubscribe:
>> https://flash.rochester.edu/mailman/listinfo/flash-users
>>
> _______________________________________________
> flash-users mailing list
> flash-users at flash.rochester.edu
>
> For list info, including unsubscribe:
> https://flash.rochester.edu/mailman/listinfo/flash-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20220516/a3980813/attachment.htm>


More information about the flash-users mailing list