mesa-users — open list for mesa comments, questions, & answers

[mesa-users] GYRE 5.0 release

[RICHARD H D T. <tow...@as...>]

Hi folks --

I'm pleased to announce the long-awaited release of GYRE 5.0. This release introduces a number of significant changes, which are described in the release notes which can be found at:

https://bitbucket.org/rhdtownsend/gyre/wiki/Release%20Notes

As usual, the source code can be downloaded from:

https://bitbucket.org/rhdtownsend/gyre/downloads/

Rich

Re: [mesa-users] instability strip definition (no MESA content)

[Aaron D. <aar...@gm...>]

Thanks, Earl and Rob, for your answers!

Aaron

On Thu, Jun 1, 2017 at 1:35 PM, Robert Farmer <rjf...@as...> wrote:

> Hi
>
> There is always the brute force method to find the boundaries to the
> instability regions, see for instance fig 9 in MESA3.
>
> Rob
>
> On Thu, Jun 1, 2017 at 8:13 AM, Aaron Dotter <aar...@gm...>
> wrote:
>
>> Hi all,
>>
>> (Sorry for the non-MESA request.  Too much expertise on this mailing list
>> to resist asking here!)
>>
>> Does anyone have a favorite definition of the realm of the instability
>> strip in the H-R diagram?  There are lots of cartoons out there, most of
>> which are vague and/or conflicting.  I'm not aware of a solid theoretical
>> or empirical definition of the bounds of the IS in terms of Teff, surface
>> gravity, and/or luminosity.
>>
>> Thanks,
>> Aaron
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
>

Re: [mesa-users] instability strip definition (no MESA content)

[Robert F. <rjf...@as...>]

Hi

There is always the brute force method to find the boundaries to the
instability regions, see for instance fig 9 in MESA3.

Rob

On Thu, Jun 1, 2017 at 8:13 AM, Aaron Dotter <aar...@gm...> wrote:

> Hi all,
>
> (Sorry for the non-MESA request.  Too much expertise on this mailing list
> to resist asking here!)
>
> Does anyone have a favorite definition of the realm of the instability
> strip in the H-R diagram?  There are lots of cartoons out there, most of
> which are vague and/or conflicting.  I'm not aware of a solid theoretical
> or empirical definition of the bounds of the IS in terms of Teff, surface
> gravity, and/or luminosity.
>
> Thanks,
> Aaron
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

Re: [mesa-users] instability strip definition (no MESA content)

[Bill P. <pa...@ki...>]

Hi Earl,

this is just to say how much I appreciate your input to mesa-users.  keep it up!

cheers,
bill


On Jun 1, 2017, at 10:11 AM, Earl Bellinger wrote:

> errata: I found a little mistake in my previous email - I meant to say
> that RR Lyrae are core-and-shell burning, not double-shell burning.
> 
> Best regards,
> Earl Bellinger
> 
> ---
> www.earlbellinger.com
> Department of Astronomy, Yale University
> Stellar Ages & Galactic Evolution Group, Max Planck Institute
> 
> 
> On Thu, Jun 1, 2017 at 12:03 PM, Earl Bellinger <bel...@mp...> wrote:
>> Dear Aaron,
>> 
>> I am probably not going to say anything you don't already know, but
>> here are my two cents on the matter...
>> 
>> From a theoretical point of view, the instability strip is found by
>> determining when stars become unstable to fundamental (or
>> low-overtone) radial oscillations. More specifically, this occurs when
>> the imaginary component of radial mode eigenfrequencies change sign.
>> 
>> This happens at several stages during evolution: on the main sequence
>> (delta Scuti and other types of stars), during a "blue straggle" (SX
>> Phoenicis variables), during the Hertzsprung gap in the sub-giant
>> phase (first-crossing Cepheids), during blue loops after ignition of
>> core helium burning in the star's ascent up the giant branch
>> (Cepheids), on the horizontal branch with double-shell burning (RR
>> Lyraes), etc...
>> 
>> On the red edge, the location of the sign change depends on the
>> details of pulsation-convection interaction which, as far as I know,
>> is neglected in pulsation codes such as GYRE and ADIPLS, and as such
>> is typically regarded as being unreliable. The location of the blue
>> edge is more reliable but depends for example on one's choice of the
>> mixing length parameter. So a theoretical definition of the
>> instability strip in terms of Teff, log g, or L will depend on
>> potentially arbitrary assumptions. That being said, one can find
>> empirical instability strips from real stars in the literature.
>> 
>> I hope what I have said is correct. If there are any errors, I hope
>> someone will please correct me.
>> 
>> Best regards,
>> Earl Bellinger
>> 
>> ---
>> www.earlbellinger.com
>> Department of Astronomy, Yale University
>> Stellar Ages & Galactic Evolution Group, Max Planck Institute
>> 
>> 
>> On Thu, Jun 1, 2017 at 11:13 AM, Aaron Dotter <aar...@gm...> wrote:
>>> Hi all,
>>> 
>>> (Sorry for the non-MESA request.  Too much expertise on this mailing list to
>>> resist asking here!)
>>> 
>>> Does anyone have a favorite definition of the realm of the instability strip
>>> in the H-R diagram?  There are lots of cartoons out there, most of which are
>>> vague and/or conflicting.  I'm not aware of a solid theoretical or empirical
>>> definition of the bounds of the IS in terms of Teff, surface gravity, and/or
>>> luminosity.
>>> 
>>> Thanks,
>>> Aaron
>>> 
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> mesa-users mailing list
>>> mes...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] instability strip definition (no MESA content)

[Earl B. <bel...@mp...>]

errata: I found a little mistake in my previous email - I meant to say
that RR Lyrae are core-and-shell burning, not double-shell burning.

Best regards,
Earl Bellinger

---
www.earlbellinger.com
Department of Astronomy, Yale University
Stellar Ages & Galactic Evolution Group, Max Planck Institute


