[mesa-users] new public release 8118

[Francis Timmes]

dear mesa community,

we are happy to announce public release version 8118.
get it from http://mesa.sourceforge.net/prereqs.html .

below we call your attention to seven high-level release items.

i am sending this release message instead of bill because 
we are offloading tasks from bill.

frank, josiah, rob, pablo, aaron, max, willie, rich, and, of course, bill



==========

item #1:

The old "RGB_wind_scheme" and "AGB_wind_scheme" have been replaced with
temperature-dependent hot_wind and cool_wind.  You can still use the RGB
and AGB wind scheme as before, the functionality remains.

Now you can also select a hot wind scheme that takes effect *above* some
temperature, set by hot_wind_full_on_T and hot_wind_full_off_T.
Similarly, the cool wind scheme has temperature controls that set the
temperature *below* which they are relevant (cool_wind_full_off_T and
cool_wind_full_on_T). The two temperature regimes can overlap; in this
case the hot and cool Mdot values are added.  The wind Mdot will ramp
from 0 to full value between full_on_T and full_off_T.

As before, an empty string '' means no wind.

The wind "eta" values, which are constant scaling factors, have all
renamed *wind_eta -> *_scaling_factor.

Here is an example of how to translate an existing inlist from the old
style to the new:

Before:

   RGB_wind_scheme = 'Reimers'
   Reimers_wind_eta = 0.1
   AGB_wind_scheme = 'Blocker'
   Blocker_wind_eta = 0.5
   RGB_to_AGB_wind_switch = 1d-4

After:

   cool_wind_RGB_scheme = 'Reimers'
   Reimers_scaling_factor = 0.1
   cool_wind_AGB_scheme = 'Blocker'
   Blocker_scaling_factor = 0.5
   RGB_to_AGB_wind_switch = 1d-4

   !  only use the cool_wind_scheme
   cool_wind_full_on_T = 1d8    !K
   cool_wind_full_off_T = 1.1d8 !K
   hot_wind_scheme = ''


The old "Dutch" conglomerate still spans the whole HR-Diagram, 
but bows to the new full on/off rules.


Thanks to Aaron!


==========

item #2:

For users of Type2 opacity tables, there has been a small change on
how opacities are computed when blending Type1 and Type2 tables, in
order to avoid a spurious increase in opacity when switching from one
to the other. This issue was described in an earlier email to
mesa-users, but we mention it again here to avoid potential
confusion. Users of Type1 opacities will not be affected by this
change.

Before describing the issue, first a small reminder on how MESA works
when the option to use Type2 opacities is on. To use Type2 opacities
one needs to specify a base metallicity, Zbase, which gives the metal
abundances previous to any CO enhancement. In regions where central
hydrogen is above a given threshold (x>0.71 by default), or the
metallicity does not differ significantly from Zbase (Z-Zbase<0.001 by default), 
Type1 tables are used instead, with blending regions to smoothly
transition from one to the other. In particular, in terms of Z-Zbase,
the blending from Type1 to Type2 is done by default between 0.001 and 0.01. 
Why not just use Type2 all the time? Is it a performance reason
to still support Type1s?

No -- the Type1 tables cover a wider range of X and have a higher resolution in Z for each X.

The Type1 tables are for (X,Z) pairs from the following sets:

The 10 Type1 X's are 0.0, 0.1, 0.2, 0.35, 0.5, 0.7, 0.8, 0.9, 0.95, 1-Z 
The 13 Type1 Z's are 0.0, 1e-4, 3e-4, 1e-3, 2e-3, 4e-3, 1e-2, 2e-2, 3e-2, 4e-2, 6e-2, 8e-1, 1e-1

The Type2 tables are for (X,Z) pairs from the following more limits sets:
The 5 Type2 X's are 0.0, 0.03, 0.10, 0.35, 0.70
The 8 Type2 Z's are 0.00, 0.001, 0.004, 0.01, 0.02, 0.03, 0.05, 0.1

There are 126 (X,Z) combinations for Type1 (not 10x13=130 since 1-Z is
<= 0.9,0.95 for the highest Z) and only 40 for Type2. So Type2 gives
you C/O enhancement at a cost of lower resolution in (X,Z). The Type1
tables also cover the full possible range of X from 0.0 to 1-Z,
whereas the Type2 tables stop at a max X of 0.70. Extrapolating the
Type2 tables to higher X is not reliable, so we switch over to using
Type1 data instead. This presents the problem of how to treat cases
with enhanced Z, i.e., Z > Zbase when computing Type1 tables. In older
versions of MESA we simply used the metal abundance Z as input for
Type1 opacity calculations.  However, a change in Z from Zbase of 0.01
(which is the default point at which the computation of opacites
switches to just using Type2) is an important difference when using
Type1 tables, as this will be interpreted as a large increase in iron,
and thus, of opacity. This results in opacities spuriously increasing
when going from full Type1 to Type2+Type1, and a decrease when going
from Type2+Type1 to full Type2. Because of this, we have modified the
computation of opacities such that when use_Type2_opacities = .true.,,
the computation of Type1 opacities is done using Zbase instead of Z,
otherwise one gets this unphysical increase in opacity. With this
change the default blending regions remain the same, but Type1
opacities give reasonable values during the transition.

