[Mesa-users] Evolution of a 9M_sun ZAMS star up to to core collapse
amar at aries.res.in
amar at aries.res.in
Mon Oct 18 06:42:03 UTC 2021
Dear Prof. Jared,
I am really very grateful to you for providing thoughtful suggestions and working hard to get this issue resolved. Here are my attempts to your suggestions :
(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?).
I agree with your assumptions regarding stripping.
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.
The surface density cuts were applied to remove the very high-velocity material. However, I have also tried with lesser cuts (e.g., -10, -15 and even -100), but either I get segmentation fault or the output did not get properly written as earlier.
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
BQ_BEGIN
use_split_merge_amr = .true.
split_merge_amr_logtau_zoing = .true.
split_merge_amr_log_zoning = .false.
BQ_END
in the other inlists except part5,
and
BQ_BEGIN
split_merge_amr_logtau_zoning = .false.
split_merge_amr_log_zoning = .false.
BQ_END
in inlist_shock_part5 to give a better mesh distribution in the envelope, assuming the surface of the initial model is sufficiently resolved.
No, unfortunately, these settings also could not resolve the issue!
Fortunately, I found a workaround for this situation. I tried another publicly available explosion code known as SNEC ( Morozova et. al 2015 ). It could simulate the synthetic explosion. Below are my results :
But, I would still like to get STELLA results due to its ease in usability and inclusion of CSM profile when needed.
With lots of thanks and regards,
Amar
From: goldberg at physics.ucsb.edu
To: amar at aries.res.in
Cc: mesa-users at lists.mesastar.org, Amararyan941 at gmail.com
Sent: Sunday, October 10, 2021 6:19:04 AM
Subject: Re: [Mesa-users] Evolution of a 9M_sun ZAMS star up to to core collapse
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:
and here's the Ni distribution.
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
BQ_BEGIN
use_split_merge_amr = .false.
BQ_END
in inlist_infall, and then
BQ_BEGIN
use_split_merge_amr = .true.
split_merge_amr_logtau_zoing = .true.
split_merge_amr_log_zoning = .false.
BQ_END
in the other inlists except part5,
and
BQ_BEGIN
split_merge_amr_logtau_zoning = .false.
split_merge_amr_log_zoning = .false.
BQ_END
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 < [ mailto:amar at aries.res.in | amar at aries.res.in ] > wrote:
BQ_BEGIN
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: [ mailto:amar at aries.res.in | amar at aries.res.in ]
To: [ mailto:goldberg at physics.ucsb.edu | goldberg at physics.ucsb.edu ]
Cc: [ mailto:mesa-users at lists.mesastar.org | 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 [ http://mesa.swd.ph/ | 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 [ http://mesa.swd.ph/ | 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: [ mailto:goldberg at physics.ucsb.edu | goldberg at physics.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 ]
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...
BQ_BEGIN
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.
BQ_END
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 [ http://mesa.swd.ph/ | 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 < [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ] > wrote:
BQ_BEGIN
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: [ mailto:amar at aries.res.in | amar at aries.res.in ]
To: [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ]
Cc: [ mailto:amararyan941 at gmail.com | amararyan941 at gmail.com ] , [ mailto:goldberg at physics.ucsb.edu | goldberg at physics.ucsb.edu ] , [ mailto:fxt44 at mac.com | 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 ] | [ 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: [ mailto:fxt44 at mac.com | fxt44 at mac.com ]
To: [ mailto:amararyan941 at gmail.com | amararyan941 at gmail.com ] , [ mailto:amar at aries.res.in | amar at aries.res.in ]
Cc: [ mailto:fxt44 at mac.com | fxt44 at mac.com ] , [ mailto:mesa-users at lists.mesastar.org | 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: [ mailto:amararyan941 at gmail.com | amararyan941 at gmail.com ] | [ 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: [ mailto:fxt44 at mac.com | fxt44 at mac.com ] | [ 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: [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ] | [ 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: [ mailto:paxton at kitp.ucsb.edu | paxton at kitp.ucsb.edu ] | [ mailto:paxton at kitp.ucsb.edu | paxton at kitp.ucsb.edu ] ]
> To: [ mailto: [ mailto:amar at aries.res.in | amar at aries.res.in ] | [ mailto:amar at aries.res.in | amar at aries.res.in ] ]
> Cc: [ mailto: [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ] | [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ] ] , [ mailto: [ mailto:Amararyan941 at gmail.com | Amararyan941 at gmail.com ] | [ 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: [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ] | [ 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: [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ] | [ 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 ] | [ https://lists.mesastar.org/mailman/listinfo/mesa-users | https://lists.mesastar.org/mailman/listinfo/mesa-users ] ]
>
>
>
>
>
> _______________________________________________
> [ mailto: [ mailto:mesa-users at lists.mesastar.org | mesa-users at lists.mesastar.org ] | [ 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 ] | [ https://lists.mesastar.org/mailman/listinfo/mesa-users | https://lists.mesastar.org/mailman/listinfo/mesa-users ] ]
>
<grid_H_046755.png>
BQ_END
_______________________________________________
[ 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 ]
BQ_END
BQ_END
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20211018/19b36191/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lum.png
Type: image/png
Size: 23569 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20211018/19b36191/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vel.png
Type: image/png
Size: 21275 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20211018/19b36191/attachment-0001.png>
-------------- 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/20211018/19b36191/attachment-0002.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/20211018/19b36191/attachment-0003.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/20211018/19b36191/attachment-0004.png>
More information about the Mesa-users
mailing list