[Mesa-users] mesa r10398, suite-case make_co_wd, question about inlist

Sat Mar 2 10:04:54 EST 2019

Hello everyone!
I'm back with almost the same topic of experimenting with make_co_wd (and
i'm still ). Again with initial mass 5 solar masses, the following two
inlists (see attachment). With inlist_prepare_to_make_co_wd MESA is
reaching lg (L/Lsolar) ~ 4.25 and lg Teff ~ 4.5, where the programm goes on
a loop, then breaks it and starts inlist_make_co_wd (see attachments of HR
diagram). Having reached lg (L/Lsolar) ~ 4.15-4.2 and lg Teff ~ 5.1 MESA
goes on another loop and there reaches maximum model number (7000 in this
case). I've managed to overcome the problem restarting from model number
~1000 or so, then MESA reached log_L_lower_limit = -2 (that was what i
needed). But i m not sure it's the right way. Maybe i should better change
something in inlists?

Another question is connected with the first one. While changing from
inlist_prepare_to_make_co_wd  to _inlist_makecowd MESA kills the history
file and creates new one. I need to save history of red giant phase too.
When i tried the same suite case with initial mass 3 solar masses and there
was no such a problem - history file contained all stages of evolution
(from MS) after the final model was created. Could you give an advice how
to solve this problem? (I suppose it is not the problem of programming only
but also the question of physics and inlist parameters as mass loss and
others )

пн, 31 дек. 2018 г. в 02:53, Александр Сергеевич Андрюшин <
andriushin.as14 at physics.msu.ru>:

> Thank you very much!
>
> пн, 31 дек. 2018 г. в 02:08, Francis Timmes <fxt44 at mac.com>:
>
>> hi alex,
>>
>> i’ll paraphrase jared’s reply in
>> https://lists.mesastar.org/pipermail/mesa-users/2018-December/009681.html
>>
>> the two inlists are executed in succession, see the “rn” file.
>>
>> whenever a saved model is loaded (i.e., load_saved_model = .true.,
>> saved_model_name = '<some name>.mod'), mesa ignores the control
>> initial_mass.
>>
>> in your specific case, an initial mass of 3.25mun is set in
>> inlist_prepare_to_make_co_wd and the ending model is saved as
>> after_1st_TP.mod.
>>
>> inlist_make_co_wd is then run and it loads after_1st_TP.mod. this picks
>> up the
>> correct mass to continue the run (including any changes in the mass
>> resulting
>> from inlist_prepare_to_make_co_wd). the initial_mass setting in
>> inlist_make_co_wd is ignored.
>>
>> clearer?
>>
>> for aesthetic purposes only, one could set initial_mass to be the same in
>> both inlists.
>>
>> fxt
>>
>>
>>
>>
>>
>>
>> > On Dec 30, 2018, at 11:33 AM, Александр Сергеевич Андрюшин <
>> andriushin.as14 at physics.msu.ru> wrote:
>> >
>> > Hello!
>> > My name Alex!
>> > I'm exploring MESA suite-case make_co_wd. Here
>> https://arxiv.org/pdf/1301.0319.pdf i have read about the suite case. So
>> i have found two inlists inlist_prepare_to_make_co_wd  and
>> inlist_make_co_wd. My question is why the initial mass in inlist_make_co_wd
>> (6 solar masses) is bigger then in inlist_prepare_to_make_co_wd (3.25 solar
>> masses )?
>> >
>> > For instance, i need to make CO white dwarf for a star with ZAMS_mass
>> about 5 solar masses. Should i write down the same initial masses in both
>> mentioned inlists?
>> > _______________________________________________
>> > 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/20190302/062303eb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_prepare_to_make_co_wd
Type: application/octet-stream
Size: 3449 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190302/062303eb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inlist_make_co_wd
Type: application/octet-stream
Size: 5429 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190302/062303eb/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hr_001800.png
Type: image/png
Size: 5240 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190302/062303eb/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hr_003660.png
Type: image/png
Size: 4466 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190302/062303eb/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hr_007000.png
Type: image/png
Size: 4458 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190302/062303eb/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abundance_006945.png
Type: image/png
Size: 4333 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190302/062303eb/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trho_profile_006825.png
Type: image/png
Size: 9263 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190302/062303eb/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trho_profile_001425.png
Type: image/png
Size: 9332 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20190302/062303eb/attachment-0005.png>