[Mesa-users] ?==?utf-8?q? Timestep issue at the He flash stage

[Dreau Guillaume]

Hello Bill,
Whenever possible (and in your case it is happily possible), debug by going back to something that works and then make small incremental single changes to identify the source of the problem.   So, what do you know now?   sounds to me that you have learned that a single change will trigger the break - am I understanding your email correctly on that? if so, then it becomes a bug/problem report concerning atm_T-tau_opacity = ‘varying’.
Yes, that's it. I took the same inlists as in the standard 1M_pre_ms_to_wd case, the only thing I changed is the option atm_T-tau_opacity = ‘varying’. I'm going to send a separate email so that the bug report is clearly exhibited.

Cheers,
Guillaume
*******************************************************************************************************************
Guillaume Dréau
PhD student 2nd year – Instructor
Speciality Stellar Physics
LESIA - Observatoire de Paris
Building 14, office 107
5 place Jules Janssen
92195 Meudon Cedex – France
http://www.lesia.obspm.fr/

*******************************************************************************************************************Le Samedi, Février 06, 2021 16:44 CET, Bill Paxton <paxton at kitp.ucsb.edu> a écrit:
  Progress.   And I didn’t expect that changing the timesteps would alone solve the problem.  It is part of a process.  Whenever possible (and in your case it is happily possible), debug by going back to something that works and then make small incremental single changes to identify the source of the problem.   So, what do you know now?   sounds to me that you have learned that a single change will trigger the break - am I understanding your email correctly on that?  if so, then it becomes a bug/problem report concerning atm_T-tau_opacity = ‘varying’.   It would be good to send a separate email to mesa-users with that as the subject and a clear statement of how to show the problem.  we don’t want the bug report to be hidden in this email chain.  then you either wait for a solution, or you look for a work-around such as changing to an ATM option that works. cheers,bill   On Feb 6, 2021, at 4:15 AM, Dreau Guillaume <Guillaume.Dreau at obspm.fr> wrote: Hello Bill,

Indeed, you are right. In my inlists, the timesteps were larger than those in the standard 1M_pre_ms_to_wd case because I was setting the option time_delta_coeff = 2d0 for some reasons. Unfortunately, when I keep the default value time_delta_coeff = 1d0 as in the standard case, the same issue occurs approximately 400 steps after the start from my start_he_core_flash.mod. In parallel, I also tried to run the standard 1M_pre_ms_to_wd case just by changing the option atm_T_tau_opacity = 'varying', from the PMS up to the RGB tip and I surprisingly get the same timestep stopping condition and I can't pass the helium flash stage. So I'm afraid that having the same timesteps as in the standard case may not be the solution.

Cheers,
Guillaume
*******************************************************************************************************************
Guillaume Dréau
PhD student 2nd year – Instructor
Speciality Stellar Physics
LESIA - Observatoire de Paris
Building 14, office 107
5 place Jules Janssen
92195 Meudon Cedex – France
http://www.lesia.obspm.fr/

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

Le Vendredi, Février 05, 2021 20:23 CET, Bill Paxton <paxton at kitp.ucsb.edu> a écrit:
 
as you said, it takes your inlists about 100 steps for the end_core_he_burn part to get into trouble starting from your start_he_core_flash.mod. At that point, lg_L3a has reached 9.5, nearly the peak of the flash.

for comparison, the standard 1M_pre_ms_to_wd case takes over 400 steps to get a similar lg_L3a. It then continues happily though the flash.

so you need to see why your inlists are causing the code to take much larger timesteps than the standard inlists.

fix that so that the timesteps are similar, then see what happens and let us know.

cheers,
bill




 


 


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20210207/e5cd5a19/attachment.htm>