In summary, the main change (the one that affects users of Type2) is
to use Zbase instead of Z for Type1 opacities when using Type2+Type1. 
A consequence of this is that Type1 opacities computed in a given
region will differ depending on whether or not the option to use Type2
opacities is on. For users wishing to revert to the old way of computing 
opacities, they can set the option use_Zbase_for_Type1_blend = .false. in controls.

Thanks to Pablo!


==========

item #3:

Starting from this version, all extras routines in run_star_extras are
implemented as hooks (except for extras_controls), in a similar way to
all other_* routines. If you only use the standard run_star_extras
files then this change will not affect your older models. if you use a
custom run_star_extras, you need to slightly modify it for it to be
compatible with this and future versions. To do this, just assign the
necessary pointers in the extras_controls subroutine, as follows:

subroutine extras_controls(id, ierr)
integer, intent(in) :: id
integer, intent(out) :: ierr
type (star_info), pointer :: s
ierr = 0
call star_ptr(id, s, ierr)
if (ierr /= 0) return

! this is the place to set any procedure pointers you want to change
! e.g., other_wind, other_mixing, other_energy (see star_data.inc)
! Uncomment these lines if you wish to use the functions in this file,
! otherwise we use a null_ version which does nothing.

s% extras_startup => extras_startup
s% extras_check_model => extras_check_model
s% extras_finish_step => extras_finish_step
s% extras_after_evolve => extras_after_evolve
s% how_many_extra_history_columns => how_many_extra_history_columns
s% data_for_extra_history_columns => data_for_extra_history_columns
s% how_many_extra_profile_columns => how_many_extra_profile_columns
s% data_for_extra_profile_columns => data_for_extra_profile_columns

! Once you have set the function pointers you want,
! then uncomment this (or set it in your star_job inlist)
! to disable the printed warning message,

s% job% warn_run_star_extras =.false.
end subroutine extras_controls

Note this also applies to run_binary_extras for binary models
which have now gained similar abilities to the run_star_extras file,
with the following new functions and when they are called:

extras_binary_startup => Called before the run starts.
extras_binary_check_model => During the binary model check phase.
extras_binary_finish_step => After both the binary and single stars have accepted the timestep.
extras_binary_after_evolve => Once the binary run is complete.

To avoid older models being rerun with missing functionality
implemented in run_star_extras, MESA will issue a warning if any of
these pointers is not assigned, terminate the run, and provide 
simple instructions on how to fix it.

The rational for this change was to 

a) create the corresponding versions of the
   extras_binary_{startup,check_model,finish_step,after_evolve} routines
   for the binary module, which previously only had the extra_history_columns.

b) we are now in the position that if we wish to add new hooks to the 
   run_star_extras file in the future we can do so without breaking peoples files again.

Thanks to Rob!


==========

item #4:

MESA's color module has now be extended to improve usability. In your
star_job control you may now specify your own files containing
bolometric corrections that MESA will read in and provide interpolated
results for your stellar model. MESA still ships with a file based on
Lejeune, Cuisinier, Buser (1998) which provides UBVRIJHK
corrections. By modifying your history_columns you can output either
the raw bolometric correction(s) or the absolute magnitude(s). PGSTAR
plots have also been added to plot magnitude-magnitude,
color-magnitude and color-color plots. See star/defaults/star_job.defaults 
for the file format needed for the correction tables.

Thanks to Rob!



==========

item #5:

A new pgstar plot "network" has been added! It shows the 
total abundances of isotopes as a function of N vs Z and 
is a useful way to visualize the distribution of isotopes 
in your nuclear network. See star/defaults/pgstar.defaults 
for the parameters of the plot.

Thanks to Rob!



==========

item #6:

Enormous thanks to Rich for finding a nasty bug and then coming up with a
major advance for us in debugging tools. We now can run the star
tests with NaN traps enabled combined with pre-setting all dynamically
allocated memory to hold NaNs. This is very effective at showing up
accesses to uninitialized data that the compiler can't catch. An
interesting technical detail was that with NaN traps enabled, you
cannot initialize the array contents to NaNs without causing a trap!
Catch 22. The solution is to call a tiny C routine that fills the
arrays with the bit pattern for NaN without telling the hardware that
we are doing anything with double precision. sneaky, but it works.

The default behavior of mesa/star is to disable NaN traps. 
Thus, most users need not be concerned. However, if you wish, you can 
become an assistant debugger! In your makefile, find the corresponding 
lines and edit to turn on NaN traps:

SKIP_NAN_TRAPS = NO
include $(MESA_DIR)/star/work_standard_makefile
STAR = star

If you have multiple such makefiles, you can alternatively edit 
star/work_standard_makefile itself to set SKIP_NAN_TRAPS = NO.



==========

item #7:

Several errors in the on-the-fly weak rate implementation have been
corrected. If you have been making use of these capabilities in r7624,
please contact Josiah Schwab <jwschwab at berkeley.edu> for more details.

==========
end of release notes