[mesa-users] new mesa release 3607

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

Hi,

3607 is now available.

this release includes changes to several large data files, so be prepared for a long slow download.
if sourceforge is being nasty, you may even need to restart the update a few times to get it to finish.

here's a quick overview of the many changes since the last release (that was long. long ago back in June)


improved ability to use multiple cores in star
	star previously couldn't make effective use of more than 3 or 4 cores; now it can use at least 12 rather well.
	for example, on a "typical" task, using 12 cores, I'm finding that new star is 2.5 times faster than the previous release. 
	times are with ifort on my 12 core mac -- I set OMP_NUM_THREADS to test with fewer cores.
		of course I make no promises for other tasks or other machines or other compilers
		to generate timing information yourself, set first_model_for_timing = 1 in the &star_job inlist section
		and in &controls, set max_model_number = number of steps for timing (10 or 20 or whatever).
	the improvements are mainly from changes to the way star solves linear algebra (see below)
	to compare the old and new ways, set newton_decsol in &controls
		to 'lapack' for the old scheme or to 'block_dc_mt_klu' for the new one.
		if you are running with basic.net, you might also try 'block_dc_mt_lapack'
			
    elapsed time: comparisons to release 3372 (seconds to complete same task)
    cores         1        2        4        6        8        10       12
    old (3372)  43.1079  29.3830  23.3465  21.4314  20.7657  20.4095  20.4462
    new         39.2345  24.9185  15.8657  11.8018   9.8319   8.7670   8.1221
    old/new      1.10     1.18     1.47     1.82     2.11     2.33     2.52

mtx
	multicore version of "divide and conquer" parallel algorithm (based on implementation by Gustavo Hime)
      	reference
         	V. Mehrmann. Divide and conquer methods for block tridiagonal systems.
         	Parallel Computing. 19(3):257-279, 1993. 
	block tridiagonal thomas solver as an alternative to banded. 
	KLU sparse solver -- now a standard part of mesa (replacing SuperLU option)
		Timothy A. Davis and Ekanathan Palamadai Natarajan. 
		Algorithm 907: KLU, a direct sparse solver for circuit simulation problems. 
		ACM Trans. Math. Softw., 37:36:1–36:17, September 2010.

newton
	support block tridiagonal so that star can use the new matrix options
	mesa/star control is newton_decsol with the following options
		'lapack'	banded matrix solve. this was the default previously.
		'block_dc_mt_klu' use divide-and-conquer block tridiagonal with KLU for blocks. this is the new default.
		'block_dc_mt_lapack' use dense LAPACK in place of KLU.  might be good for basic.net

kap
	new electron conduction data from Sasha Potekhin -- larger range of coverage, higher resolution
	we have split the mesa opacity tables into independent, overlapping high and low T sections.
		select one of each at run time and specify temperature range for transition between them
		high T options (kappa_file_prefix in star controls)
			'a09' Asplund, Grevesse, Sauval, and Scott (2009) OPAL Type1 
			'gn93' Grevesse & Noels (1993) OPAL Type1 
			'gs98'Grevesse & Sauval (1998) OPAL Type1 
			'OP'  Opacity Project tables (similar to gs98)
		enhanced C/O high T tables (kappa_CO_prefix in star controls)
			'gn93_co' C/O enriched -- based on Grevesse & Noels (1993) OPAL Type2
		low T options (kappa_lowT_prefix in star controls)
			'lowT_af94_gn93' Alexander & Ferguson (1995) with gn93 metals
			'lowT_fa05_gn93' Ferguson, Alexander, et al (2005) with gn93 metals
			'lowT_fa05_gs98' Ferguson, Alexander, et al (2005) with gs98 metals
			'lowT_Freedman11' Freedman (2011) -- currently for solar only.  more Zs coming soon.
		transition temperature range (set in star controls)
			kappa_blend_logT_upper_bdy and kappa_blend_logT_lower_bdy (e.g. 4.1 and 4.0)
	higher resolution for tables 
		we now create higher resolution tables in the preprocessor to reduce interpolation effects at runtime
		and we look forward to getting higher resolution low T data from Jason Ferguson in the near future.
		if you know a way to get higher resolution data from OPAL or OP, please let me know.
	new low T tables from Richard Freedman
		as described in Freedman et al. (2008), 
			with updates to the molecular hydrogen pressure-induced opacity (Frommhold et al. 2010) 
			and the ammonia opacity (Yurchenko et al. 2011)
		previously only had solar Z.  now interpolate Z using tables for these: 0.01, 0.02, 0.04, 0.10, 0.20, 0.63, and 1.00
		now using new CIA opacities from Didier Saumon and his collaborators. (replaces the older Borysow data)
		includes the UCL NH3 which is much more extensive that the hitran NH3 that was esed before. 
			This causes an increase in the opacities in a limited temperature range where NH3 is abundant.
		references:
			Freedman et al. ApJS 174 504 (2008)
			Frommhold et al. Molecu. Physics 108, 2265 (2010)
			Yurchenko et al. MNRAS 413 1828 (2011)
	calls to kap now pass zbar (average ion charge) for use in calculating electron conduction at high density
		and lnfree_e (free electron density) for use in calculating Compton scattering at high T

