[Mesa-users] Question

[Jared Goldberg]

You likely have already figured out the answers to these questions.
However, in case anyone in the future is interested:


> In the example_make_pre_ccsn, what is the difference between
> inlist_common and inlist_convert,
>

Like example_ccsn_IIp, example_make_pre_ccsn chains together a series of
inlists which each govern a different "step", in this case, in the
evolution of the red supergiant. To see the order of the steps, look at the
rn script in your favorite text editor.

In this case, inlist_common is a set of common input parameters that are
used (and modified) throughout the entire run.  Inlist_convert governs a
certain step in the evolution.

why is one of its initial_mass is 14 and another is 13.0?


If you load from a saved model (i.e. in your star_job, load_saved_model =
.true., saved_model_name = '<some name>.mod'), MESA ignores the control
initial_mass. So it gets ignored in the step governed by inlist_convert.


> And in the inlist_before_remove, it set
>       xa_central_lower_limit_species(1) = 'he4'
>       xa_central_lower_limit(1) = 1d-6

Why is that set in this way?
>

This is a stopping condition for this particular step. When the he4
fraction in the core drops below 1d-6, terminate the step and move onto the
next one, as dictated by the rn script.

By the way, where and what kinds of the result of test_suite case
> example_make_pre_ccsn should be put in the example_ccsn_IIp?
>

The final model, saved, after the evolution has completed through core
silicon burning, final.mod, is what you want to load into example_ccsn_IIp
(e.g. rename final.mod produced by example_make_pre_ccsn, copy it over to
example_ccsn_IIp, and set
*saved_model_name = '<your new model name>.mod' *
instead of
*saved_model_name = '13M_vvc_0.0_wnd_1.0_ovr_010_mlt_3.0_z6m3.mod'  *
in inlist_infall).

Best,
~Jared

On Mon, Dec 24, 2018 at 11:05 AM Being Unique <uniquebeing17 at gmail.com>
wrote:

> Hi~
> Sorry for bothering again.
>
> In the example_make_pre_ccsn, what is the difference between
> inlist_common and inlist_convert, why Ione of its nitial_mass is 14 and
> another is 13.0?
>
> And in the inlist_before_remove, it set
>
>       xa_central_lower_limit_species(1) = 'he4'
>
>       xa_central_lower_limit(1) = 1d-6
>
> Why is that set in this way?
>
> By the way, where and what kinds of the result of test_suite case
> example_make_pre_ccsn should be put in the example_ccsn_IIp?
>
> Thanks a lot.
>
>
> Albert
>
> Jared Goldberg <goldberg at ucsb.edu> 於 2018年12月24日 週一 上午10:56寫道：
>
>> Hi Albert (and other interested Mesa users),
>>
>> Instead of having one run controlled by one inlist, example_ccsn_IIp
>> chains together various inlists in a sequence. Take a look at the rn
>> script. This will tell you the order they run in. Notice how it calls rn1,
>> a script that is nearly identical to the regular rn script you’d find in
>> $MESA_DIR/star/work. Note also that example_ccsn_IIp does NOT make a red
>> supergiant. It starts with a red supergiant and blows it up.
>>
>> Loosely speaking, inlist_edep is the inlist that controls the “explosion
>> itself” — it tells MESA to inject energy in the innermost region of the
>> star until the star reaches a total final energy that you specify (a
>> positive number typically on the order of 10^51 ergs). This will create the
>> shock that travels through the star’s envelope in shock_part1-4.
>>
>> You could in principle add rotation settings in any of the steps,
>> although some of them may have more problems with rotation than others.  If
>> you want to set rotation controls (or any other controls) that are active
>> throughout the entire explosion up until shock breakout, set them in the
>> files inlist_controls and inlist_star_job, which are called at the same
>> time as other inlists which govern specific “steps” in the explosion
>> (inlist_*part*). Then double check that the same rotation controls are not
>> being reset in the other inlist_part_*.
>>
>> I am still unsure if rotation can be implemented simply in
>> example_ccsn_iip without causing MESA to crash, but you’re more than
>> welcome to try! For my purposes I have generally considered models without
>> rapid rotation, which we can approximate as non-rotating on the ~1-day
>> timescale from core collapse to shock breakout. In many cases, this is
>> fine, as the relevant effects of rotation often occur when *making the red
>> supergiant* (e.g., by modifying the test_suite case example_make_pre_ccsn),
>> where rotation can be turned on more simply. Then, that red supergiant
>> model could be used as the input model in inlist_part_infall in
>> example_ccsn_IIp.
>>
>> Hope this is somewhat helpful. Let us know if you have any other
>> questions. I’m eager to hear of your success in this endeavor.
>>
>> Cheers,
>> ~Jared
>>
>>
>>
>> On Dec 23, 2018, at 1:04 AM, Being Unique via Mesa-users <
>> mesa-users at lists.mesastar.org> wrote:
>>
>> Hello MESA-Users,
>>
>> Does inlist_edep in the test_suite example_ccsn_IIp mean the star model's
>> setting before explosion?
>> And is that able for me to add rotation settings in the inlist_edep in
>> the test_suite example_ccsn_IIp?
>>
>> Many thanks !
>>
>> Albert
>>
>> _______________________________________________
>> 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/20181228/0c80aeb9/attachment.html>