[Mesa-users] Evolution of a 9M_sun ZAMS star up to to core collapse

Sun Oct 10 00:49:04 UTC 2021

Hi Amar,

Stripped-envelope SNe are very challenging, and sometimes intractable, in
the standard MESA+STELLA setup, as others on this users list might be able
to attest. (Not to mention that I'm still a little shocked that the 9Msun
ended up with this much stripping; I guess with less efficient convection
the surface is cooler, opacity is higher, Eddington luminosity is lower,
and winds are stronger?).

As for an update: I am getting a similar error and have not found a
solution yet for the STELLA output question. Congratulations, you've
stumbled on a hard (weird) problem!

I suspect the output mismatch specifically has to do with the definition of
the photosphere versus what's output to the terminal, which I believe are
values in the outer zone in stella. I also suspect we have an issue with
the spatial resolution which may or may not be related. Because the
envelope is very sparse (<0.5 Msun), the usual stopping condition of
reaching the outer 0.05Msun leaves the shock in the middle of the ejecta.
This may also impact what you should choose as your inner boundary velocity
cut and/or skip_inner_dm.

This is what the shock velocity looks like in your mesa.hyd/mesa.abn files.
Notice that there are only 3 shocked zone at handoff:
[image: image.png]

[image: image.png]

and here's the Ni distribution.
[image: image.png]

Also, either because of your surface density cut or because of the
stripping, the explosion is within the C/O core, and there is no H/He
present anywhere in your mesa.hyd. Notice the 0.125Rsun surface radius.
This could create problems for STELLA's opacities.

