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

Re: [mesa-users] report on failure of installing version 3607

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

Hi Alfred,

Perhaps we have a compiler incompatibility?
I've rechecked the atm install on (mac/linux) with (ifort/gfortran) 
and all 4 cases work with the particular compilers I'm using.

on linux I've got gfortran 4.6.0; on mac it is 4.6.1
on linux I've got ifort 12.0.3; on mac it is 12.0.4

good luck!

-Bill



On Sep 4, 2011, at 7:45 AM, Alfred Gautschy wrote:

> Gentlemen, 
> 
> first, thanks for the information on recent changes and for the
> efficient work to expand the Mesa domain of applicability. 
> 
> When I tried to upgrade to version 3607 I unfortunately ran into
> problems at Mesa/mesa/atm/test; build_and_test failed when performing
> Do_One_Grey_Irradiated, everything before is perfect: 
> 
> The terminal output just before failure is:
> 
> <              Do_One_Grey_Irradiated: kap    3.3036958409266584E-02
> --- field 3	relative error 8.18e-01
>>             Do_One_Grey_Irradiated: kap    1.8176165663029643E-02
> 71c71
> <                                      tau    2.2023436474453483E+01
> --- field 2	relative error 9.84e-01
>>                                     tau    1.1100502830879284E+01
> 75c75
> <                                        T    1.9891409201680560E+03
> --- field 2	relative error 1.72e-01
>>                                       T    1.6974910696457246E+03
> 76c76
> <                                     logT    3.2986655516932868E+00
> --- field 2	relative error 2.13e-02
>>                                    logT    3.2298074981726947E+00
> 
> The relevant output in tmp.txt reads as
> 
>             Do_One_Grey_Irradiated: kap    3.3036958409266584E-02
>                             M/M_jupiter    1.5000000000000000E+00
>                             R/R_jupiter    1.6101763189034692E+00
>                                  R/Rsun    1.6174176934805662E-01
>                                   kap_v    4.0000000000000001E-03
>                                       P    1.0000000000000000E+06
> 
>                                     tau    2.2023436474453483E+01
>                                    Teff    1.1307462496356613E+03
>                                    T_eq    1.0000000000000000E+03
>                                   T_int    9.0000000000000000E+02
>                                       T    1.9891409201680560E+03
>                                    logT    3.2986655516932868E+00
> 
> Any help to overcome the problem is very much appreciated.
> 
> With regards, 
> Alfred
> 
> 
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better 
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] report on failure of installing version 3607

[Alfred G. <al...@ga...>]

Gentlemen, 

first, thanks for the information on recent changes and for the
efficient work to expand the Mesa domain of applicability. 

When I tried to upgrade to version 3607 I unfortunately ran into
problems at Mesa/mesa/atm/test; build_and_test failed when performing
Do_One_Grey_Irradiated, everything before is perfect: 

The terminal output just before failure is:

<              Do_One_Grey_Irradiated: kap    3.3036958409266584E-02
--- field 3	relative error 8.18e-01
>              Do_One_Grey_Irradiated: kap    1.8176165663029643E-02
71c71
<                                      tau    2.2023436474453483E+01
--- field 2	relative error 9.84e-01
>                                      tau    1.1100502830879284E+01
75c75
<                                        T    1.9891409201680560E+03
--- field 2	relative error 1.72e-01
>                                        T    1.6974910696457246E+03
76c76
<                                     logT    3.2986655516932868E+00
--- field 2	relative error 2.13e-02
>                                     logT    3.2298074981726947E+00

The relevant output in tmp.txt reads as

             Do_One_Grey_Irradiated: kap    3.3036958409266584E-02
                             M/M_jupiter    1.5000000000000000E+00
                             R/R_jupiter    1.6101763189034692E+00
                                  R/Rsun    1.6174176934805662E-01
                                   kap_v    4.0000000000000001E-03
                                       P    1.0000000000000000E+06
 
                                     tau    2.2023436474453483E+01
                                    Teff    1.1307462496356613E+03
                                    T_eq    1.0000000000000000E+03
                                   T_int    9.0000000000000000E+02
                                       T    1.9891409201680560E+03
                                    logT    3.2986655516932868E+00

Any help to overcome the problem is very much appreciated.

With regards, 
Alfred