On Thu, Jun 1, 2017 at 12:03 PM, Earl Bellinger <bel...@mp...> wrote:
> Dear Aaron,
>
> I am probably not going to say anything you don't already know, but
> here are my two cents on the matter...
>
> From a theoretical point of view, the instability strip is found by
> determining when stars become unstable to fundamental (or
> low-overtone) radial oscillations. More specifically, this occurs when
> the imaginary component of radial mode eigenfrequencies change sign.
>
> This happens at several stages during evolution: on the main sequence
> (delta Scuti and other types of stars), during a "blue straggle" (SX
> Phoenicis variables), during the Hertzsprung gap in the sub-giant
> phase (first-crossing Cepheids), during blue loops after ignition of
> core helium burning in the star's ascent up the giant branch
> (Cepheids), on the horizontal branch with double-shell burning (RR
> Lyraes), etc...
>
> On the red edge, the location of the sign change depends on the
> details of pulsation-convection interaction which, as far as I know,
> is neglected in pulsation codes such as GYRE and ADIPLS, and as such
> is typically regarded as being unreliable. The location of the blue
> edge is more reliable but depends for example on one's choice of the
> mixing length parameter. So a theoretical definition of the
> instability strip in terms of Teff, log g, or L will depend on
> potentially arbitrary assumptions. That being said, one can find
> empirical instability strips from real stars in the literature.
>
> I hope what I have said is correct. If there are any errors, I hope
> someone will please correct me.
>
> Best regards,
> Earl Bellinger
>
> ---
> www.earlbellinger.com
> Department of Astronomy, Yale University
> Stellar Ages & Galactic Evolution Group, Max Planck Institute
>
>
> On Thu, Jun 1, 2017 at 11:13 AM, Aaron Dotter <aar...@gm...> wrote:
>> Hi all,
>>
>> (Sorry for the non-MESA request.  Too much expertise on this mailing list to
>> resist asking here!)
>>
>> Does anyone have a favorite definition of the realm of the instability strip
>> in the H-R diagram?  There are lots of cartoons out there, most of which are
>> vague and/or conflicting.  I'm not aware of a solid theoretical or empirical
>> definition of the bounds of the IS in terms of Teff, surface gravity, and/or
>> luminosity.
>>
>> Thanks,
>> Aaron
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>

Re: [mesa-users] instability strip definition (no MESA content)

[Earl B. <bel...@mp...>]

Dear Aaron,

I am probably not going to say anything you don't already know, but
here are my two cents on the matter...

>From a theoretical point of view, the instability strip is found by
determining when stars become unstable to fundamental (or
low-overtone) radial oscillations. More specifically, this occurs when
the imaginary component of radial mode eigenfrequencies change sign.

This happens at several stages during evolution: on the main sequence
(delta Scuti and other types of stars), during a "blue straggle" (SX
Phoenicis variables), during the Hertzsprung gap in the sub-giant
phase (first-crossing Cepheids), during blue loops after ignition of
core helium burning in the star's ascent up the giant branch
(Cepheids), on the horizontal branch with double-shell burning (RR
Lyraes), etc...

On the red edge, the location of the sign change depends on the
details of pulsation-convection interaction which, as far as I know,
is neglected in pulsation codes such as GYRE and ADIPLS, and as such
is typically regarded as being unreliable. The location of the blue
edge is more reliable but depends for example on one's choice of the
mixing length parameter. So a theoretical definition of the
instability strip in terms of Teff, log g, or L will depend on
potentially arbitrary assumptions. That being said, one can find
empirical instability strips from real stars in the literature.

I hope what I have said is correct. If there are any errors, I hope
someone will please correct me.

Best regards,
Earl Bellinger

---
www.earlbellinger.com
Department of Astronomy, Yale University
Stellar Ages & Galactic Evolution Group, Max Planck Institute


On Thu, Jun 1, 2017 at 11:13 AM, Aaron Dotter <aar...@gm...> wrote:
> Hi all,
>
> (Sorry for the non-MESA request.  Too much expertise on this mailing list to
> resist asking here!)
>
> Does anyone have a favorite definition of the realm of the instability strip
> in the H-R diagram?  There are lots of cartoons out there, most of which are
> vague and/or conflicting.  I'm not aware of a solid theoretical or empirical
> definition of the bounds of the IS in terms of Teff, surface gravity, and/or
> luminosity.
>
> Thanks,
> Aaron
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

[mesa-users] instability strip definition (no MESA content)

[Aaron D. <aar...@gm...>]

Hi all,

(Sorry for the non-MESA request.  Too much expertise on this mailing list
to resist asking here!)

Does anyone have a favorite definition of the realm of the instability
strip in the H-R diagram?  There are lots of cartoons out there, most of
which are vague and/or conflicting.  I'm not aware of a solid theoretical
or empirical definition of the bounds of the IS in terms of Teff, surface
gravity, and/or luminosity.

Thanks,
Aaron

Re: [mesa-users] Changes to the gravitational constant

[Dennis S. <den...@sy...>]

You can also have a look at the mesastar.org and click Add-ons.

There is one example of changing G in fact.

Dennis/

On 1/06/2017 6:43, Earl Bellinger wrote:
> For a guide on writing a custom run_stars_extras.f, here are my notes
> in case they are useful on Josiah Schwab's MESA Summer School 2016
> tutorial:
> https://research-engine.appspot.com/5791865672564736/wiki/page/Extending_MESA
>
> Best regards,
> Earl Bellinger
>
> ---
> www.earlbellinger.com
> Department of Astronomy, Yale University
> Stellar Ages & Galactic Evolution Group, Max Planck Institute
>
>
> On Wed, May 31, 2017 at 1:26 PM, Robert Farmer <rjf...@as...> wrote:
>> Hi
>>
>> You need to set the s%cgrav(1:s%nz) array with the value of the gravitational constant you want.
>>
>> Have a look in the $MESA_DIR/star/other/other_cgrav.f90 file for how to hook up an other_ routine for changing the cgrav value
>>
>> Rob
>>
>>
>>
>> On Wed, May 31, 2017 at 10:16 AM, Nsamba Benard <nsa...@gm...> wrote:
>>> Hello,
>>>
>>> We are trying to make some changes on the gravitational constant so that it varies with a parameter say radius.
>>>
>>> say.    Gnew = Go(1 + constant*radius)
>>>
>>> I am supposed to do this in the run_star_extras but not sure how to do it. Can someone help me how to incorporate this.
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Benard
>>> ----------------------------------------------------------------------------------------------------------
>>> Benard Nsamba
>>> PhD student                                  Centro de Astrofisica
>>>                                                      Universidade do Porto
>>>                                                      Rua das Estrelas
>>> Tel: +351 920 404 108                   4150-762 Porto, Portugal
>>> E-mail: ben...@as...
>>> Skype: benardnsamba
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> mesa-users mailing list
>>> mes...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

Re: [mesa-users] New public release 9793

[Willie S. <cw...@gm...>]

Congratulations and thank you to all involved.  Downloading now.

Willie


