[mesa-users] New public release 9575

[Evan Bauer]

Hi Everyone,

I noticed one minor change that didn’t quite make its way into the release notes, but is probably worth warning everyone about.

The default profile_columns.list has been modified to save only a bare minimum of essential information. All the same information is still available if you want to access it, but almost none of the columns are turned on by default anymore. If you take a look in star/defaults/profile_columns.list, you’ll see

! minimal set of enabled columns:

   zone       ! numbers start with 1 at the surface
   mass       ! m/Msun. mass coordinate of outer boundary of cell.
   logR       ! log10(radius/Rsun) at outer boundary of zone
   logT       ! log10(temperature) at center of zone
   logRho     ! log10(density) at center of zone
   logP       ! log10(pressure) at center of zone
   x_mass_fraction_H
   y_mass_fraction_He
   z_mass_fraction_metals

This has the advantage of greatly reducing disk space taken up by profile.data files, but it means that you’ll have to be more careful to consciously add quantities you want to track to your profile_columns.list. It may be a good idea to keep a copy of your own custom profile_columns.list that tracks columns you care about in your typical usage. For example, I care a lot about abundances for my work with diffusion, so I keep a copy of profile_columns.list that (among other things) uncomments

	add_abundances ! this adds all of the isos that are in the current net

As long as I remember to include this custom profile_columns.list file in my working directories, I get abundance info for every isotope in my network in every profile.data file. But unlike previous MESA release versions, I won’t get this info by default.

Cheers,
Evan

