[mesa-users] mesa release version 5456

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

Hi,

Lots of changes in this release.  It will take some work on your part
to move to it, but it will be worth the effort!  ;p

Cheers,
Bill

-------------------------------------------------------------------------


This is the first major release after the mesa summer school, and you might recall
that last year there were lots of changes to names after the school.  Same thing
has happened again.  In particular, I've finally fixed my counter-intuitive
naming of the mass locations where there are changes in dominant
abundances.   Unlike everyone else, I was naming these according
to what was more abundant above the transition instead of below.  
Now that's reversed, so what was called "h1_boundary_mass" is now
called "he_core_mass", what was "he4_boundary_mass" is now
"c_core_mass", etc.   The criterion for the locations is simply what 
has the maximum mass fraction -- e.g., he_core_mass is the outermost
location where the mass fraction of he4 is larger than for anything else,
the c_core_mass is outermost where mass fraction of c12 is larger than
any other, etc.


There is a new star/test_suite called "make_planets" thanks to Phil Arras.
Check it out if you are in the business of making planets!
It replaces the old create_planets and create_inert_core_planets test cases.


OP opacities using A09 metals mix are now available.  Radek Smolec 
supplied the data files, and I turned the kap/preprocessor crank to make 
the mesa versions. The old kappa_file_prefix = 'OP' is now renamed 'OP_gs98'.
To use the new A09 version of OP, set kappa_file_prefix = 'OP_a09'.


As you might recall, thanks to Haili Hu, we support OP mono opacities.
These use the actual composition to calculate opacities rather than assuming
a particular mix of metals.  These opacities are used in the implementation
of radiative levitation.  The data files are large (656 MB), so I haven't
included them in the standard mesa download.  To make it easier to get
them, they are now available on the mesa sourceforge site
at http://sourceforge.net/projects/mesa/files


In response to questions from Tug Sukhbold, I've made changes to the
options for the c12 + c12 reaction.  Previously the choices were "CF88"
and "G05" corresponding to Caughlan & Fowler, 1988 and Gasques 2005.
In the new release we distinguish between two CF88 options in addition to G05:
'CF88_basic_1212' and 'CF88_multi_1212'.
      	CF88_basic_1212 is the single rate approximation from CF88.
      	CF88_multi_1212 combines the three rates for the n, p, and a channels,
         	c12(c12,n)mg23, c12(c12,p)na23, and c12(c12,a)ne20,
         	and uses neutron branching from dayras, switkowski, and woosley, 1976.
In previous releases of mesa, the default was the basic form.
The new default is to use the more complete multichannel form.  
You can of course still select which option for c12+c12 you want to use
by setting the control "set_rate_1212" to one of the three choices.


mesa/star/binary has morphed into mesa/binary.  

	it has the usual mesa module structure of public, private, make, and test directories.
	like mesa/star it also has defaults, job, test_suite, and work directories.
	Pablo Marchant continues to drive the development work on binaries.
	Just for one example, L-S coupling has been added in this release.
	Stay tuned for more news on this topic -- binaries are big. ;p


revisions to calculation of eps_grav when there is mass gain or loss

	In prior mesa releases, the mass loss case was almost right, but I had
	a bug that caused it to under-estimate the effect.  For mass gain
	we had an accurate but limited approach based on the thin radiative
	shell formula from Townsley & Bildsten, ApJ, 2004.  That scheme
	has now been replaced by the following general solution.


	eps_grav depends on Lagrangian time derivatives (i.e., at same mass coord).
	in mesa/star, such time derivatives are estimated by 1st order differences:
		(value_final - value_initial)/(time_final - time_initial)
	where the values are at the same mass location in the model.
	in most cases the value_initial is the value at the start of the step,
	value_final is at the end of the step, and time_final - time_initial
	is the timestep, dt.   For each cell, k, we have value(k) at the end
	of the step, and we have the mass m(k) for that cell.  

	[We have the final value when calculating the time derivative
	that is itself required to calculate the final value -- how can that be?  
	It is because we are solving implicit equations where we guess
	a final value, check to see if it is self consistent, and
	iteratively revise the guesses to make them better.  This
	process is essentially a high dimensional newton root find,
	hence the references to "newton iterations" in the folllowing.]
	
	We need to find the value_initial at m(k) at the initial time.  
	The "adjust_mass" routine which implements mass gain or loss 
	sets a variable, k_const_mass, such that for all k >= k_const_mass,
	the cell k is at the same mass coordinate as it was at the initial_time.
	So for those cells, the difference at constant mass is just a difference
	at the same k.  (recall that k=1 is at the surface in mesa).
	If there is no change in mass, k_const_mass will be 1,
	in other words, all of the cells will be at the same mass coordinate.
	For mass loss or gain, cells with k < k_const_mass will have
	changed mass coordinates.  If m(k) is <= the mass of the star at
	the start of the step, then we will interpolate by m in the starting
	model to get the value_initial.  

	In the case of mass gain, we will have cells at the surface of 
	the final model containing mass that was not part of the model
	at the start of the step, so we need a different method
	for those cases.  But it turns out to be easy.  We know
	time_initial when the mass entered the model since we know
	how much mass is finally above the cell and we know the rate at which
	the mass is added.  Once we have time_initial, we can use that
	to get value_initial by interpolating between the surface values
	at the start of the timestep and at the end.  We begin the newton
	iterations by setting the guess for the ending surface value to the
	starting value.  After the newton iterations 1st converge using that
	guess, we check to see if the guess was good enough
	by comparing it to the actual final surface value.  If the
	change at the surface has been small enough, we accept 
	the new solution.  Otherwise, we change the guessed final value for
	use in interpolation and continue the newton iterations.
	In all cases I've checked, a single extra iteration is sufficient.

	In practice, we use the natural log of the entropy at the surface,
	to check if the guess was okay.  The control parameter 
		max_abs_rel_change_surf_lnS
	tells how big the change can be without forcing more newton
	iterations.  The control parameter
		 max_num_surf_revisions
	specifies max number of forced reconverges for changes in surf_lnS.
	The default settings in controls.defaults are 5d-4 and 1, respectively.
	In cases of high mdot*dt, you will sometimes see a terminal message,
	starting with "abs rel diff of predicted vs actual final lnS",
	telling you that the code has forced another newton iteration.
	
	Does it make a difference?  You'll have to judge.  It is a more accurate
	accounting of energy, and that will show up as increased "compressional"
	heating at the surface during mass gain and as decreased luminosity
	during mass loss as energy is extracted to increase the entropy of the
	cells nearing the surface.  Depending on your application, the effects
	might be insignificant or critical.  Let us know if you have a case
	where this makes a big difference.

	And, naturally, the usual warnings apply as for any new method.
	It has been tested, but there can still be surprises hidden in the complexity.


Finally, there are major revisions to the PGSTAR plotting options.   You'll
probably need to throw out your current &pgstar controls and start fresh. 
To help with this process, I've written a "pgstar.README" that is in star/defaults
along with the much changed "pgstar.defaults".   It includes a hands-on
tutorial to walk you through the new options -- I strongly recommend it.

As a preview of the new PGSTAR, I've made a couple of movies 
and placed them on the website: http://mesa.sourceforge.net/#what

	http://mesa.sourceforge.net/pdfs/1M_pre_ms_to_wd.mov


	http://mesa.sourceforge.net/pdfs/16M_z2m2_wwc70.mov
















----------