> On May 31, 2017, at 1:40 PM, Evan Bauer <eb...@ph...> wrote:
> 
> Hello MESA Users,
> 
> We are happy to announce a new MESA public release version: 9793. Release notes below.
> 
> Cheers,
> Evan (on behalf of Pablo, Rich, Josiah, Rob, Aaron, Frank, and Bill)
> 
> 
> 
> 
> MESA 9793 - Release Notes
> =====================
> 
> 
> Binary
> -------
> 
> Binary module terminal output has been significantly changed to provide more useful information at runtime.
> 
> 
> Element Diffusion
> -------------------
> 
> Option added to simplify the user interface for diffusion classes (diffusion_use_full_net = .true.). This assigns each isotope in the current net to its own diffusion class, circumventing the need to manually specify each isotope that serves as a class representative.
> 
> Default solver for the Burgers equations has been changed to properly account for electron degeneracy in white dwarfs. The old solver based on the work of Thoul et al. (1994) for the Sun is still available, but is no longer the default.
> 
> The new diffusion solver (diffusion_use_cgs_solver = .true.) now accounts for thermal diffusion terms in the Burgers equations. It includes options to turn off these terms smoothly as a function of electron degeneracy, since they are invalid and usually negligible for WD interiors. With these thermal diffusion terms included for non-degenerate material, this solver is appropriate for use on the main sequence as well as in WDs. Thus, in most circumstances, the user no longer needs to worry about switching between solvers for different types of diffusion problems.
> 
> The new diffusion solver also supports radiative levitation now, where before this required using the solver based on Thoul et al. (1994) (as revised by Haili Hu to include extra driving terms from radiative levitation). The user interface remains unchanged.
> Note that radiative levitation is limited to isotopes that are supported by OP data for calculating radiative accelerations, so one must be careful to avoid using a class structure involving isotopes that aren’t supported. In particular, radiative levitation with the new diffusion_use_full_net option will cause problems for any net including isotopes not supported by OP.
> 
> “diffusion_gamma_full_on/off” has been changed to 150-175 as default, meaning diffusion occurs for all material that has not crystallized.
> 
> An option that accounts for Ne22 sedimentation heating in old, cooling WDs is now available.
> 
> Minor bug fixed in calculating the ionization states for diffusion classes. This only affected diffusion, and only mattered when background material for diffusion was not hydrogen.
> 
> Fixed a bug that could cause timesteps to crash unnecessarily due to stale diff_iters value. (Thanks to Bill Wolf for bug report!)
> 
> 
> GYRE
> -------
> 
> GYRE has been upgraded to 5.0rc6. There are significant changes to GYRE’s input files in this updated version; users should consult example input files, and/or the online documentation, for details. https://bitbucket.org/rhdtownsend/gyre/wiki/Home <https://bitbucket.org/rhdtownsend/gyre/wiki/Home>
> 
> 
> pgstar
> -------
> 
> Pgstar plots now have the option to call a decorator function, set in a users run_star_extras file in a similar way to the other_* functions, this allows additional customization options for all pgplots. See $MESA_DIR/star/other/pgstar_decorator.f90 for an example.
> 
> Network plots now have the option to show a colorbar for the abundances.
> 
> 
> Rates
> ------
> 
> The default version of JINA reaclib provided with MESA has been updated to reaclib v2.2.  To restore the previous default, use
>        jina_reaclib_filename = ‘jina_reaclib_results_20130213default2'
> in your star_job inlist. When switching between different reaclib versions, users must either: run $MESA_DIR/empty_caches or set rates_cache_dir in their star_job inlist to a local folder. Otherwise mesa will not use any rates from the new reaclib version that have been cached from a previous version. Running  $MESA_DIR/clean will also clear the caches.
> 
> It is now much simpler for a user to specify a custom table providing a weak reaction rate. See the test suite case "custom_rates" for examples of providing user-specified reaction rate tables.
> 
> 
> Miscellaneous
> ---------------
> 
> Bug fix for redo_conv_for_dr_lt_mixing_length so that it now applies to central convection zones.
> 
> The default opacity files all use gs98 relative metal fractions. (Previously, this was a mix of gn93 and gs98).  As a reminder, these choices are controlled by the star_job options
> 
>        kappa_file_prefix
>        kappa_lowT_prefix
>        kappa_CO_prefix
> 
> The star_job options associated with the blend (in Z) between OPAL and HELM and the blend (in T) between ionized and neutral HELM have been refactored.  See the documentation for the controls:
> 
>        set_HELM_OPAL_Zs
>        Z_all_HELM
>        Z_all_OPAL
> 
>        set_HELM_ion_neutral_blends
>        max_logRho_neutral_HELM
>        logT_neutral_HELM
>        logT_ion_HELM
> 
> While "stella" is now part of the mesa release, it is not yet ready for general use.  Please wait for the next release to begin using it.
> 
> A file containing a summary of the changes to inlist defaults is attached. Some internal and experimental controls are not included.
> 
> <changes.txt>
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] Changes to the gravitational constant

[Earl B. <bel...@mp...>]

For a guide on writing a custom run_stars_extras.f, here are my notes
in case they are useful on Josiah Schwab's MESA Summer School 2016
tutorial:
https://research-engine.appspot.com/5791865672564736/wiki/page/Extending_MESA

Best regards,
Earl Bellinger

---
www.earlbellinger.com
Department of Astronomy, Yale University
Stellar Ages & Galactic Evolution Group, Max Planck Institute


On Wed, May 31, 2017 at 1:26 PM, Robert Farmer <rjf...@as...> wrote:
>
> Hi
>
> You need to set the s%cgrav(1:s%nz) array with the value of the gravitational constant you want.
>
> Have a look in the $MESA_DIR/star/other/other_cgrav.f90 file for how to hook up an other_ routine for changing the cgrav value
>
> Rob
>
>
>
> On Wed, May 31, 2017 at 10:16 AM, Nsamba Benard <nsa...@gm...> wrote:
>>
>> Hello,
>>
>> We are trying to make some changes on the gravitational constant so that it varies with a parameter say radius.
>>
>> say.    Gnew = Go(1 + constant*radius)
>>
>> I am supposed to do this in the run_star_extras but not sure how to do it. Can someone help me how to incorporate this.
>>
>> Thank you.
>>
>> Cheers,
>> Benard
>> ----------------------------------------------------------------------------------------------------------
>> Benard Nsamba
>> PhD student                                  Centro de Astrofisica
>>                                                     Universidade do Porto
>>                                                     Rua das Estrelas
>> Tel: +351 920 404 108                   4150-762 Porto, Portugal
>> E-mail: ben...@as...
>> Skype: benardnsamba
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>

Re: [mesa-users] New public release 9793

[Evan B. <eb...@ph...>]

Hi All,

It looks like my mail client may have done something weird with my attempt to attach “changes.txt”, so I’m just copying all that inline here to make sure everyone can see it.

Cheers,
Evan


# star_job
## removed
  - use_se_output: .false.
  - set_Z_all_HELM: .false.