[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
 


	


 

Re: [mesa-users] Add my whinging to the discussion

[Ehsan M. <mor...@ia...>]

Dear Kent,
Hi. I hope I understood your message well. In case you are in favor of
blue looping models to produce HB stars, and let them evolve up the AGB
branch, I spent some days exploring this with MESA.

My first initial suggestion is to use Ledoux criterion to mix all
surroundings of burning zones with partially mixed material, enlarge their
extent and mass, and postpone their evolution till they start burning He
just before their first RGB excursion.
There remains the sensitivity of occurrence of blue loops to the initial
semi-convection and overshooting coefficients. I used to explore this with
models of 15 to 20 Msun.
However, I still cannot comprehend the central role of Ledoux criterion on
this.
Moreover, I found rotational mixing repulsive towards creating blue loops.
This is in contrast to the very recent work of Mayenet et al. (2011) who
have blue loops in massive star models including rotation. Yet to be
explored ...

Maybe I totally misunderstood you, and I am not worried, since I am for
sure stupid enough to stay in stellar physics.

Best wishes.
Ehsan.

> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> </head>
> <body bgcolor="#ffffff" text="#000000">
> I see that there's been a lot of kvetching here lately. I might as well
> jump right in.<br>
> <br>
> I've been revisiting the question of the evolutionary status of Type II
> Cepheids, prompted by a suggestion from Alfred Gautschy that this
> should be looked at with a modern evolution code and up-to-date
> physics. The Conventional Wisdom is that the short-period Type II
> Cepheids are stars evolving from the horizontal branch to the
> asymptotic giant branch, while longer-period Type II Cepheids are
> making blue excursions due to shell helium flashes. And by
> "Conventional Wisdom" I mean Wallerstein (2002) and sources therein.<br>
> <br>
> So I've been exploring the relevant parameter space. To keep things
> tractable, I assume 13.8 GYr as the Hubble time, Y=0.2485 as the
> current accepted Big Bang helium fraction, 0.07 as the overshoot scale
> height fraction, and to get to a reasonable starting place, I'm trying
> to reproduce the morphology of M14 since it's a cluster with an unusual
> number of Type II Cepheids; that means [Fe/H] around -1.5 and an age
> close to the Hubble time. Unsurprisingly, it takes a fair amount of
> mass loss on the red giant branch to produce a reasonable horizontal
> branch with reasonable RR Lyrae masses in a Hubble time. So far so
> good.<br>
> <br>
> Now, what's puzzling me is that just about every model in this region
> undergoes hydrogen ingestion either in the core helium flash or on the
> first shell flash. This leads to some spectacular mixing and the model
> almost immediately goes to a cooler, brighter carbon star. There isn't
> a prayer of getting a blue loop out of any of these models. But before
> reaching sweeping conclusions about the incorrectness of the
> Conventional Wisdom for explaining longer-period Type II Cepheids, I
> thought a sanity check was in order. Anything I should/should not be
> doing that might explain this alacrity for ingesting hydrogen? <br>
> <br>
> And, yeah, what Bill said earlier. If I'm stupid enough to be working
> in stellar evolution, I'm probably too stupid to be working in stellar
> evolution. Or something. <br>
> <br>
> --Kent G. Budge<br>
> <br>
> david arnett wrote:
> <blockquote
>  cite="mid:CAGpgfQFgxZXp+ra-V=UjU...@ma..."
>  type="cite">Hi Bill and Tuguldur,
>   <div>This is an "interesting" region, which, imho, is based on
> algorithms not physics. I plan to add to Mesa a physics based algorithm
> (with Bill's aid and permission) in October when I am at Kavli ITP. I
> am now testing it in TYCHO. It is based on the work that Casey Meakin
> and I have done, analyzing 3D turbulent simulations. I think that Bill
> and I will not stop until this becomes sane.</div>
>   <div>Dave Arnett</div>
>   <div><br clear="all">
>   <div><br>
>   </div>
> -- <br>
> David Arnett<br>
> Regents Professor<br>
> Steward Observatory<br>
> University of Arizona<br>
>   </div>
>   <pre wrap="">
> <hr size="4" width="90%">
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. <a class="moz-txt-link-freetext"
> href="http://p.sf.net/sfu/emc-vnx-dev2dev">http://p.sf.net/sfu/emc-vnx-dev2dev</a></pre>
>   <pre wrap="">
> <hr size="4" width="90%">
> _______________________________________________
> mesa-users mailing list
> <a class="moz-txt-link-abbreviated"
> href="mailto:mes...@li...">mes...@li...</a>
> <a class="moz-txt-link-freetext"
> href="https://lists.sourceforge.net/lists/listinfo/mesa-users">https://lists.sourceforge.net/lists/listinfo/mesa-users</a>
>   </pre>
> </blockquote>
> <br>
> <br />--
> <br />This message has been scanned for viruses and
> <br />dangerous content by
> <a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
> <br />believed to be clean.
> </body>
> </html>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed.
> http://p.sf.net/sfu/emc-vnx-dev2dev_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[mesa-users] Add my whinging to the discussion

[Kent G. B. <kg...@la...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I see that there's been a lot of kvetching here lately. I might as well
jump right in.<br>
<br>
I've been revisiting the question of the evolutionary status of Type II
Cepheids, prompted by a suggestion from Alfred Gautschy that this
should be looked at with a modern evolution code and up-to-date
physics. The Conventional Wisdom is that the short-period Type II
Cepheids are stars evolving from the horizontal branch to the
asymptotic giant branch, while longer-period Type II Cepheids are
making blue excursions due to shell helium flashes. And by
"Conventional Wisdom" I mean Wallerstein (2002) and sources therein.<br>
<br>
So I've been exploring the relevant parameter space. To keep things
tractable, I assume 13.8 GYr as the Hubble time, Y=0.2485 as the
current accepted Big Bang helium fraction, 0.07 as the overshoot scale
height fraction, and to get to a reasonable starting place, I'm trying
to reproduce the morphology of M14 since it's a cluster with an unusual
number of Type II Cepheids; that means [Fe/H] around -1.5 and an age
close to the Hubble time. Unsurprisingly, it takes a fair amount of
mass loss on the red giant branch to produce a reasonable horizontal
branch with reasonable RR Lyrae masses in a Hubble time. So far so good.<br>
<br>
Now, what's puzzling me is that just about every model in this region
undergoes hydrogen ingestion either in the core helium flash or on the
first shell flash. This leads to some spectacular mixing and the model
almost immediately goes to a cooler, brighter carbon star. There isn't
a prayer of getting a blue loop out of any of these models. But before
reaching sweeping conclusions about the incorrectness of the
Conventional Wisdom for explaining longer-period Type II Cepheids, I
thought a sanity check was in order. Anything I should/should not be
doing that might explain this alacrity for ingesting hydrogen? <br>
<br>
And, yeah, what Bill said earlier. If I'm stupid enough to be working
in stellar evolution, I'm probably too stupid to be working in stellar
evolution. Or something. <br>
<br>
--Kent G. Budge<br>
<br>
david arnett wrote:
<blockquote
 cite="mid:CAGpgfQFgxZXp+ra-V=UjU...@ma..."
 type="cite">Hi Bill and Tuguldur,
  <div>This is an "interesting" region, which, imho, is based on
algorithms not physics. I plan to add to Mesa a physics based algorithm
(with Bill's aid and permission) in October when I am at Kavli ITP. I
am now testing it in TYCHO. It is based on the work that Casey Meakin
and I have done, analyzing 3D turbulent simulations. I think that Bill
and I will not stop until this becomes sane.</div>
  <div>Dave Arnett</div>
  <div><br clear="all">
  <div><br>
  </div>
-- <br>
David Arnett<br>
Regents Professor<br>
Steward Observatory<br>
University of Arizona<br>
  </div>
  <pre wrap="">
<hr size="4" width="90%">
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/emc-vnx-dev2dev">http://p.sf.net/sfu/emc-vnx-dev2dev</a></pre>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
mesa-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mes...@li...">mes...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/mesa-users">https://lists.sourceforge.net/lists/listinfo/mesa-users</a>
  </pre>
</blockquote>
<br>
</body>
</html>

[mesa-users] massive stars (M>15)

[david a. <wda...@gm...>]

Hi Bill and Tuguldur,
This is an "interesting" region, which, imho, is based on algorithms not
physics. I plan to add to Mesa a physics based algorithm (with Bill's aid
and permission) in October when I am at Kavli ITP. I am now testing it in
TYCHO. It is based on the work that Casey Meakin and I have done, analyzing
3D turbulent simulations. I think that Bill and I will not stop until this
becomes sane.
Dave Arnett


-- 
David Arnett
Regents Professor
Steward Observatory
University of Arizona

[mesa-users] Odd mixing behavior in massive stars...

[Josh S. <jhs...@be...>]

Users,

It's been a while since I've contributed, but I've been here plugging away up here in Berkeley (including staying updated with MESA releases). 

So here's my question:

In evolving massive stars (I find issue with anything >~ 40 Msun), has anyone had problems with oddly behaving convection zones? The basic behavior I see is, usually during core hydrogen fusion, convection zones form near the original location of the convective core boundary and "roll" inward in mass until they connect with the core convection zone, dumping fresh hydrogen. 

For reference, I've started with the 40M_z1m4_to_si_burn test case inlist and modified to get what I've been working with. That case works swimmingly! As does m=40, z=0.02, opacity = electron-scattering (example is attached).

Depending on the parameters for mixing (Ledoux vs. Schwarzschild), semiconvection on or off, overshoot parameters, and so on and so on, this happens before or after (or both) hydrogen is exhausted in the convective core. You can see this in some of the attached Tioga "Internal Structure" plots from various runs of a 100 solar mass star with zero metallicity and electron scattering opacity (to address other issues in the atmosphere). This behavior seems to occur independent of overshoot being on (overshoot_f_* = 0.01) or off (overshoot_f_* = 0) and independent of global resolution over the range of 0.7 < mesh_delta_coeff < 2 and having (or not having) locally enhanced resolution using xtra_coeff_* = 0.1...

When fresh H is dumped into an exhausted core, the results are quite.. exciting, but I don't understand the origin of these shifting convection zones? I will continue exploring the mixing parameter space in search of less exciting evolutionary behavior in line with what I expect to see (smooth transitions from burning phase to burning phase), but I am hoping to get suggestions, feedback, shared experience,.. moral support(?) from the users on this. Anyone seen this before? Fixed it for themselves? 

The key to the pdfs is after "Internal_Structure_" the first letter is S/L for Sch or Ledoux criterion, O if there is overshoot, L/H for low or high res, and B if the resolution is enhanced at the boundaries. (I have more examples of these now, and will likely have even more in the next few days, if someone is interested.)

Thanks,


--
Josh Shiode
Graduate Student Researcher
NASA Earth & Space Sciences Fellow
Theoretical Astrophysics Center
University of California, Berkeley
753 Campbell Hall
jhs...@be...

Re: [mesa-users] creating preSN model

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

Hi,

On Aug 25, 2011, at 4:58 PM, Tuguldur Sukhbold wrote:

> - why this slight difference in numerical values of Y and Z making this difference in the runs?
> - what should I do to prevent these extremely small timesteps during the Si burning phase?
> 
> Please enlighten me! I am a new graduate student and am very confused with this situation.
> 

in my experience, stellar evolution codes are confusing, disappointing, and depressing.
so my 1st suggestion is that you change research areas.

if in spite of that, you decide to continue, you should at least change your expectations:
expect the code to fail and be amazed and delighted if it somehow manages to work.

at this moment I am trying to fix a typical problem with mesa -- I have all of the test cases running
fine on my mac with ifortran and gfortran, but when I run them on a linux machine, there is one
subcase of one of the tests that fails; all the rest are fine.  same code, same data, same inlists,
but one out of a huge set of tests fails for no apparent reason.   I'll make some random changes
until something makes the problem go away, but i'm not likely to ever understand what is going on.

for your particular question about massive stars, my only suggestion to is start from something
that works and make small changes to see if you can find other things that work.  but expect
that the small changes will trigger some nasty non-linearity that causes things to break.
then redefine your research topic to focus on the things that work and skip those that don't.
if you fix your topic 1st and expect to force the code to cooperate, you're doomed.

you might start from the 15M_si_burn test case in star/test_suite.  It should run to onset of core collapse.
Once you get that to work, change it to start from ZAMS instead of from a saved model.
If that works, try changing the mass -- I've been able to make 15, 20, and 25 work with Z=0.02;
outside of that range, I've run into problems and haven't put in the time to search for a solution.
then try changing Z -- and try changing mixing (overshoot/semiconvection/rotational) --
and try changing mass loss (superEddington/supersonic/rotationally enhanced/...).

if you manage to make progress on this, please let me know how you've done it!

good luck,
Bill

Re: [mesa-users] show two profiles

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

Hi Jing,

Have you tried using these controls for the Profile window?

         ! axis choices -- use names from mesa/data/star_data/profile_columns.list
         ! you can also use element names or reaction category names
         ! here is a partial list of the available choices:
            ! mass, logT, logRho, logP, logR, entropy, csound, log_opacity, 
            ! eta, mu, grada, gradr, tau, chiRho, abar, ye, luminosity, ....
            ! h1, he3, c12, ...
            ! pp, cno, tri_alfa, .... (see rates/public/rates_def.f)
         Profile_xaxis_name = 'mass'
         Profile_xmin = -101 ! only used if > -100
         Profile_xmax = -101 ! only used if > -100
         
         Profile_yaxis_name = 'logT'
         Profile_yaxis_reversed = .false.
         Profile_ymin = -101 ! only used if > -100
         Profile_ymax = -101 ! only used if > -100        
         Profile_dymin = -1 
         
         Profile_other_yaxis_name = '' 
         Profile_other_yaxis_reversed = .false.
         Profile_other_ymin = -101 ! only used if > -100
         Profile_other_ymax = -101 ! only used if > -100
         Profile_other_dymin = -1
         
         ! extra axis choices
            ! in your run_star_extras routine extras_finish_step,
            ! store the values to be plotted for each cell in the model.
            !
            !    	do k=1,s% nz ! up to 9 extra values for plotting
            !  		s% profile_extra(k,1) = value1(k)
            !  		s% profile_extra(k,2) = value2(k)
            !  		s% profile_extra(k,3) = value3(k)
            !  	end do
            !  	s% profile_extra_name(1) = 'label for value1 axis'
            !  	s% profile_extra_name(2) = 'label for value2 axis'
            !  	s% profile_extra_name(3) = 'label for value3 axis'
            !
            ! in your inlist you can set Profile_xaxis_name,
            ! Profile_yaxis_name, or Profile_other_yaxis_name
            ! to any of 'profile_extra1', 'profile_extra2', 'profile_extra3', ...


-Bill





On Aug 20, 2011, at 10:28 AM, Jing Luan wrote:

> Dear Mesa-users,
> 
> There are three profiles showing on the main pgplot window under the T-Rho profile. How to change the y-axis of these profiles please? I currently only know how to change the x-axis in inlist_project;
> 
> For example, I would like to plot two profile-figures showing on the main window, each figure containing two profiles:
> 
> 1,  M(>r) (i.e. mass outside radius r) and Mh(>r) (i.e. hydrogen mass outside r) as functions of logR
> 2, logRho and \epsilon_nuc as functions of logR;
> 
> The special thing is that there is only M(<r) and s% xa(j,k) directly readable from MESA's data pointer s, I can calculate M(>r) and Mh(>r) in run_star_extras.f, but how could I let pgplot read in my own data to make the first profile-figure please?
> 
> Thank you very much :-)
> 
> -- 
> Sincerely
> Jing
> 
> Ph.D candidate at physics.caltech
> email: jin...@ca...
> address: MC350-17,Caltech,1200 E.California Blvd
>         Pasadena, CA 91125
> 
> 

[mesa-users] blue loops

[Jeremy S. <j.a...@da...>]

Hello Everyone,

I've been looking at blue loops for high mass stars (5-10 solar masses) for 
varying initial metallicities and have found something a bit odd. For 
metallicities z=0.005ish to 0.014 the blue loop all but disappears. Has 
anyone else found this as well?

Cheers,

Jeremy

[mesa-users] show two profiles

[Jing L. <jin...@ca...>]

Dear Mesa-users,

There are three profiles showing on the main pgplot window under the 
T-Rho profile. How to change the y-axis of these profiles please? I 
currently only know how to change the x-axis in inlist_project;

For example, I would like to plot two profile-figures showing on the 
main window, each figure containing two profiles:

1,  M(>r) (i.e. mass outside radius r) and Mh(>r) (i.e. hydrogen mass 
outside r) as functions of logR
2, logRho and \epsilon_nuc as functions of logR;

The special thing is that there is only M(<r) and s% xa(j,k) directly 
readable from MESA's data pointer s, I can calculate M(>r) and Mh(>r) in 
run_star_extras.f, but how could I let pgplot read in my own data to 
make the first profile-figure please?

Thank you very much :-)

-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200 E.California Blvd
          Pasadena, CA 91125

[mesa-users] Moment of inertia

[Tsing W. <tsingwong2012@u.northwestern.edu>]

Hi Mesa users,

I would to know whether mesa writes the moment of inertia of the star (or
anything similar) to the output files. I looked into log_columns.list in
data/star_data and did not find anything close to the moment of inertia.

Thanks,
TsingWai

[mesa-users] how to save figure?

[阿亮 <chl...@gm...>]

Hello,
       I can save the figure every several steps, but I just want to save
the
   last figure when it terminates. What should I do?

       Thank you very much !
       Sincerely

       chal

Re: [mesa-users] onset of He-burning

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

Hi Maurizio,

Please take a look at logical function time_to_profile in
star/private/do_one_utils.f.  This is where the evolutionary "phase" of the
model is determined.

Aaron




On Tue, Aug 16, 2011 at 10:40 AM, Giannotti, Maurizio <
MGi...@ma...> wrote:

>  Hello All,
>
> I downloaded and I have been studying MESA since the beginning of the
> summer. I think it is great. I am hoping to write a paper soon with my
> colleagues in Los Alamos. I have 2 questions:
>
> 1) What is the exact criteria used by MESA to identify the onset of
> He-burning? I understand that Mesa saves a model (and gives it priority 2)
> at the onset of He-burning. Does this mean that the parameter "tri_alfa" (or
> "log_LHe") reaches a certain threshold value? If so, what?
>
> 2) It would be nice to find a list of all the criteria which MESA uses to
> give priority 2 to a model. I read in the MESA home page: "Priority level 2
> is for models saved because of some special event in the evolution such as
> the onset of helium burning". Is there somewhere a list of all these
> "special events"?
>
> Thank you very much,
> Maurizio
>
>
>
>  Maurizio Giannotti,
>
> Assistant Professor of Physics,
>
> Physical Sciences, Barry University,
>
> 11300 NE 2nd Ave., Miami Shores, FL 33161
>
> mgi...@ma...
>
> 305-899-4565 (office), 305-899-3479 (fax)
>
>
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] onset of He-burning