eos
	we now have eos tables from Jim MacDonald for high Z with partial ionization
		the OPAL eos tables only go up to Z = 0.04
		previously we automatically switched to using HELM for Z > 0.04, 
			but HELM only provides results for fully ionized or neutral gas
		thanks to Jim MacDonald we now have another option for high Z.
			his tables account for partial ionization and cover the same T, Rho range as OPAL
			there are also (T,Pgas) tables for those of you using eos_PT
		in addition to the OPAL/SCVH tables for Z = 0.00, 0.02, and 0.04, 
			we have tables from Jim for Z = 0.20 and Z = 1.00
			For the Z = 1.00 case, there are 3 options for metals
			set eosDT_Z1_suffix and eosPT_Z1_suffix in star controls to select Z = 1.00 metals
			alternatives are the following (others can perhaps be added if you ask Jim nicely)
				'_CO_1' 	49.5% C12 and 49.5% O16 and 1% "solar" metals -- this is the default
				'_CO_0' 	50% C12 and 50% O16
				'' 		100% solar
		control in star for the highZ tables
         		Z_all_HELM = 1d99 ! switch to HELM for Z > this  
		for backward compatibility, you can set Z_all_HELM to 0.04

ionization
	we also now have tables from Jim MacDonald for average charge and neutral fraction
 		values are provided for H, He, C, N, O, Ne, Mg, Si, and Fe
		you can add the following to your profile_columns.list file for star
			avg_charge_<X>
			neutral_fraction_<X>
			where <X> = H, He, C, N, O, Ne, Mg, Si, or Fe.  
			e.g., avg_charge_Fe or neutral_fraction_H

atm
	we now include atmosphere tables from Rene Rohrmann for use with white dwarfs
		(thanks to Mike Montgomery for initiating this)
	the tables cover Teff from 10000 to 2500 and logg from 6.5 to 9.0 at an optical depth of 25
	reference:
		Rohrmann, R. D.; Althaus, L. G.; Kepler, S. O.
		Lyman α wing absorption in cool white dwarf stars
		Mon. Not. R. Astron. Soc. 411, 781–791 (2011)
	to use them in mesa/star, set which_atm_option = 'WD_tau_25_tables'
	the wd_cool case in the star test_suite has been modified to show an example --
		and it illustrates how to coax star into using higher resolution at the surface.
		that's a good idea to do before switching to the table.

FYI: we recently discovered that our eps_nuc values for hydrogen burning are about 1% too large
	we're working on this problem, but it isn't fixed yet -- and we want to let you know.
	the source of the difference is an old approximation that uses baryon number in place of atomic weight.
	so with hydrogen, for example, we use the integer 1 in place of the real atomic weight 1.00782505
	for nuclear burning, we get number density from mass fraction divided by atomic weight,
	so we overestimate  hydrogen number density, and correspondingly overestimate h burning eps_nuc.
	for CNO, our eps_nuc is too high by 0.78%, while for PP is about twice that.
	of course it isn't just hydrogen burning that is impacted, but the size of the error is largest there.
	e.g., for he4, we're using integer 4 in place of the real 4.0026031, so the error factor is < 1e-3.
	but if you are after precision at 1% of better for hydrogen burning, you'll want to know about this problem.
	the fix isn't trivial because the use of baryon number for atomic weight is built into some other things also.
	you'll be hearing from as soon as we have a new version that takes care of this problem.

Cheers,
Bill