## added
  + relax_initial_angular_momentum: .false.
  + max_steps_to_relax_angular_momentum: 1000
  + timescale_for_relax_angular_momentum: 1d-10
  + max_dt_for_relax_angular_momentum: 1d-9
  + num_timescales_for_relax_angular_momentum: 1000
  + relax_angular_momentum_filename: ''
  + remove_initial_center_by_entropy: 0
  + remove_center_by_entropy: 0
  + fallback_check_total_energy: .true.
  + remove_initial_surface_by_v_surf_km_s: 0
  + remove_surface_by_v_surf_km_s: 0
  + set_HELM_OPAL_Zs: .false.
  + Z_all_OPAL: 0.04d0
  + set_HELM_ion_neutral_blends: .false.
  + max_logRho_neutral_HELM: 3d0
  + logT_neutral_HELM: 5.0d0
  + logT_ion_HELM: 6.5d0
  + eosDT_use_linear_interp_for_X: .false.

## changed
  * Z_all_HELM: 1d99 => 0.04d0
  * min_x_for_keep: 1d-23 => 1d-5
  * min_x_for_n: 1d-18 => 1d-4
  * min_x_for_add: 1d-17 => 1d-4
  * kappa_file_prefix: 'gn93' => 'gs98'
  * kappa_CO_prefix: 'gn93_co' => 'gs98_co'

# controls
## removed
  - use_eosDE_get: .true.
  - helmeos_max_logRho_neutral: -1d99
  - helmeos_logT_neutral: -1d99
  - helmeos_logT_ion: -1d99

## added
  + center_R_lower_limit: -1
  + mach1_mass_upper_limit: -1
  + use_fixed_L_for_BB_outer_BC: .false.
  + fixed_L_for_BB_outer_BC: 0
  + max_logT_for_net: 10.2d0
  + cgs_thermal_diffusion_eta_full_on: 0d0
  + cgs_thermal_diffusion_eta_full_off: 2d0
  + do_Ne22_sedimentation_heating: .false.
  + diffusion_use_full_net: .false.
  + eps_Ne22_sedimentation_factor: 1
  + tol_bad_max_correction: 0d0
  + dvdt_visc_factor: 1d0
  + use_artificial_viscosity: .false.
  + artificial_viscosity_Q_shift: -1
  + post_shock_viscosity_decay_factor: -1
  + pre_shock_viscosity_decay_factor: -1
  + art_visc_full_on_logRho_ge_this: -99
  + art_visc_full_off_logRho_le_this: -99
  + force_timestep_min: 0
  + force_timestep_min_years: 0
  + force_timestep_min_factor: 2d0
  + limit_for_max_E_residual: 1d99
  + hard_limit_for_max_E_residual: 1d99

## changed
  * diffusion_use_cgs_solver: .false. => .true.
  * diffusion_v_max: 1d-5 => 1d-3
  * diffusion_gamma_full_off: 50 => 175
  * diffusion_gamma_full_on: 40 => 150
  * kap_phot_factor_for_kap_floor: 1d0 => -1d0
  * Gamma_lnS_eps_grav_full_on: 160d0 => 150d0
  * Gamma_lnS_eps_grav_full_off: 130d0 => 120d0
  * shock_spread_linear: -1d0 => 0
  * shock_spread_quadratic: -1d0 => 1d-3


# binary_job
## removed
  - trace_binary_rlo: .true.

## added
  + show_binary_log_description_at_start: .true.
  + relax_primary_to_th_eq: .false.
  + log_Lnuc_div_L_for_relax_primary_to_th_eq: 0.005
  + min_age_for_relax_primary_to_th_eq: 1d2
  + max_steps_for_relax_primary_to_th_eq: 1000
  + no_history_during_relax_primary_to_th_eq: .true.
  + reset_age_for_relax_primary_to_th_eq: .true.
  + tsync_for_relax_primary_to_th_eq: 1

# binary_controls
## added
  + history_interval: 5
  + terminal_interval: 1
  + write_header_frequency: 10
  + extra_binary_terminal_output_file: ''
  + report_rlo_solver_progress: .false.

## changed
  * limit_retention_by_mdot_edd: .true. => .false.
  * max_tries_to_achieve: 0 => 20



> On May 31, 2017, at 11:40 AM, Evan Bauer <eb...@ph...> wrote:
> 
> Hello MESA Users,
> 
> We are happy to announce a new MESA public release version: 9793. Release notes below.
> 
> Cheers,
> Evan (on behalf of Pablo, Rich, Josiah, Rob, Aaron, Frank, and Bill)
> 
> 
> 
> 
> MESA 9793 - Release Notes
> =====================
> 
> 
> Binary
> -------
> 
> Binary module terminal output has been significantly changed to provide more useful information at runtime.
> 
> 
> Element Diffusion
> -------------------
> 
> Option added to simplify the user interface for diffusion classes (diffusion_use_full_net = .true.). This assigns each isotope in the current net to its own diffusion class, circumventing the need to manually specify each isotope that serves as a class representative.
> 
> Default solver for the Burgers equations has been changed to properly account for electron degeneracy in white dwarfs. The old solver based on the work of Thoul et al. (1994) for the Sun is still available, but is no longer the default.
> 
> The new diffusion solver (diffusion_use_cgs_solver = .true.) now accounts for thermal diffusion terms in the Burgers equations. It includes options to turn off these terms smoothly as a function of electron degeneracy, since they are invalid and usually negligible for WD interiors. With these thermal diffusion terms included for non-degenerate material, this solver is appropriate for use on the main sequence as well as in WDs. Thus, in most circumstances, the user no longer needs to worry about switching between solvers for different types of diffusion problems.
> 
> The new diffusion solver also supports radiative levitation now, where before this required using the solver based on Thoul et al. (1994) (as revised by Haili Hu to include extra driving terms from radiative levitation). The user interface remains unchanged.
> Note that radiative levitation is limited to isotopes that are supported by OP data for calculating radiative accelerations, so one must be careful to avoid using a class structure involving isotopes that aren’t supported. In particular, radiative levitation with the new diffusion_use_full_net option will cause problems for any net including isotopes not supported by OP.
> 
> “diffusion_gamma_full_on/off” has been changed to 150-175 as default, meaning diffusion occurs for all material that has not crystallized.
> 
> An option that accounts for Ne22 sedimentation heating in old, cooling WDs is now available.
> 
> Minor bug fixed in calculating the ionization states for diffusion classes. This only affected diffusion, and only mattered when background material for diffusion was not hydrogen.
> 
> Fixed a bug that could cause timesteps to crash unnecessarily due to stale diff_iters value. (Thanks to Bill Wolf for bug report!)
> 
> 
> GYRE
> -------
> 
> GYRE has been upgraded to 5.0rc6. There are significant changes to GYRE’s input files in this updated version; users should consult example input files, and/or the online documentation, for details. https://bitbucket.org/rhdtownsend/gyre/wiki/Home <https://bitbucket.org/rhdtownsend/gyre/wiki/Home>
> 
> 
> pgstar
> -------
> 
> Pgstar plots now have the option to call a decorator function, set in a users run_star_extras file in a similar way to the other_* functions, this allows additional customization options for all pgplots. See $MESA_DIR/star/other/pgstar_decorator.f90 for an example.
> 
> Network plots now have the option to show a colorbar for the abundances.
> 
> 
> Rates
> ------
> 
> The default version of JINA reaclib provided with MESA has been updated to reaclib v2.2.  To restore the previous default, use
>        jina_reaclib_filename = ‘jina_reaclib_results_20130213default2'
> in your star_job inlist. When switching between different reaclib versions, users must either: run $MESA_DIR/empty_caches or set rates_cache_dir in their star_job inlist to a local folder. Otherwise mesa will not use any rates from the new reaclib version that have been cached from a previous version. Running  $MESA_DIR/clean will also clear the caches.
> 
> It is now much simpler for a user to specify a custom table providing a weak reaction rate. See the test suite case "custom_rates" for examples of providing user-specified reaction rate tables.
> 
> 
> Miscellaneous
> ---------------
> 
> Bug fix for redo_conv_for_dr_lt_mixing_length so that it now applies to central convection zones.
> 
> The default opacity files all use gs98 relative metal fractions. (Previously, this was a mix of gn93 and gs98).  As a reminder, these choices are controlled by the star_job options
> 
>        kappa_file_prefix
>        kappa_lowT_prefix
>        kappa_CO_prefix
> 
> The star_job options associated with the blend (in Z) between OPAL and HELM and the blend (in T) between ionized and neutral HELM have been refactored.  See the documentation for the controls:
> 
>        set_HELM_OPAL_Zs
>        Z_all_HELM
>        Z_all_OPAL
> 
>        set_HELM_ion_neutral_blends
>        max_logRho_neutral_HELM
>        logT_neutral_HELM
>        logT_ion_HELM
> 
> While "stella" is now part of the mesa release, it is not yet ready for general use.  Please wait for the next release to begin using it.
> 
> A file containing a summary of the changes to inlist defaults is attached. Some internal and experimental controls are not included.
> 
> <changes.txt>
> 