[Giannotti, M. <MGi...@ma...>]

Hello All,

I downloaded and I have been studying MESA since the beginning of the summer. I think it is great. I am hoping to write a paper soon with my colleagues in Los Alamos. I have 2 questions:

1) What is the exact criteria used by MESA to identify the onset of He-burning? I understand that Mesa saves a model (and gives it priority 2) at the onset of He-burning. Does this mean that the parameter "tri_alfa" (or "log_LHe") reaches a certain threshold value? If so, what?

2) It would be nice to find a list of all the criteria which MESA uses to give priority 2 to a model. I read in the MESA home page: "Priority level 2 is for models saved because of some special event in the evolution such as the onset of helium burning". Is there somewhere a list of all these "special events"?

Thank you very much,
Maurizio



Maurizio Giannotti,
Assistant Professor of Physics,
Physical Sciences, Barry University,
11300 NE 2nd Ave., Miami Shores, FL 33161
mgi...@ma...<mailto:mgi...@ma...>
305-899-4565 (office), 305-899-3479 (fax)

Re: [mesa-users] neutral H in giants' envelope

[Jing L. <jin...@ca...>]

Hello,

There is a parameter called lnfree_e ( please check 
star/public/star_data.dek) indicating the free electron number per 
nucleon. You can refer it as s% lnfree_e. You could then use Saha's 
equation, together with the temperature s% T to get the ionization 
fraction of H. I do not know that there is a direct H ionization 
fraction parameter though.