> On Feb 17, 2017, at 10:38 AM, RICHARD H D TOWNSEND <townsend at astro.wisc.edu> wrote:
> 
> Dear MESA Community,
> 
> It is our great pleasure to announce MESA public release version 9575.
> There are a number of changes we'd like to bring to your attention;
> please see the release notes below.
> 
> Best wishes,
> 
> Rich (on behalf of Rob, Josiah, Evan, Aaron, Frank and Bill)
> 
> MESA 9575 - Release Notes
> =========================
> 
> Opacities
> ---------
> 
> The kap module has been modified to make it easier to incorporate
> alternative opacity tables, while preserving the normal behavior of
> the default tables. The modifications come in 2 basic forms:
> 
> 1) the naming convention for opacity table files has been streamlined
> so that all X and Z values are now consistently written across all
> different types of tables.
> 
> 2) the input X and Z values required by the kap module are no longer
> hard-coded in kap_def; they are now read from a configuration file
> that is (optionally) read at run time. The number of X and Z values
> are set in the file, along with the numbers Xs for each Z, and the
> actual X and Z values. This is accomplished through the star_job
> inlist through 'kappa_config_file'.
> 
> These changes should be completely transparent to users of the
> standard kap tables. No changes have been made to the OP monochromatic
> opacities either.
> 
> For users who update their mesa install through svn, kap_data will
> need to be reinstalled after the update.
> 
> Pulsation
> ---------
> 
> *) Fixed code that adds atmosphere data to pulsation output files (as
> enabled by add_atmosphere_to_pulse_data). Previously, this code only
> worked correctly for the four atmosphere choices that perform a T-Tau
> integration: ‘Eddington_grey’, ‘Krishna_Swamy’, ‘solar_Hopf_grey’ and
> ‘Pacznski_grey’. In other cases, the code silently added on a
> ‘Paczynski_grey’ atmosphere instead of what was requested; typically,
> this led to density/temperature discontinuities at the transition
> between atmosphere and interior. In the fixed code, along with the
> four T-tau cases, the ‘simple_photosphere’ and ‘grey_and_kap’ options
> now function as they should; while the remaining options (e.g.,
> ‘photosphere_tables’) cause MESA to terminate with a message
> indicating that an atmosphere cannot be added.
> 
> *) Fixed the headers written to FGONG- and OSC-format pulsation output
> files; previously, some of the fields (e.g., stellar age) were being
> incorrectly set up.
> 
> *) MESA can now write pulsation output files that include
> composition/density discontinuities (in fact, this capability was
> present in release 8845, but undocumented). When a density
> discontinuity is detected in a model (see below for more details on
> how this is done), and the control flag
> ‘add_double_point_to_pulse_data’ is .TRUE. MESA writes a double point
> to the output file, containing the model values on either side of the
> discontinuity. Double points can easily be recognized in the file
> because they share the same radial (r) and mass (M_r) coordinate
> values. Recent releases of the GYRE pulsation code (5.0 onward)
> correctly treat double points by applying appropriate jump conditions
> in the pulsation equations.
> 
> To control what MESA considers to be a density discontinuity, use the
> ‘threshold_grad_mu_for_double_point’ control. Cell faces where
> |grad_mu| = |d(ln mu)/d(ln P)| rises above this threshold are treated
> as density discontinuities. A typical threshold value might be
> somewhere in the range 1-10. To avoid having *too* many double points
> created, you can set an upper limit on the number using the
> ‘max_number_of_double_points’ control.
> 
> *) MESA by default now uses the ‘wide’ (version >= 1000) format when
> writing FGONG pulsation output files. This format was formalized
> during the 2015 Aarhus RGB Workshop in Birmingham, England.
> 
> *) Some of the pulsation output parameters have been renamed, as
> follows:
> 
>   save_pulsation_info_for_model_number -> save_pulse_data_for_model_number
>   save_pulsation_info_when_terminate -> save_pulse_data_when_terminate
>   save_pulsation_info_filename -> save_pulse_data_filename
>   write_pulse_info_with_profile -> write_pulse_data_with_profile
>   pulse_info_format -> pulse_data_format
>   add_atmosphere_to_pulse_info -> add_atmosphere_to_pulse_data
>   add_center_point_to_pulse_info -> add_center_point_to_pulse_data
>   keep_surface_point_for_pulse_info -> keep_surface_point_for_pulse_data
>   add_double_points_to_pulse_info -> add_double_points_to_pulse_data
> 
> *) Fixed incorrect filename when using write_gyre_for_best_model
> 
> Accretion
> ---------
> 
> Accretion with small timesteps has been improved, using a patch and
> test case provided by Dean Townsley. Here is his commentary:
> 
> "The attached adjust_mass.f90 has some fixes for accretion with small
> timesteps when the mass added in the step is similar to the mass of
> the outer zone.  In the current code (I tested 8845), if the material
> being added is not the same abundance as the surface already there,
> the individual species accretion rates are wrong and the profiles get
> messed up as well.  See the attached plots of h1 mass and the h1
> profile after about 50 steps into adding mass. The test here is just
> taking the current "wd" accretion test, setting the initial timestep
> so that the initial added mass in a timestep is about half that in the
> outer zone, and changing to helium-rich accreted material, though any
> abundance different from what is already there will do.  Updates to
> adjust_mass.f90 seem to fix things.
> 
> The main issues were:
> 
> - dm(k) was being used after revise_q_and_dq() was called but was not
>  actually updated.  it is now updated with the dq's.
> 
> - the renorming of the dq's after the constant dm / constant dq
>  boundary determination was done in a way that suffered from
>  truncation problems when the the constant dq region is small. This
>  caused the mass added in various species to be off (too small).  As
>  you can see in the plots, the H mass could actually decrease even
>  when accreting material with H in it!
> 
> - there was some code in there that seemed to be trying to fix this by
>  rescaling abundances to match expectations in layers near the
>  surface, but due to the need to keep abundances to sum to 1 and the
>  fact that all the accreted masses were off in the same direction,
>  this distorted the abundance profile instead of fixing the
>  problem. (see the second set of plots) I have disabled this code now
>  that the underlying problem appears to be fixed.
> 
> - there was a minor error in the way the abundance was computed for
>  partially accreted cells.  This doesn't seem to have been having a
>  major impact.
> 
> In fixing the second of these issues related to truncation, I
> refactored the revise_q_and_dq() to work in 1-q instead of q
> coordinates to reduce truncation issues.  The logic is otherwise the
> same, just with 1-q as the coordinate.
> 
> I have also included a new test suite test to check for these issues.
> This test reports failure for the current release (8845) but success
> with the adjust_mass.f90 changes attached here.  While this test could
> be done at the start of the "wd" test, starting from small timesteps
> takes around 1200 steps which is a fair bit more than the current "wd"
> test, which takes around 400.  Also it's a bit more clear to just test
> it separately."
> 
> Miscellaneous
> -------------
> 
> *) Added new pgstar plot production_plots which show the relative
> change in the abundances against the initial composition.
> 
> *) pgstar plots can now be used while mesa is using one of the relax
> routines to "relax" the model to a new state.
> 
> *) makefiles will now warn the user if $MESA_DIR variable is not set,
> or if using the SDK makefile (the default) if the SDK has not been
> initialized.
> 
> *) Cache files will now be written to the current working directory
> before being moved to the $MESA_DIR/data folder. This will stop
> multiple mesa runs, running simultaneously, from over writing the
> cache files leaving them in a inconsistent state. This should help
> those running MESA on clusters or otherwise running more than 1 mesa
> job at a time.
> 
> *) A new file $MESA_DIR/star/defaults/env_vars.list has been added
> which describes the environment variables MESA uses as well as few
> miscellaneous options.
> 
> *) fixed a bug in the color code that prevents the use of more than
> one bolometric correction file. In previous versions of MESA, when
> using bc’s from a second or subsequent file, the wrong column is
> returned.
> 
> *) Add test_suite case (custom_rate_c14ago18) exercising custom
> rate. This test case provides an example of how to set up and use one
> of your own reaction rates in MESA.  Physically, it is a WD slowly
> accreting He (with some N14, which has electron-captured to C14 at
> the base of the He layer).  It illustrates the effect of the
> c14(a,g)o18 rate on the ignition of the He.  The custom rate is that
> from Hashimoto et al. (1986) and is compared to the default "reaclib"
> rate that ships with MESA.
> 
> *) MESA now strictly respects max_timestep control. Previously, if you
> loaded a model that has a stored timestep greater than the requested
> max_timestep, the timestep would remain above the limit for several
> steps (since it could only shrink so much per step).
> 
> *) Fixed check_for_redo_MLT by using mlt_mixing_type, so that it now
> functions as documented.
> 
> *) Tweak convective zone boundary mesh controls, changing the effect
> of the convective zone boundary mesh controls xtra_coef_*_*_*_czb
> (hereafter "coef") and xtra_dist_*_*_*_czb (hereafter,
> "dist"). Previously, the meshing was adjusted by setting the value of
> delta_gval_max to be a linear blend between coef at the boundary and
> 1.0 over a length dist * Hp (measured from the boundary).
> 
> If you try to increase the resolution near the convective boundary by
> a significant factor, the linear blend means that delta_gval_max is
> only near the specified value of coef for a distance away from the
> boundary of order coef * dist.  So in practice, MESA increases the
> resolution over a significantly smaller region than you might expect.
> 
> To fix this, the form of the blend is now a piecewise linear form
> that guarantees that delta_gval_max is near coef for at least half of
> dist.
> 
> ------------------------------------------------------------------------------
> 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
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users