[mesa-users] New public release 9793

[Evan B. <eb...@ph...>]

Hello MESA Users,

We are happy to announce a new MESA public release version: 9793. Release notes below.

Cheers,
Evan (on behalf of Pablo, Rich, Josiah, Rob, Aaron, Frank, and Bill)




MESA 9793 - Release Notes
=====================


Binary
-------

Binary module terminal output has been significantly changed to provide more useful information at runtime.


Element Diffusion
-------------------

Option added to simplify the user interface for diffusion classes (diffusion_use_full_net = .true.). This assigns each isotope in the current net to its own diffusion class, circumventing the need to manually specify each isotope that serves as a class representative.

Default solver for the Burgers equations has been changed to properly account for electron degeneracy in white dwarfs. The old solver based on the work of Thoul et al. (1994) for the Sun is still available, but is no longer the default.

The new diffusion solver (diffusion_use_cgs_solver = .true.) now accounts for thermal diffusion terms in the Burgers equations. It includes options to turn off these terms smoothly as a function of electron degeneracy, since they are invalid and usually negligible for WD interiors. With these thermal diffusion terms included for non-degenerate material, this solver is appropriate for use on the main sequence as well as in WDs. Thus, in most circumstances, the user no longer needs to worry about switching between solvers for different types of diffusion problems.

The new diffusion solver also supports radiative levitation now, where before this required using the solver based on Thoul et al. (1994) (as revised by Haili Hu to include extra driving terms from radiative levitation). The user interface remains unchanged.
Note that radiative levitation is limited to isotopes that are supported by OP data for calculating radiative accelerations, so one must be careful to avoid using a class structure involving isotopes that aren’t supported. In particular, radiative levitation with the new diffusion_use_full_net option will cause problems for any net including isotopes not supported by OP.

“diffusion_gamma_full_on/off” has been changed to 150-175 as default, meaning diffusion occurs for all material that has not crystallized.

An option that accounts for Ne22 sedimentation heating in old, cooling WDs is now available.

Minor bug fixed in calculating the ionization states for diffusion classes. This only affected diffusion, and only mattered when background material for diffusion was not hydrogen.

Fixed a bug that could cause timesteps to crash unnecessarily due to stale diff_iters value. (Thanks to Bill Wolf for bug report!)


GYRE
-------

GYRE has been upgraded to 5.0rc6. There are significant changes to GYRE’s input files in this updated version; users should consult example input files, and/or the online documentation, for details. https://bitbucket.org/rhdtownsend/gyre/wiki/Home <https://bitbucket.org/rhdtownsend/gyre/wiki/Home>


pgstar
-------

Pgstar plots now have the option to call a decorator function, set in a users run_star_extras file in a similar way to the other_* functions, this allows additional customization options for all pgplots. See $MESA_DIR/star/other/pgstar_decorator.f90 for an example.

Network plots now have the option to show a colorbar for the abundances.


Rates
------

The default version of JINA reaclib provided with MESA has been updated to reaclib v2.2.  To restore the previous default, use
       jina_reaclib_filename = ‘jina_reaclib_results_20130213default2'
in your star_job inlist. When switching between different reaclib versions, users must either: run $MESA_DIR/empty_caches or set rates_cache_dir in their star_job inlist to a local folder. Otherwise mesa will not use any rates from the new reaclib version that have been cached from a previous version. Running  $MESA_DIR/clean will also clear the caches.

It is now much simpler for a user to specify a custom table providing a weak reaction rate. See the test suite case "custom_rates" for examples of providing user-specified reaction rate tables.


Miscellaneous
---------------

Bug fix for redo_conv_for_dr_lt_mixing_length so that it now applies to central convection zones.

The default opacity files all use gs98 relative metal fractions. (Previously, this was a mix of gn93 and gs98).  As a reminder, these choices are controlled by the star_job options

       kappa_file_prefix
       kappa_lowT_prefix
       kappa_CO_prefix

The star_job options associated with the blend (in Z) between OPAL and HELM and the blend (in T) between ionized and neutral HELM have been refactored.  See the documentation for the controls:

       set_HELM_OPAL_Zs
       Z_all_HELM
       Z_all_OPAL

       set_HELM_ion_neutral_blends
       max_logRho_neutral_HELM
       logT_neutral_HELM
       logT_ion_HELM

While "stella" is now part of the mesa release, it is not yet ready for general use.  Please wait for the next release to begin using it.

A file containing a summary of the changes to inlist defaults is attached. Some internal and experimental controls are not included.

Re: [mesa-users] Changes to the gravitational constant

[Aaron D. <aar...@gm...>]

Hi Nsamba,

Read through star/other/other_cgrav.f90.  That explains how to set things
up.  If you have problems with the implementation, mesa-users can help you
try to solve them.

Good luck!

Aaron

On Wed, May 31, 2017 at 1:16 PM, Nsamba Benard <nsa...@gm...>
wrote:

> Hello,
>
> We are trying to make some changes on the gravitational constant so that
> it varies with a parameter say radius.
>
> say.    Gnew = Go(1 + constant*radius)
>
> I am supposed to do this in the run_star_extras but not sure how to do it.
> Can someone help me how to incorporate this.
>
> Thank you.
>
> Cheers,
> Benard
> ------------------------------------------------------------
> ----------------------------------------------
> Benard Nsamba
> PhD student                                  Centro de Astrofisica
>                                                     Universidade do Porto
>                                                     Rua das Estrelas
> Tel: +351 920 404 108 <+351%20920%20404%20108>                   4150-762
> Porto, Portugal
> E-mail: ben...@as... <Ben...@as...>
> Skype: benardnsamba
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

Re: [mesa-users] Changes to the gravitational constant

[Robert F. <rjf...@as...>]

Hi

You need to set the s%cgrav(1:s%nz) array with the value of the
gravitational constant you want.

Have a look in the $MESA_DIR/star/other/other_cgrav.f90 file for how to
hook up an other_ routine for changing the cgrav value

Rob



On Wed, May 31, 2017 at 10:16 AM, Nsamba Benard <nsa...@gm...>
wrote:

> Hello,
>
> We are trying to make some changes on the gravitational constant so that
> it varies with a parameter say radius.
>
> say.    Gnew = Go(1 + constant*radius)
>
> I am supposed to do this in the run_star_extras but not sure how to do it.
> Can someone help me how to incorporate this.
>
> Thank you.
>
> Cheers,
> Benard
> ------------------------------------------------------------
> ----------------------------------------------
> Benard Nsamba
> PhD student                                  Centro de Astrofisica
>                                                     Universidade do Porto
>                                                     Rua das Estrelas
> Tel: +351 920 404 108 <+351%20920%20404%20108>                   4150-762
> Porto, Portugal
> E-mail: ben...@as... <Ben...@as...>
> Skype: benardnsamba
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] Changes to the gravitational constant

[Nsamba B. <nsa...@gm...>]

Hello,

We are trying to make some changes on the gravitational constant so that it
varies with a parameter say radius.

say.    Gnew = Go(1 + constant*radius)

I am supposed to do this in the run_star_extras but not sure how to do it.
Can someone help me how to incorporate this.

Thank you.

Cheers,
Benard
----------------------------------------------------------------------------------------------------------
Benard Nsamba
PhD student                                  Centro de Astrofisica
                                                    Universidade do Porto
                                                    Rua das Estrelas
Tel: +351 920 404 108                   4150-762 Porto, Portugal
E-mail: ben...@as... <Ben...@as...>
Skype: benardnsamba

[mesa-users] Scientia PhD Scholarships at UNSW-Sydney

[Dennis S. <den...@sy...>]

I would like to draw your attention to the following PhD scholarship 
scheme for projects in asteroseiseismology and artificial 
intelligence/machine learning.
Up to two scholarships are up for grabs to commence in 2018.

Project page:
http://www.2025.unsw.edu.au/apply/scientia-phd-scholarships/measuring-fundamental-properties-stars-and-planets-using-artificial
=> The deadline for submitting the initial self assessment report is 21 
July 2017. <=

The Scientia scholarships are for new PhD scholars of exceptional 
quality to work on research projects aligned with UNSW’s ten year 
strategy. These prestigious scholarships offer unique benefits, 
individualised support and guaranteed funding to reach your personal 
development goals.

Specifically, they include:

  * *$40,000 a year* stipend (living allowance) for four years (tax free).
  * *Tuition fees covered* for the full 4 year period
  * *Up to $10,000 per year* to build your career, support your
    international research collaborations, and cover relocation/visa costs

For general information about the Scientia scheme, please visit:
http://www.2025.unsw.edu.au/apply/
Guidelines:
http://www.2025.unsw.edu.au/apply/node/69/
List of FAQs:
http://www.2025.unsw.edu.au/apply/unsw-scientia-phd-scholarships-faqs

Best
Dennis Stello

Re: [mesa-users] how to turn off certain categories of nuclear burning

[Aaron D. <aar...@gm...>]

Marvelous! Thanks Rob.

Aaron


On Tue, May 30, 2017 at 6:05 PM Robert Farmer <rjf...@as...> wrote:

> Hi
>
> You need to set
>
> s%weak_rate_factor = 0
>
> to turn off the weak rates. when i do this and put up the pgstar power win
> all i see is the cno, tri_alfa and pp as expected
>
> Rob
>
> On Tue, May 30, 2017 at 2:46 PM, Aaron Dotter <aar...@gm...>
> wrote:
>
>> Hi Rob,
>>
>> Thanks!  I've tried something like this and it doesn't work.  I also
>> tried your code, just to be sure, and it doesn't work either.
>>
>> I *think* there is some disconnect between the reaction rates in g and
>> the rate factors -- or I just don't understand how the two go together.
>> The two arrays are of different length, for one thing: size(s%
>> rate_factors) is greater than g% num_reactions = s% num_reactions.  Not
>> sure what's going on there.  Weak reactions, maybe?
>>
>> I'm attaching as close to a MWE as I can make.  The attached tarball can
>> be unpacked into star/work.  The code is in extras_finish_step and just
>> below that.  The idea in this particular case is to turn off all but H- and
>> He-burning during the post-AGB.  It should take fewer than 20 steps before
>> the code to turn off burning is called.  Then, if you look at the terminal
>> output for LH, LHe, and LZ, you'll see that this is not what happens.  At
>> least that's what I see!
>>
>> Aaron
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tuesday, May 30, 2017, Robert Farmer <rjf...@as...> wrote:
>>
>>> Hi
>>>
>>>  s%rate_factors goes from 1 to g%num_reactions
>>>
>>> so you could do:
>>>
>>> call get_net_ptr(s%net_handle, g, ierr)
>>> s%rate_factors=0d0
>>>
>>>       do j=1,g %num_reactions
>>>          id = g% reaction_id(j)
>>>          icat = reaction_categories(id)
>>>          if(icat .eq. ipp .or. ........)then
>>>                 s%rate_factors(j)=1d0
>>>          end if
>>>      enddo
>>>
>>> Rob
>>>
>>>
>>>
>>> On Tue, May 30, 2017 at 1:01 PM, Aaron Dotter <aar...@gm...>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have a situation where I'd like to turn off all nuclear burning that
>>>> is neither H-burning nor He-burning in run_star_extras.  In MESA/chem
>>>> terminology, I'd like reactions in these categories
>>>>
>>>> ipp = 1
>>>> icno = 2
>>>> i3alf = 3
>>>>
>>>> to go on as usual but to zero all other burning categories.  I'm using
>>>> a very recent version (9793 to be exact).  I had a way of doing this back
>>>> in 7503 but that no longer works.
>>>>
>>>> I have an array s% category_factors(1:num_categories); there are
>>>> currently 24 categories in chem_def.  This array is filled with values of 1
>>>> (first three elements) or 0 (all others).
>>>>
>>>> 1. I need to associate each reaction in my net with its category.  The
>>>> following seems to work:
>>>>
>>>>       call get_net_ptr(s%net_handle, g, ierr)
>>>>       do j=1,g %num_reactions
>>>>          id = g% reaction_id(j)
>>>>          icat = reaction_categories(id)
>>>>       enddo
>>>>
>>>> 2. I need to associate each reaction in my net with its s%
>>>> rate_factor.  This has me stumped at the moment.
>>>>
>>>>
>>>> Any advice would be greatly appreciated!
>>>>
>>>>
>>>> Thanks,
>>>> Aaron
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> mesa-users mailing list
>>>> mes...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>>
>>>>
>>>
>