Hope it helps :-)

Sincerely,
Jing

On 8/11/11 9:24 PM, Jean-Claude Passy wrote:
> Hi mesa-users,
>
> I have a stellar structure of a giant star and I would like to know how
> much of the envelope is already neutral H. How could I get this
> information ?
>
> Any help would be greatly appreciated.
> Thanks a lot,
>
> JC
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users


-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200 E.California Blvd
          Pasadena, CA 91125

[mesa-users] neutral H in giants' envelope

[Jean-Claude P. <jc...@gm...>]

Hi mesa-users,

I have a stellar structure of a giant star and I would like to know how 
much of the envelope is already neutral H. How could I get this 
information ?

Any help would be greatly appreciated.
Thanks a lot,

JC

[mesa-users] what is the radius of the star in mesa?

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

On Aug 11, 2011, at 9:45 AM, Jeremy Sakstein wrote:
> I'm just trying to check a few details in my data, what does MESA use as the radius of the star? Is it the radius where T and P are 0 or is the the photospheric radius where T=Teff and the optical depth is 2/3 (I'm assuming this is how Teff is definied)?


Hi Jeremy,

There is a distinction between "photospheric radius" and "surface radius".
The surface of the star is defined to be the outer edge of the outermost cell in the model.
The optical depth of the surface is = tau_base * tau_factor (see star_data.dek for these).
The photosphere radius is defined in terms of the total luminosity and the effective temperature.
The atmosphere module decides what tau corresponds to the photosphere (2/3 typically),
and it also tells us what Teff is.

