[Mesa-users] Problem at He flash when atm_T_tau_opacity = 'varying'

Warrick Ball W.H.Ball at bham.ac.uk
Mon Oct 10 20:07:47 UTC 2022


Hi Claudia,

First, thanks very much for running all these extra simulations and for checking the EOS and opacity coverage.

If I've followed all your results correctly, what strikes me most is that the 1.4 Msun model fails to progress through the flash even with `fixed` atmospheric opacity and the usual GS98 opacity tables.  That computes the atmosphere structure using the opacity at the outermost meshpoint (τ=2/3 for an Eddington atmosphere) and is unlikely to fall off the opacity table.

I personally have limited capacity at the moment but I'll start by reproducing your failing run, seeing if the `1M_pre_ms_to_wd` test works at 1.4 Msun and, if so, trying to bridge the gap between them to find an issue.  I'm hoping that we can find something more useful than "the helium flash is difficult".  I'll try to get back to you before the end of this week.

Cheers,
Warrick

___________

Warrick Ball
Postdoc, School of Physics and Astronomy
University of Birmingham, Edgbaston, Birmingham B15 2TT
W.H.Ball at bham.ac.uk
+44 (0)121 414 4552

On Sat, 8 Oct 2022, c.reyes_saez at unsw.edu.au wrote:

> 
> Hi Warrick,
> 
>  
> 
> Thanks for your reply and suggestions. I simplified my inlists accordingly and turned off Ledoux criterion in all cases.
> 
> Then I tried two atm_T_tau_relations:
>
>  1. Eddington with kap_lowT_prefix = 'lowT_fa05_gs98'
>  2. Trampedach_solar with kap_lowT_prefix = 'lowT_rt14_ag89'
> 
> For each, I evolved models using atm_T_tau_opacity fixed, iterated and varying and initial masses 1.0 and 1.4.
> 
> With Eddington, MESA failed at the He flash when mass = 1.0 and opacity was “iterated” and “varying”. When mass = 1.4, it failed only when opacity was “fixed”.
> 
> With Trampedach_solar the code failed at the He flash when mass=1.0 and opacity “fixed”, and when mass=1.4 and opacity “varying”. I found that opacity “fixed” and “iterated” are basically the same in the HR diagram and in the profiles, but most of
> the times one of them failed when the other didn’t.
> 
> Based on this the problem is not the EoS coverage but I still got some FGONG profiles right after the peak luminosity. log_T is between 3 and 4, and log_rho is between -12 and -6 for all models at the outer layers, all within the MESA EoS coverage
> for solar-like composition.
> 
> I’m not sure about the opacity coverage, but log_kappa is between -4.2 and 2.2 at the outer layers. The models with more extreme values of log kappa are not necessary the ones that fail.
> 
>  
> 
> In the HR diagrams I zoomed into the “loop” around the He flash where models can fail. Sometimes MESA struggled for hours and it either got out of that loop or failed with a min_time_step error, while other times it went through quickly. I looked at
> some old tracks I had using table atmospheres instead of T_tau and MESA r7505 , and that loop never looked like it struggled.
> 
>  
> 
> I’d be happy to keep experimenting if you have additional suggestions.
> 
>  
> 
> Claudia.
> 
>  
> 
> Attached:
> 
> - one of my inlists
> 
> - HR diagrams
> 
> - “loops” in HR diagrams.
> 
>  
> 
> From: Warrick Ball <W.H.Ball at bham.ac.uk>
> Date: Tuesday, 4 October 2022 at 8:59 pm
> To: Claudia Reyes <c.reyes_saez at unsw.edu.au>
> Cc: mesa-users at lists.mesastar.org <mesa-users at lists.mesastar.org>
> Subject: Re: [Mesa-users] Problem at He flash when atm_T_tau_opacity = 'varying'
> 
> Hi Claudia,
> 
> The evolutionary track looks like it's failing at the helium flash, not the first thermal pulse.  Is that what you meant?
> 
> This will be a bit tedious, in part because of the time required to evolve up the RGB, but you can help us narrow things down.  The first step, is to reduce the number of options you're using so we can identify precisely what the problem is.  Can you
> try turning off diffusion, thermohaline mixing and the rotation controls?  Does the evolution still fail in the same way?  I don't expect any of those will fix the problem but it'll simplify the inlists.
> 
> Also, since the problem manifests for an Eddington atmosphere, can you try turning off `use_T_tau_gradr_factor` too?  The structure should end up the same anyway.  (If it doesn't, that's probably a bug!)
> 
> I suspect two possible sources of difficulty here.  First, to compute an atmosphere with the `'varying'` option, the atmosphere solver will call the EoS and opacity routines out in the optically thin layers of the atmosphere.  This might be
> cool/rarefied enough to fall off an EoS table.  What happens if you use `atm_T_tau_opacity = 'fixed'` (i.e., the default)?  If the run works in that case, then I expect that's the problem.  To pursue this, you could try writing out pulsation output
> files (e.g. FGONG or GYRE format) and having a look at the temperature and density of the outer layers, and compare them with MESA's EoS and opacity coverage.
> 
> The other possibility is that the Ledoux criterion is the problem.  You already found the old issue, which I'm not sure was ever satisfactorily resolved.  The other change to try, then, is turning off the Ledoux criterion (and leaving the `'varying'`
> atmosphere option on).
> 
> Once we know more precisely where the problem is, we can see how to fix it.
> 
> Cheers,
> Warrick
> 
> 
> ____________
> 
> Warrick Ball
> Postdoc, School of Physics and Astronomy
> University of Birmingham, Edgbaston, Birmingham B15 2TT
> W.H.Ball at bham.ac.uk
> +44 (0)121 414 4552
> 
> 
> On Tue, 4 Oct 2022, mesa-users at lists.mesastar.org wrote:
> 
> >
> > Dear All,
> >
> >  
> >
> > I'm trying to evolve a 1.0 solar mass star until the first thermal pulse using Ledoux criterium and atm_T_tau_opacity 'varying', with MESA r22.05.1. The inlist is copied below and next I copy the
> > modifications I have tried, most of them were suggestions from https://github.com/MESAHub/mesa/issues/80/
> >
> >  
> >
> > My same initial inlist reaches the first thermal pulse without issues when initial mass is 1.4.
> >
> > However, for 1 Msol the star gets cooler and dimmer instead of descending to the clump after reaching its peak giant luminosity. See red line in attached HR diagram.
> >
> >  
> >
> > Or, with some modifications (blue line, shifted to the right for clarity), the model reaches peak luminosity and continues with a zig-zag pattern perpendicular to the RGB until I kill the process.
> >
> > The same happens with any of the other atm_T_tau_relation options: solar_Hopf, Krishna_Swamy, Trampedach_solar.
> >
> >  
> >
> > I don’t think there is a bug report for this, I could only find an email related to a test suite case titled “Problem with atm_T_tau_opacity at the helium flash stage” from February 2021.
> >
> > Are there any other options I could try to get this model to the first thermal pulse?
> >
> >  
> >
> > Regards,
> >
> > Claudia.
> >
> >  
> >
> > [IMAGE][IMAGE]
> >
> >  
> >
> >  
> >
> > ------------------------
> >
> >  
> >
> > &star_job
> >
> >  
> >
> >     create_pre_main_sequence_model = .true.
> >
> >     pre_ms_T_c = 5d5
> >
> >     set_initial_number_retries = .false.
> >
> >     initial_zfracs = 3 ! GS98_zfracs
> >
> >     history_columns_file = 'my_history_columns.list'
> >
> >     show_retry_counts_when_terminate = .true.
> >
> >     show_timestep_limit_counts_when_terminate = .true.
> >
> >  
> >
> > / ! end of star_job namelist
> >
> >  
> >
> >  
> >
> > &eos
> >
> >   ! eos options
> >
> >   ! see eos/defaults/eos.defaults
> >
> > / ! end of eos namelist
> >
> >  
> >
> > &kap
> >
> >  
> >
> >     !opacities with GS98 abundances
> >
> >     kap_file_prefix = 'gs98'
> >
> >     kap_lowT_prefix = 'lowT_fa05_gs98'
> >
> >     kap_CO_prefix = 'gs98_co'
> >
> >  
> >
> >     !CO enhanced opacities
> >
> >     use_Type2_opacities = .true.
> >
> >     Zbase = 0.02d0
> >
> > / ! end of kap namelist
> >
> >  
> >
> > &controls
> >
> >  
> >
> >     initial_mass = 1.00 ! in Msun units
> >
> >     initial_z = 0.0187
> >
> >     initial_y = 0.2718
> >
> >  
> >
> >   ! stop when the first thermal pulse occurs
> >
> >     stop_at_phase_TP_AGB = .true.    
> >
> >  
> >
> >     cool_wind_RGB_scheme = 'Reimers'
> >
> >     cool_wind_AGB_scheme = 'Blocker'
> >
> >     RGB_to_AGB_wind_switch = 1d-4
> >
> >     Reimers_scaling_factor = 0.1
> >
> >     Blocker_scaling_factor = 0.2
> >
> >     max_wind = 1d-3
> >
> >  
> >
> >     D_SH_factor =  1.0
> >
> >     D_SSI_factor = 1.0
> >
> >     D_ES_factor =  1.0
> >
> >     D_GSF_factor = 1.0
> >
> >     D_DSI_factor = 1.0
> >
> >     D_ST_factor = 0.0
> >
> >     am_D_mix_factor = 0.033
> >
> >     am_gradmu_factor = 0.05
> >
> >  
> >
> >     do_element_diffusion = .true.
> >
> >     atm_option = 'T_tau'
> >
> >     atm_T_tau_relation = 'Eddington'
> >
> >     atm_T_tau_opacity = 'varying'
> >
> >  
> >
> >     okay_to_reduce_gradT_excess = .true.
> >
> >     Pextra_factor = 2.0
> >
> >  
> >
> >     ! ####
> >
> >     use_Ledoux_criterion = .true.
> >
> >     alpha_semiconvection = 0.1
> >
> >     thermohaline_coeff = 666.0
> >
> >  
> >
> >     mlt_option = 'Henyey'
> >
> >     mixing_length_alpha = 1.90  
> >
> >    
> >
> >     ! Core overshoot
> >
> >     overshoot_scheme(1) = 'exponential'
> >
> >     overshoot_zone_type(1) = 'any'
> >
> >     overshoot_zone_loc(1) = 'core'
> >
> >     overshoot_bdy_loc(1) = 'top'
> >
> >     overshoot_f(1) = 0.016
> >
> >     overshoot_f0(1) = 0.008
> >
> >     overshoot_mass_full_off(1) = 1.10
> >
> >     overshoot_mass_full_on(1) = 1.30
> >
> >    
> >
> >     ! shell overshoot
> >
> >     overshoot_scheme(2) = 'exponential'
> >
> >     overshoot_zone_type(2) = 'any'
> >
> >     overshoot_zone_loc(2) = 'shell'
> >
> >     overshoot_bdy_loc(2) = 'any'
> >
> >     overshoot_f(2) = 0.0174
> >
> >     overshoot_f0(2) = 0.0087
> >
> >  
> >
> >     energy_eqn_option = 'dedt'
> >
> >     use_gold_tolerances = .true.
> >
> >  
> >
> >       delta_lg_XH_cntr_max = -1
> >
> >       max_dq = 1d-3
> >
> >       varcontrol_target = 1d-3
> >
> >       max_allowed_nz = 50000
> >
> >  
> >
> >       delta_lgTeff_limit = 0.005
> >
> >       delta_lgTeff_hard_limit = 0.01
> >
> >       delta_lgL_limit = 0.02
> >
> >  
> >
> >  
> >
> >   ! output
> >
> >      history_interval = 1
> >
> >      terminal_interval = 10
> >
> >      write_header_frequency = 20
> >
> >      photo_digits = 5
> >
> >      photo_interval = 100
> >
> >      write_profiles_flag = .false.
> >
> >  
> >
> >      star_history_name = 'history.data'
> >
> >  
> >
> > / ! end of controls namelist
> >
> > ------------------------------------------------------------------------------------------------------
> >
> >  
> >
> > Modifications :
> >
> >  
> >
> >     change_initial_net = .true.      
> >
> >     new_net_name = 'mesa_49.net'  
> >
> >     change_v_flag = .true.
> >
> >     new_v_flag = .true.
> >
> >
> >
> >     use_T_tau_gradr_factor = .true.
> >
> >     atm_T_tau_max_steps = 2000 ! default is 500
> >
> >     atm_T_tau_errtol = 1d-8    ! default is 1d-7
> >
> >     timestep_factor_for_retries = 0.5
> >
> >     use_dPrad_dm_form_of_T_gradient_eqn = .true.
> >
> >     corr_coeff_limit = 1d-10
> >
> >     use_gold2_tolerances = .true.
> >
> >     gold_iter_for_resid_tol2 = 10
> >
> >     gold_iter_for_resid_tol3 = 10
> >
> >     gold_tol_residual_norm3 = 1d-6
> >
> >     gold_tol_max_residual3 = 1d-3
> >
> >     gold_solver_iters_timestep_limit = 20
> >
> >     solver_iters_timestep_limit = 50
> >
> >     scale_max_correction = 0.05d0
> >
> >     convergence_ignore_equL_residuals = .false.
> >
> >     delta_lgL_He_limit = 0.0001 ! Avoids running past the flash too fast
> >
> >     correction_xa_limit = 3d-2
> >
> >     fix_d_eos_dxa_partials = .true
> >
> >     max_v_div_cs_for_convection = 100
> >
> >     max_conv_vel_div_csound = 1d0 ! Limit convection speed
> >
> >     use_gradT_actual_vs_gradT_MLT_for_T_gradient_eqn = .true.
> >
> >     mesh_delta_coeff = 0.5
> >
> >     time_delta_coeff = 0.5
> >
> >     min_timestep_limit = 1d-8
> >
> >
> >
> 
> 
>


More information about the Mesa-users mailing list