Re: [mesa-users] how to turn off certain categories of nuclear burning

[Robert F. <rjf...@as...>]

Hi

You need to set

s%weak_rate_factor = 0

to turn off the weak rates. when i do this and put up the pgstar power win
all i see is the cno, tri_alfa and pp as expected

Rob

On Tue, May 30, 2017 at 2:46 PM, Aaron Dotter <aar...@gm...>
wrote:

> Hi Rob,
>
> Thanks!  I've tried something like this and it doesn't work.  I also tried
> your code, just to be sure, and it doesn't work either.
>
> I *think* there is some disconnect between the reaction rates in g and
> the rate factors -- or I just don't understand how the two go together.
> The two arrays are of different length, for one thing: size(s%
> rate_factors) is greater than g% num_reactions = s% num_reactions.  Not
> sure what's going on there.  Weak reactions, maybe?
>
> I'm attaching as close to a MWE as I can make.  The attached tarball can
> be unpacked into star/work.  The code is in extras_finish_step and just
> below that.  The idea in this particular case is to turn off all but H- and
> He-burning during the post-AGB.  It should take fewer than 20 steps before
> the code to turn off burning is called.  Then, if you look at the terminal
> output for LH, LHe, and LZ, you'll see that this is not what happens.  At
> least that's what I see!
>
> Aaron
>
>
>
>
>
>
>
>
>
> On Tuesday, May 30, 2017, Robert Farmer <rjf...@as...> wrote:
>
>> Hi
>>
>>  s%rate_factors goes from 1 to g%num_reactions
>>
>> so you could do:
>>
>> call get_net_ptr(s%net_handle, g, ierr)
>> s%rate_factors=0d0
>>
>>       do j=1,g %num_reactions
>>          id = g% reaction_id(j)
>>          icat = reaction_categories(id)
>>          if(icat .eq. ipp .or. ........)then
>>                 s%rate_factors(j)=1d0
>>          end if
>>      enddo
>>
>> Rob
>>
>>
>>
>> On Tue, May 30, 2017 at 1:01 PM, Aaron Dotter <aar...@gm...>
>> wrote:
>>
>>> Hi,
>>>
>>> I have a situation where I'd like to turn off all nuclear burning that
>>> is neither H-burning nor He-burning in run_star_extras.  In MESA/chem
>>> terminology, I'd like reactions in these categories
>>>
>>> ipp = 1
>>> icno = 2
>>> i3alf = 3
>>>
>>> to go on as usual but to zero all other burning categories.  I'm using a
>>> very recent version (9793 to be exact).  I had a way of doing this back in
>>> 7503 but that no longer works.
>>>
>>> I have an array s% category_factors(1:num_categories); there are
>>> currently 24 categories in chem_def.  This array is filled with values of 1
>>> (first three elements) or 0 (all others).
>>>
>>> 1. I need to associate each reaction in my net with its category.  The
>>> following seems to work:
>>>
>>>       call get_net_ptr(s%net_handle, g, ierr)
>>>       do j=1,g %num_reactions
>>>          id = g% reaction_id(j)
>>>          icat = reaction_categories(id)
>>>       enddo
>>>
>>> 2. I need to associate each reaction in my net with its s% rate_factor.
>>> This has me stumped at the moment.
>>>
>>>
>>> Any advice would be greatly appreciated!
>>>
>>>
>>> Thanks,
>>> Aaron
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> mesa-users mailing list
>>> mes...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>>
>>>
>>

Re: [mesa-users] how to turn off certain categories of nuclear burning

[Aaron D. <aar...@gm...>]

Hi Rob,

Thanks!  I've tried something like this and it doesn't work.  I also tried
your code, just to be sure, and it doesn't work either.

I *think* there is some disconnect between the reaction rates in g and the
rate factors -- or I just don't understand how the two go together.  The
two arrays are of different length, for one thing: size(s% rate_factors) is
greater than g% num_reactions = s% num_reactions.  Not sure what's going on
there.  Weak reactions, maybe?

I'm attaching as close to a MWE as I can make.  The attached tarball can be
unpacked into star/work.  The code is in extras_finish_step and just below
that.  The idea in this particular case is to turn off all but H- and
He-burning during the post-AGB.  It should take fewer than 20 steps before
the code to turn off burning is called.  Then, if you look at the terminal
output for LH, LHe, and LZ, you'll see that this is not what happens.  At
least that's what I see!

Aaron









On Tuesday, May 30, 2017, Robert Farmer <rjf...@as...> wrote:

> Hi
>
>  s%rate_factors goes from 1 to g%num_reactions
>
> so you could do:
>
> call get_net_ptr(s%net_handle, g, ierr)
> s%rate_factors=0d0
>
>       do j=1,g %num_reactions
>          id = g% reaction_id(j)
>          icat = reaction_categories(id)
>          if(icat .eq. ipp .or. ........)then
>                 s%rate_factors(j)=1d0
>          end if
>      enddo
>
> Rob
>
>
>
> On Tue, May 30, 2017 at 1:01 PM, Aaron Dotter <aar...@gm...>
> wrote:
>
>> Hi,
>>
>> I have a situation where I'd like to turn off all nuclear burning that is
>> neither H-burning nor He-burning in run_star_extras.  In MESA/chem
>> terminology, I'd like reactions in these categories
>>
>> ipp = 1
>> icno = 2
>> i3alf = 3
>>
>> to go on as usual but to zero all other burning categories.  I'm using a
>> very recent version (9793 to be exact).  I had a way of doing this back in
>> 7503 but that no longer works.
>>
>> I have an array s% category_factors(1:num_categories); there are
>> currently 24 categories in chem_def.  This array is filled with values of 1
>> (first three elements) or 0 (all others).
>>
>> 1. I need to associate each reaction in my net with its category.  The
>> following seems to work:
>>
>>       call get_net_ptr(s%net_handle, g, ierr)
>>       do j=1,g %num_reactions
>>          id = g% reaction_id(j)
>>          icat = reaction_categories(id)
>>       enddo
>>
>> 2. I need to associate each reaction in my net with its s% rate_factor.
>> This has me stumped at the moment.
>>
>>
>> Any advice would be greatly appreciated!
>>
>>
>> Thanks,
>> Aaron
>>
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
>