In the current options in log_columns.list, I'm only giving information for the surface radius.
I'll add options for the photosphere for the next release -- thanks for leading me to discover this shortfall.

In the meantime, if you'd like to add a log column for the photosphere radius to your logs, you can of course 
do it in your run_star_extras.   You'll even find the desired value in s% photosphere_r (Rsun units).

Cheers,
Bill

Re: [mesa-users] unable to open isotopes.data

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

Hi,

In the star_job section of your inlist, you need to set

      mesa_data_dir = '../../data'

So that it points to the correct mesa data directory.  It is as above by
default, which should work for the basic test and work directories but not
when you move to a new location.

Aaron




On Wed, Aug 10, 2011 at 10:31 AM, Li Gongjie <li...@gm...> wrote:

> Hi all,
> I have just installed MESA and the appetizer works successfully :) However,
> I have a problem making my copy of mesa star by running the 'rn' script in a
> work folder.  I made a copy of the work directory and renamed it. Then I
> edited the make/makefile to set MESA_DIR, and edited the &star_job section
> of the inlist_project file. I've made the work version of star by executing
> the 'mk' script, which went well. However, when I run the 'rn' script, it
> reports:
>
>  unable to open ../../data/chem_data/isotopes.data
>  failed in stardata_init
>  star_init ierr          29
> WARNING: failed in chem_init
>  init_and_alloc ierr          29
> WARNING: failed in chem_init
>
> I tried to open isotopes.data myself using emacs and it works well. I don't
> know how to fix this. I am using ifort 12.0.2.
>
> Thank you so much!
>
> best wishes,
> Gongjie Li
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] unable to open isotopes.data

