[Mesa-users] problem of ccsn_llp
游凱安
timyu930218 at gmail.com
Mon Aug 2 04:25:14 UTC 2021
Dear Jared,
I followed your second step but it stopped accidentally due to the
requirement of u_flag = .true. in inlist_finish_core_collapse
so if I want to do that, should I change u_flag = .true. until it is about
to finish and change it into false?
Is that right?
or do I need to add another step to keep it from stopping?
thanks for your patience.
~kai-an
Jared Goldberg <goldberg at physics.ucsb.edu> 於 2021年8月2日 週一 上午8:58寫道：
> You could do this a number of ways. I encourage you to explore different
> options and see what works best and is the most physically consistent.
>
> You could, for example, add an inlist in between
> inlist_to_start_core_collapse and inlist_finish_core_collapse that takes
> one timestep, and zeroes out the outer velocity profile by setting
> velocity_q_upper_bound = 0.8. This might work, unless the large v/csound at
> the surface arises during inlist_finish_core_collapse. You could try to do
> the same thing between inlist_finish_core_collapse and inlist_infall.
>
> You could also try setting use_v_flag=.true. and use_u_flag = .false. in
> inlist_finish_core_collapse and add velocity_q_upper_bound to that inlist,
> but the final.mod may or may not break when you put it in inlist_infall,
> since MESA will have to switch from face- to cell-centered hydro schemes.
>
> ~Jared
>
> On Sat, Jul 31, 2021 at 3:12 PM 游凱安 <timyu930218 at gmail.com> wrote:
>
>> Hi Jared,
>>
>> Please tell me how to modify the end of pre-ccsn-run before it creates
>> the final.mod.
>>
>> Does it mean that before the model finished running, I need to change
>> use_u_flag from false to true immediately?
>>
>> please elaborate it,
>>
>> thanks for your patience.
>>
>> ~kai-an
>>
>> Jared Goldberg <goldberg at physics.ucsb.edu> 於 2021年7月28日 週三 上午9:17寫道：
>>
>>> No, this would be doing something above and beyond the MESA defaults
>>> listed in the test suite. The inlist command fixed_vsurf = 0. sets the
>>> velocity only at the outermost zone.
>>>
>>> Basically, the velocities in the outermost solar mass or so of the
>>> H-rich envelope are faster than the soundspeed, but slow compared to the
>>> supernova shock. So I'm suggesting that you set the velocities in the outer
>>> envelope to zero before inlilst_edep, as a "stellar engineering" solution.
>>> There are many ways you could try to do this. My first guess would be that
>>> you can try to turn hydrodynamics off before creating final.mod, like I
>>> suggested, using velocity_q_upper_bound, which sets the outermost stellar
>>> mass fraction that MESA includes velocities (q is defined as mass
>>> coordinate/star_mass; see the description in
>>> $MESA_DIR/star/defaults/controls.defaults). This option only works if
>>> use_v_flag = .true. and use_u_flag = .false., which would require modifying
>>> the end of your pre-ccsn run before you create final.mod, as the ccsn_IIp
>>> case needs use_u_flag = .true.
>>>
>>> If that does not work, you can try to set the velocities to zero outside
>>> some mass or temperature coordinate "by hand", by writing your own
>>> subroutine in run_star_extras.
>>>
>>> Cheers,
>>> ~Jared
>>>
>>> On Tue, Jul 27, 2021 at 5:58 PM 游凱安 <timyu930218 at gmail.com> wrote:
>>>
>>>> Hi Jared,
>>>>
>>>> thank you for giving me such advice.
>>>>
>>>> but I want to check that you said "enforcing the velocities in the
>>>> outer envelope to be zero before inlist_edep".
>>>>
>>>> what kind of factor it is?
>>>>
>>>> use_fixed_vsurf_outer_BC = .true.
>>>> fixed_vsurf = 0
>>>>
>>>> is that right?
>>>>
>>>> if it is, I have set the value zero before.
>>>>
>>>> if it isn't, please tell me the correct factor.
>>>>
>>>> Thanks
>>>> ~kai-an
>>>>
>>>>
>>>>
>>>> Jared Goldberg <goldberg at physics.ucsb.edu> 於 2021年7月28日 週三 上午7:30寫道：
>>>>
>>>>> Hi Kai-an,
>>>>>
>>>>> First of all, this is not a complete working directory, with no rn
>>>>> script or src/run_star_extras.f90 files, so I copied the inlists and
>>>>> final.mod to my own copy of a working directory you'd sent to the mailing
>>>>> list before.
>>>>>
>>>>> This is an example of a time wheen looking at why the runs terminated
>>>>> will help you. The culprit is supersonic velocities near the surface of
>>>>> your final.mod.
>>>>> Inlist_shock_part1 and inlist_shock_part2 immediately complete because
>>>>> the shock has reached outside the location specified in run_star_extras.
>>>>> This could be because your thermal energy injection region was too wide (it
>>>>> was, as the SN shock was already in the He core at shock_part1, but as you
>>>>> note, even fixing that by setting total_mass_for_inject_extra_ergs_sec =
>>>>> 0.01 did not solve the problem), or it could be because there is another
>>>>> shock somewhere else in the model.
>>>>>
>>>>> If you look at the mass coordinates of the shock listed at the end of
>>>>> the run (start_m and stop_m displayed in the terminal), it tells you the
>>>>> shock has already reached the 11Msun coordinate. Going back and rerunning
>>>>> inlist_infall with no limits on the x-axis of pgstar, we see that at the
>>>>> surface, sound speed (csound) in the outer zones of your model has a sheer
>>>>> drop and the vel_div_csound at the surface is 5, *even before
>>>>> inlist_edep*. This shock then improperly "satisfies" the stopping
>>>>> condition in shock_part1 and shock_part2, causing the failure in
>>>>> shock_part3.
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> Is the high surface velocity meaningful or physical? Maybe, maybe not.
>>>>> Nonetheless, I advise either enforcing the velocities in the outer envelope
>>>>> to be zero before inlist_edep, or figure out another work-around. This is
>>>>> an engineering solution, not a physical one, but probably OK since the
>>>>> surface velocity is small compared to the eventual shock velocity.
>>>>>
>>>>> One way to do this might be using velocity_q_upper_bound = 0.8 at the
>>>>> very end of your make_pre_ccsn before switching from using v_flag (old
>>>>> hydro scheme) to u_flag (HLLC Riemann solver, see instrument paper IV for
>>>>> more details), since velocity_q_upper_bound does not seem to work for the
>>>>> u_flag hydro scheme. Otherwise, it can be done in run_star_extras.
>>>>>
>>>>> Best,
>>>>>
>>>>> ~Jared
>>>>>
>>>>>
>>>>> On Mon, Jul 26, 2021 at 4:30 PM 游凱安 <timyu930218 at gmail.com> wrote:
>>>>>
>>>>>> Dear Jared,
>>>>>>
>>>>>> What you show is in inlist_edep,
>>>>>>
>>>>>> actually, I've looked at the models, and it seemed that they just
>>>>>> neglect shock_par1 shock_part2 and just jumped to part_3 and then failed
>>>>>> immediately.
>>>>>>
>>>>>> so I guessed the problem might occur in inlist_edep.
>>>>>>
>>>>>> however, I have changed the reasonable parameters many times, I
>>>>>> couldn't find the best solution.
>>>>>>
>>>>>> below are my inlist for the whole run.
>>>>>>
>>>>>> if you need more information please let me know.
>>>>>>
>>>>>> ~kai-an
>>>>>>
>>>>>>
>>>>>> Jared Goldberg <goldberg at physics.ucsb.edu> 於 2021年7月27日 週二 上午4:25寫道：
>>>>>>
>>>>>>> What inlists do these videos show?
>>>>>>>
>>>>>>> I suspect this is the same problem you had before with shocks
>>>>>>> getting out before the end of edep, as the energy and entropy profiles
>>>>>>> appear shock-heated out to zone 600, and that giant spike (not present in
>>>>>>> the 0.6 foe explosion) in v/cs is probably what's causing the numerical
>>>>>>> crash.
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> If changing the parameters of the thermal energy injection don't
>>>>>>> work, send me one entire (zipped) work directory for one run that fails
>>>>>>> (e.g. 1.8 foe).
>>>>>>>
>>>>>>> ~Jared
>>>>>>>
>>>>>>> On Sat, Jul 24, 2021 at 8:20 PM 游凱安 via Mesa-users <
>>>>>>> mesa-users at lists.mesastar.org> wrote:
>>>>>>>
>>>>>>>> Dear professors,
>>>>>>>>
>>>>>>>> I have tried the models of omega=0.2/z=0.02/13msun with 0.6foe
>>>>>>>> 1.2foe 1.8foe 2.4foe
>>>>>>>>
>>>>>>>> and I found that only 0.6foe could run successfully, the others
>>>>>>>> failed in shock_part3
>>>>>>>>
>>>>>>>> the factor I only changed is max_age_in_seconds
>>>>>>>> &total_mass_for_inject_extra_ergs_sec in imlist_edep
>>>>>>>>
>>>>>>>> 0.6foe
>>>>>>>> max_age_in_seconds=0.5
>>>>>>>> total_mass_for_inject_extra_ergs_sec in imlist_edep=0.2
>>>>>>>> https://youtu.be/h-Xg_VjbKb8
>>>>>>>>
>>>>>>>> 1.2foe
>>>>>>>> 0.7/0.3
>>>>>>>> https://youtu.be/xiqCTHEY24Y
>>>>>>>>
>>>>>>>> 1.8foe
>>>>>>>> 0.9/0.4
>>>>>>>> https://youtu.be/W25HkzC9v00
>>>>>>>>
>>>>>>>> 2.4foe
>>>>>>>> 1.0/0.5
>>>>>>>> https://youtu.be/8Iu6fcLrjbA
>>>>>>>>
>>>>>>>> and I found that 1.2foe~2.4foe couldn't make shock waves reach the
>>>>>>>> boundary
>>>>>>>>
>>>>>>>> and the mixing plot revealed the development of the core was not
>>>>>>>> good enough.
>>>>>>>>
>>>>>>>> May the problems occur in inlist_edep (explosion energy control)
>>>>>>>>
>>>>>>>> or in inlist_part3?
>>>>>>>>
>>>>>>>> how can I fix it?
>>>>>>>>
>>>>>>>> below are the models & inlists
>>>>>>>>
>>>>>>>> if you need more information, please let me know immediately
>>>>>>>> ~kai-an
>>>>>>>> _______________________________________________
>>>>>>>> mesa-users at lists.mesastar.org
>>>>>>>> https://lists.mesastar.org/mailman/listinfo/mesa-users
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20210802/f0e98921/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 378136 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20210802/f0e98921/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13206 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20210802/f0e98921/attachment-0003.png>
More information about the Mesa-users
mailing list