Re: [mesa-users] how to turn off certain categories of nuclear burning

[Robert F. <rjf...@as...>]

Hi

 s%rate_factors goes from 1 to g%num_reactions

so you could do:

call get_net_ptr(s%net_handle, g, ierr)
s%rate_factors=0d0

      do j=1,g %num_reactions
         id = g% reaction_id(j)
         icat = reaction_categories(id)
         if(icat .eq. ipp .or. ........)then
                s%rate_factors(j)=1d0
         end if
     enddo

Rob



On Tue, May 30, 2017 at 1:01 PM, Aaron Dotter <aar...@gm...>
wrote:

> Hi,
>
> I have a situation where I'd like to turn off all nuclear burning that is
> neither H-burning nor He-burning in run_star_extras.  In MESA/chem
> terminology, I'd like reactions in these categories
>
> ipp = 1
> icno = 2
> i3alf = 3
>
> to go on as usual but to zero all other burning categories.  I'm using a
> very recent version (9793 to be exact).  I had a way of doing this back in
> 7503 but that no longer works.
>
> I have an array s% category_factors(1:num_categories); there are
> currently 24 categories in chem_def.  This array is filled with values of 1
> (first three elements) or 0 (all others).
>
> 1. I need to associate each reaction in my net with its category.  The
> following seems to work:
>
>       call get_net_ptr(s%net_handle, g, ierr)
>       do j=1,g %num_reactions
>          id = g% reaction_id(j)
>          icat = reaction_categories(id)
>       enddo
>
> 2. I need to associate each reaction in my net with its s% rate_factor.
> This has me stumped at the moment.
>
>
> Any advice would be greatly appreciated!
>
>
> Thanks,
> Aaron
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] how to turn off certain categories of nuclear burning

[Aaron D. <aar...@gm...>]

Hi,

I have a situation where I'd like to turn off all nuclear burning that is
neither H-burning nor He-burning in run_star_extras.  In MESA/chem
terminology, I'd like reactions in these categories

ipp = 1
icno = 2
i3alf = 3

to go on as usual but to zero all other burning categories.  I'm using a
very recent version (9793 to be exact).  I had a way of doing this back in
7503 but that no longer works.

I have an array s% category_factors(1:num_categories); there are currently
24 categories in chem_def.  This array is filled with values of 1 (first
three elements) or 0 (all others).

1. I need to associate each reaction in my net with its category.  The
following seems to work:

      call get_net_ptr(s%net_handle, g, ierr)
      do j=1,g %num_reactions
         id = g% reaction_id(j)
         icat = reaction_categories(id)
      enddo

2. I need to associate each reaction in my net with its s% rate_factor.
This has me stumped at the moment.


Any advice would be greatly appreciated!


Thanks,
Aaron

[mesa-users] Scientia PhD Scholarships at UNSW-Sydney

[Dennis S. <d.s...@un...>]

I would like to draw your attention to the following PhD scholarship 
scheme for projects in asteroseiseismology and artificial 
intelligence/machine learning.
Up to two scholarships are up for grabs to commence in 2018.

Project page:
http://www.2025.unsw.edu.au/apply/scientia-phd-scholarships/measuring-fundamental-properties-stars-and-planets-using-artificial
=> The deadline for submitting the initial self assessment report is 21 
July 2017. <=

The Scientia scholarships are for new PhD scholars of exceptional 
quality to work on research projects aligned with UNSW’s ten year 
strategy. These prestigious scholarships offer unique benefits, 
individualised support and guaranteed funding to reach your personal 
development goals.

Specifically, they include:

  * *$40,000 a year* stipend (living allowance) for four years (tax free).
  * *Tuition fees covered* for the full 4 year period
  * *Up to $10,000 per year* to build your career, support your
    international research collaborations, and cover relocation/visa costs

For general information about the Scientia scheme, please visit:
http://www.2025.unsw.edu.au/apply/
Guidelines:
http://www.2025.unsw.edu.au/apply/node/69/
List of FAQs:
http://www.2025.unsw.edu.au/apply/unsw-scientia-phd-scholarships-faqs

Best
Dennis Stello

[mesa-users] Janaka Adassuriya

[Janaka A. <ada...@gm...>]

-- 
Janaka Adassuriya
Astronomy & Space Science Division
Arthur C Clarke Institute
Katubedda, Moratuwa
Sri Lanka
Tel: +94 11 2651566
Fax: +94 11 2650462
Email: ada...@ac...
          ada...@gm...

Re: [mesa-users] sdB

[Jan-Torge S. <jts...@em...>]

Dear Rahou,

I have simulated sdB stars with an older version of MESA.

I am not aware that MESA currently has capabilities to simulate the 
complicated two star evolution that produces sdB stars.
However my approach was 'mimicking' it by

1.) Start a single star evolution with the initial mass of your sdB 
progenitor star.
2.) Run the evolution and then write out a model at the point in time 
where you would like the mass transfer to happen. (Somewhat close to but 
before the He-flash.
3.) Start the saved model but specify a M_new and let MESA take mass off 
from the outside of the star. But beware, you must be careful not too 
take off too much mass. Physically, the mass transfer will quench the 
H-shell burning and then the mass transfer will stop as well. So never 
let MESA take off mass below the H-shell burning zone.

Unfortunately, I am currently travelling and I don't have much time to 
elaborate. I did find the old inlists I used with version 7184. Be aware 
much has changed since then, but they should give you a head start.

One more advice, turn off wind for the sdB evolution. This let's you 
control the total mass better in the beginning and you can turn them on 
later for a more 'realistic' simulation ( not sure how realistic the 
wind parameters are constraint for sdBs).

At last have a look at our paper from 2015, where I describe how we 
modelled sdB stars.

Cheers,
Jan-Torge

On 05/21/2017 08:56 PM, kaoutar lahlou wrote:
> Hi mesa users:
>
> I am traying to figure out the EHB or sdB. I read in an article that 
> we need to make simulation between two stars: M _ initial and M _new.
>
> On mesa -binary, what i should make for initial condition ie for M1 
> and M2.
>
> Who will be the donor and accretor ?
>
> Thanks
>
> Rahou
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] sdB

[kaoutar l. <kao...@gm...>]

Hi mesa users:

I am traying to figure out the EHB or sdB. I read in an article that we
need to make simulation between two stars: M _ initial and M _new.

On mesa -binary, what i should make for initial condition ie for M1 and M2.

Who will be the donor and accretor ?

Thanks

Rahou