[Li G. <li...@gm...>]

Hi all,
I have just installed MESA and the appetizer works successfully :) However,
I have a problem making my copy of mesa star by running the 'rn' script in a
work folder.  I made a copy of the work directory and renamed it. Then I
edited the make/makefile to set MESA_DIR, and edited the &star_job section
of the inlist_project file. I've made the work version of star by executing
the 'mk' script, which went well. However, when I run the 'rn' script, it
reports:

 unable to open ../../data/chem_data/isotopes.data
 failed in stardata_init
 star_init ierr          29
WARNING: failed in chem_init
 init_and_alloc ierr          29
WARNING: failed in chem_init

I tried to open isotopes.data myself using emacs and it works well. I don't
know how to fix this. I am using ifort 12.0.2.

Thank you so much!

best wishes,
Gongjie Li

Re: [mesa-users] Derivatives of eps_nuc in massive evolved models

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

On Aug 9, 2011, at 1:40 PM, Alfred Gautschy wrote:

> It seems that the Mesa coders decided to compute nuclear energy
> generation to quite low temperatures (Bill: do you have any numbers
> ready?)


2e5 for the low end

-b

Re: [mesa-users] Derivatives of eps_nuc in massive evolved models

[Alfred G. <al...@ga...>]

Ehsan

as far as I can see the partials eps_T and eps_Rho look fine to me.
Notice that eps_T and eps_Rho are not zero as long as the coder decided
nuclear reacations are to be computed. Even though the magnitude of
epsilon_nuc itself will be essentially zero, the partials are not. 