If anything could work (which, frankly, I'm not sure it can), my first
piece of advice is run the shock in MESA for longer if you can, by setting
 x_ctrl(16) = 0.01 or smaller, to get the shock closer to the surface by
the time you hand off to STELLA.

STELLA's timestep is also limited by the width of each zone, so although
more zones will make the run take longer and take more timesteps.
Remeshing in MESA might be necessary for this problem.

I'm not sure if this will help your specific case, but to change the
spatial resolution of the shock propagation in MESA to better resolve the
surface of the star without underresolving the core, sometimes I've found
that setting

> use_split_merge_amr = .false.

in inlist_infall, and then

> use_split_merge_amr = .true.
> split_merge_amr_logtau_zoing = .true.
> split_merge_amr_log_zoning = .false.

in the other inlists except part5,
and

> split_merge_amr_logtau_zoning = .false.
> split_merge_amr_log_zoning = .false.

in inlist_shock_part5 to give a better mesh distribution in the envelope,
assuming the surface of the initial model is sufficiently resolved.

Hope this is somewhat helpful, and I absolutely commiserate that it's a
frustrating problem.

Best,
~Jared

On Thu, Oct 7, 2021 at 10:45 AM <amar at aries.res.in> wrote:

> Dear Prof. Jared,
>
> I am eagerly waiting for your suggestions regarding the issue of writing
> the output properly for STELLA calculations of a 9 solar mass ZAMS star.
> Please also suggest if you require something else to reproduce the issue. I
> am also trying continuously to get the output written properly but
> without any success.
>
>
> With thanks and regards,
> Amar
>
> ------------------------------
> *From: *amar at aries.res.in
> *To: *goldberg at physics.ucsb.edu
> *Cc: *mesa-users at lists.mesastar.org
> *Sent: *Tuesday, September 28, 2021 11:13:57 PM
> *Subject: *Re: [Mesa-users] Evolution of a 9M_sun ZAMS star up to to core
> collapse
>
> Dear Prof. Jared,
>
> Many thanks for your reply.
>
> Very interesting that such astonishingly low values of alpha_MLT lead to
> the stripping behavior you see, but that's not necessarily the point here.
> Here I wish to mention that, the mixing_lenth_alpha = 0.01 is required
> only in inlist_to_si_burn and the star has already been significantly
> stripped before this stage.
>
> In the Lbol plot, what does the green line represent? Is that the log_Lbol
> column of mesa.lbol_lnuc.txt? If so, something odd is going on indeed...
> Yes, the green in the Lbol plot is the log_Lbol column
> of  mesa.lbol_lnuc.txt.
>
> Do other files share this issue? What do the photospheric velocities and
> temperatures in mesa.swd.ph look like?Is mesa.lbol better?
> No, It seems (almost) all other files do not have the same issue. The
> photospheric velocities and temperatures in mesa.swd.ph look fine, but
> the log_L plot seems to have some issue. Also, there is no improvement from
> mesa.lbol.
>
> Have you modified any of the other STELLA input files, such as
> stella/strad/run/mesa.dat?
> Yes, just a little bit to produce light curve only up to 60 days. So,
> TcurB is set to 60.5.
>
> Would you mind sending your mesa.hyd and mesa.abn? Right now this isn't
> enough to reproduce the problem.
> I am attaching the mesa.abn, mesa.hyd, stella/strad/run/mesa.dat, the
> inlist_shock_part5, and a few other files from stella/res directory.
>
> Please let me know if something more is required to diagnose the problem.
>
> With thanks and regards,
> Amar
>
>
>
> ------------------------------
> *From: *goldberg at physics.ucsb.edu
> *To: *amar at aries.res.in
> *Cc: *mesa-users at lists.mesastar.org
> *Sent: *Tuesday, September 28, 2021 1:14:22 AM
> *Subject: *Re: [Mesa-users] Evolution of a 9M_sun ZAMS star up to to core
> collapse
>
> Hi Amar,
> Sorry for the delay. Very interesting that such astonishingly low values
> of alpha_MLT lead to the stripping behavior you see, but that's not
> necessarily the point here.
>
> As for the output, this looks like a STELLA issue rather than a MESA
> issue...
>
> Please suggest how to get the output written properly. I have devoted a
>> large amount of time in solving this issue without any success. Any
>> suggestion could be extremely helpful for me.
>
>
> In the Lbol plot, what does the green line represent? Is that the log_Lbol
> column of mesa.lbol_lnuc.txt? If so, something odd is going on indeed...
> Do other files share this issue? What do the photospheric velocities and
> temperatures in mesa.swd.ph look like? Is mesa.lbol better?  Have you
> modified any of the other STELLA input files, such as
> stella/strad/run/mesa.dat?
>
> Would you mind sending your mesa.hyd and mesa.abn? Right now this isn't
> enough to reproduce the problem.
>
> ~Jared
>
> On Mon, Sep 27, 2021 at 10:22 AM Amar Aryan via Mesa-users <
> mesa-users at lists.mesastar.org> wrote:
>
>> Dear MESA team,
>>
>> Please provide your valuable suggestion to get the output written
>> properly for the explosion of 9 solar mass ZAMS progenitor.
>>
>> I am waiting for any kind suggestion. Please also let me know if you
>> require any further information.
>>
>> With regards,
>> Amar
>> ----- Original Message -----
>> From: amar at aries.res.in
>> To: mesa-users at lists.mesastar.org
>> Cc: amararyan941 at gmail.com, goldberg at physics.ucsb.edu, fxt44 at mac.com
>> Sent: Wed, 22 Sep 2021 12:04:01 +0530 (IST)
>> Subject: Re: [Mesa-users] Evolution of a 9M_sun ZAMS star up to to core
>> collapse
>>
>> Dear MESA team,
>>
>> MESA Version : 11701
>> OS : UBUNTU 20.04
>> Sorry for the long email, but it was necessary to explain what I tried.
>>
>> A few months back, I tried to touch the lower limit of progenitors that
>> result in core-collapse supernovae (SNe). For this purpose, I took a 9.0
>> solar mass ZAMS progenitor and could evolve the model up to the onset of
>> core-collapse. However, a few changes were made to the inlist files in the
>> ~/mesa/star/test_suit/example_make_pre_ccsn directory. The most suspecting
>> modification was changing mixing_length_alpha to 0.01 in inlist_to_si_burn.
>> I read many literatures regarding mixing length and found a few commendable
>> suggestions. One such literature (Joyce et al. 2018, [
>> https://doi.org/10.3847/1538-4357/aab200 |
>> https://doi.org/10.3847/1538-4357/aab200 ] ) says that " In the same way
>> that αMLT is not a physical constant, it is also not a computational one.
>> Because it is a free parameter, the value of αMLT must be determined on an
>> individual basis in each stellar evolution code, and its value as
>> determined by different codes will reflect the prescriptive differences
>> among those codes—even though the target features to be reproduced are
>> identical ". Besides, the MLT is still not well understood and it is yet to
>> be explored. Further, as suggested by Prof. Jared, at the end of the
>> evolution we checked the position of our model on HR diagram and also
>> discovered that there are a few stripped stars that have been observed near
>> the position of our model star ( please see fig1.png ). This suggests that
>> our model could be physical as such stripped stars have been observed in
>> nature.
>> Fig1. The position of our model on HR diagram at the last evolutionary
>> stages (at Z=0.0185 close to Z_sun or Z_milkyWay). This figure is taken
>> from a lecture and has made use of Shenar et al. 2020, A&A, 634, 79.
>>
>> Thus, given the evidences, we assume our model to be physical and tried
>> to evolve the model just before the shock reached the stellar surface using
>> the ~/mesa/star/test_suit/example_make_ccsn_IIp directory with an explosion
>> energy of 0.5x10^51 ergs. Eventually, the evolution stops in the
>> inlist_shock_part3 stage by displaying a message min_m >= max_m. Recently,
>> I was following the conversation between Kai-an & Prof. Jared and found out
>> that this situation arrived because the ready_for_edep.mod had supersonic
>> velocities. Then, I changed those velocities to the order of d0 and this
>> worked as a sovereign remedy. The model evolved throughout and produced the
>> mesa.abn and mesa.hyd files, which were incorporated in STELLA to produce
>> the light curves and velocity evolution. But the outputs were not
>> thoroughly written in the mesa.lbol_lnuc.txt ( please see fig2.png ),
>> although the velocities (using mesa.vel_feII ) are written properly (
>> fig3.png ). The following settings were used to produce STELLA files :
>>
>> save_stella_data_when_terminate = .true.
>> save_stella_data_filename = 'mesa'
>> stella_num_points = 50 ! lesser number of zones are required for stripped
>> stars (also tried 60, 100)
>> stella_nz_extra = 0
>> stella_min_surf_logRho = -5 ! to remove the high velocity components,
>> (also tried -100, but same result)
>> stella_min_velocity = 0
>> stella_skip_inner_dm = 0.1
>> stella_skip_inner_v_limit = 5d+07
>> stella_mdot_years_for_wind = 1
>> stella_mdot_for_wind = 0.25
>> stella_v_wind = 10
>> stella_show_headers = .false.
>>
>> Fig2 : Terminal output and mesa.lbol_lnuc.txt file plot for luminosity
>> light curve
>>
>>
>> Fig. 3 : Velocity evolution. The blue triangle shows the observed FeII
>> 5169A velocity calculated from the spectrum.
>>
>> Please suggest how to get the output written properly. I have devoted a
>> large amount of time in solving this issue without any success. Any
>> suggestion could be extremely helpful for me.
>>
>> With regards,
>> Amar
>>
>>
>> From: fxt44 at mac.com
>> To: amararyan941 at gmail.com, amar at aries.res.in
>> Cc: fxt44 at mac.com, mesa-users at lists.mesastar.org
>> Sent: Friday, April 9, 2021 9:51:51 AM
>> Subject: Re: [Mesa-users] Evolution of a 9M_sun ZAMS star up to to core
>> collapse
>>
>> thanks amar.
>> fxt
>>
>>
>>
>>
>>
>>
>> On Apr 3, 2021, at 11:11 PM, Amar Aryan < [ mailto:amararyan941 at gmail.com
>> | amararyan941 at gmail.com ] > wrote:
>> Dear fxt,
>>
>> Here I attach the png plot almost at the end of the evolution
>> (inlist_finish).
>>
>> <grid_H_046755.png>
>>
>>
>> With best regards,
>> Amar
>>
>> On Sun, Apr 4, 2021 at 8:24 AM Francis Timmes < [ mailto:fxt44 at mac.com |
>> fxt44 at mac.com ] > wrote:
>>
>> BQ_BEGIN
>> hi amar,
>>
>> will you share a plot of the final mass fractions from this 9 msun run?
>>
>> fxt
>>
>>
>>
>>
>>
>>
>> > On Apr 3, 2021, at 10:29 AM, Amar Aryan via Mesa-users < [ mailto:
>> mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ] > wrote:
>> >
>> > Dear Bill,
>> >
>> > Many thanks for your prompt reply. Here I wish to mention that a few
>> months back, we were struggling to get going with a 12M_sun ZAMS star
>> progenitor but with some changes, we could successfully model ( with
>> excessive bits of help from Jared Goldberg ) the 12M_sun ZAMS star and
>> further got successful STELLA calculations providing the light curves and
>> velocity evolutions.
>> >
>> > With best regards,
>> > Amar
>> >
>> >
>> > From: [ mailto:paxton at kitp.ucsb.edu | paxton at kitp.ucsb.edu ]
>> > To: [ mailto:amar at aries.res.in | amar at aries.res.in ]
>> > Cc: [ mailto:mesa-users at lists.mesastar.org |
>> mesa-users at lists.mesastar.org ] , [ mailto:Amararyan941 at gmail.com |
>> Amararyan941 at gmail.com ]
>> > Sent: Saturday, April 3, 2021 10:48:21 PM
>> > Subject: Re: [Mesa-users] Evolution of a 9M_sun ZAMS star up to to core
>> collapse
>> >
>> > just a quick comment: i’ve never been able to get 9M beyond the
>> off-center Neon flash. Perhaps i’m just too impatient, but it takes longer
>> than I’m willing to wait for the burning to make its way slowly to the
>> center. with more massive models, the neon ignition is at the center so
>> things go smoothly. you are welcome to try, but it might go easier if you
>> can redefine your problem to 12M or more.
>> >
>> > cheers,
>> > bill
>> >
>> >
>> > On Apr 3, 2021, at 10:12 AM, Amar Aryan via Mesa-users < [ mailto:
>> mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ] > wrote:
>> >
>> > Dear MESA user team,
>> >
>> > I am trying to make a 9M_sun ZAMS model with Z=0.02 that explodes as a
>> type IIb SN. Gladly, I could evolve the star up to the stage of Fe core
>> infall, using the default star/test_suit/example_make_pre_ccsn with few
>> modifications. Although I could evolve the model up to Fe core infall, I am
>> not sure about a few parameters to be physical :
>> >
>> > Now here I briefly mention the changes in the inlist_files of
>> example_make_pre_ccsn directory :
>> >
>> > a) In inlist_common, varcontrol_target = 1d-3,
>> > mixing_length_alpha = 2.0
>> > mixing_delta_coeff_for_highT = 2.5
>> > f = 0.007 (Not sure if this is allowed!)
>> > f0= 0.001
>> >
>> > b) In inlist_set_alpha_mlt, x_ctrl(21) = 2.5
>> > x_ctrl(22) = 1.5
>> > x_ctrl(23) = 0.5
>> >
>> > 1) In Inlist_to_zams, varcontrol_target = 1d-5
>> >
>> > 2) In inlist_to_zams, varcontrol_target = 1d-5
>> >
>> > 3) In inlist_remove, varcontrol_target = 1d-5,
>> > mass_change = -1d-4
>> > star_H_mass_min_limit = 0.013
>> >
>> > 4) In inlist_before_remove, ! varcontrol_target = 1d-2 (Not used)
>> > Steps_to_take_before_terminate = 2
>> >
>> > 5) In inlist_to_si_burn, varcontrol_target = 5d-4,
>> > mixing_length_alpha = 0.01 (seems to be too low but anything greater
>> than 0.01 did not worked, setting this to 0 also failed!!)
>> > 6) In inlist_to_lgT9.9, varcontrol_target = 5d-4
>> >
>> > Please provide your valuable suggestions regarding f, f0,
>> mixing_lenth_alpha, and other major mistakes if any in the above
>> parameters.
>> >
>> > With best regards,
>> > Amar
>> >
>> >
>> >
>> > _______________________________________________
>> > [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org
>> ]
>> > [ https://lists.mesastar.org/mailman/listinfo/mesa-users |
>> https://lists.mesastar.org/mailman/listinfo/mesa-users ]
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org
>> ]
>> > [ https://lists.mesastar.org/mailman/listinfo/mesa-users |
>> https://lists.mesastar.org/mailman/listinfo/mesa-users ]
>> >
>>
>>
>>
>>
>> <grid_H_046755.png>
>>
>> BQ_END
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20211009/ebdd9c98/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 34417 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20211009/ebdd9c98/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 33087 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20211009/ebdd9c98/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31811 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20211009/ebdd9c98/attachment-0002.png>