Since in all applications I came across, always the combination of
eps_nuc * eps_T or eps_nuc * eps_Rho occurred, these composed functions
are always very smooth and they are restricted to the nuclear burning
regions of a star. 

It seems that the Mesa coders decided to compute nuclear energy
generation to quite low temperatures (Bill: do you have any numbers
ready?)

Along the pragmatic and heuristic avenue: As star models react very
sensitively to eps_T and eps_nuc during the Henyey iterations, and since
the tests of Mesa apparently run very reliable and compare well with the
literature, I guess that the partials are computed correctly; at least
consistent with eps itself. 

I doubt that there is anything helpful in the literature regarding eps_T
and eps_Rho; it's all auxiliary machinery no referee (and probably
reader) wants to see in the end.   

Regards, Alfred

Re: [mesa-users] change dir

[Jean-Claude P. <jc...@gm...>]

Hello Jing,

you have to change the variable MESA_DIR in mesa/star/work/make/makefile

Good luck,

JC

On 08/08/11 14:46, jingluan wrote:
> Hello,
>
> I just installed mesa 3290, and revised the makefile_head. When I tried
> to do ./mk under /star/work, it reports
>
> makefile:2: /Users/bpaxton/mesa/star/work_standard_makefile: No such
> file or directory
> make: *** No rule to make target
> `/Users/bpaxton/mesa/star/work_standard_makefile'.  Stop.
>
> FAILED
>
> It seems that I should revise the directory path in some makefile, but
> there are many makefiles under mesa. Which one shall I revise please?
>
> Thank you very much :-)
>

[mesa-users] change dir

[jingluan <jin...@ca...>]

Hello,

I just installed mesa 3290, and revised the makefile_head. When I tried 
to do ./mk under /star/work, it reports

makefile:2: /Users/bpaxton/mesa/star/work_standard_makefile: No such 
file or directory
make: *** No rule to make target 
`/Users/bpaxton/mesa/star/work_standard_makefile'.  Stop.

FAILED

It seems that I should revise the directory path in some makefile, but 
there are many makefiles under mesa. Which one shall I revise please?

Thank you very much :-)

-- 
Sincerely
Jing

Ph.D candidate at physics.caltech
email: jin...@ca...
address: MC350-17,Caltech,1200E.California Blvd,
          Pasadena, CA 91125

Re: [mesa-users] EoS & partial ionization

[Frank T. <fx...@ma...>]

that's right aaron, helm assumes full ionization, 
as does the PC eos at high densities. one could 
load a pure metal opal eos, but it would only be
valid in the opal regime - see fig 1 of paxton et al. 2011.

fxt



On Aug 3, 2011, at 5:42 PM, Aaron Dotter wrote:

> Hi Ken,
> 
> From eos/public/eos_lib.f:
> 
>       ! The MESA EOS is based on the OPAL, SCVH, and HELM EOS's.
>       ! The OPAL-SCVH values are used for approximately
>       !     Z < 0.04, logRho < 3.3, and logT < 7.7
>       ! HELM is used for all other cases.
>       
> Since you're in pure "Z" territory, you're accessing the HELM EoS which assumes full ionization  (Frank, correct me if I am wrong).
> 
> Aaron
> 
> 
> 
> On Wed, Aug 3, 2011 at 8:20 PM, Ken Shen <ke...@as...> wrote:
> Hi all.  I've got a question about how the MESA EoS handles partial
> ionization.  In particular, are the changes in free electron fraction
> taken into account when the EoS returns, e.g., chiT and chiRho?  As a
> test, here are the results for two calls to the EoS for X_12C = X_16O
> = 0.5 and rho = 2e-8 g/cm^3:
> 
> T = 6.5e4 K
> P = 9.022e4 dyne/cm^2
> free_e = 0.3463
> chiT = 2.499
> mu = 1.745
> 
> T = 6.4e4 K
> P = 8.577e4 dyne/cm^2
> free_e = 0.3364
> chiT = 2.482
> mu = 1.745
> 
> A crude calculation from these two calls gives dlnP/dlnT = 3.26, which
> is significantly different from the returned value of chiT = 2.5.
> Also, the mean molecular weight that is returned seems to assume full
> ionization; it should be 2.39 for the first call and 2.44 for the
> second.
> 
> 
> Thanks,
> Ken
> 
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
> 
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts. 
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users