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

Re: [mesa-users] very thin shell burning

[Falk H. <fh...@uv...>]

On 8-Mar-11, at 9:55 AM, Kent Budge wrote:

> So I'm running some Population III calculations at the lower end of  
> the
> mass range, and the very thin shell burning on the giant branch is
> taking *forever*.
>
> What's the latest thinking about mass loss in Population III? I know
> it's thought to be rather low, but just how rather low?

I think that really depends on the type of stars. There is common  
scaling out there in which Mdot ~ sqrt(Z) but that applies only to  
mass loss processes that are driven by radiation pressure on lines,  
and if there is no self-enrichment of the surface. For AGB stars both  
assumptions are wrong, since AGB stars will bring lots of C, O and  
other metals to the surface. I am not an expert on dust formation, but  
I think it is not clear that in particular in the C-rich phase for  
advance AGB stars, even at Pop III you could not have effective dust  
formation, which would activate the characteristic dust-driven wind  
mechanism of AGB stars. Observations seem to indicate at least that in  
the MCs Mdot is not smaller than in the Galaxy.

>
> What is the state of the art in modeling very thin shell burning?  
> Brute
> force seems, well, like brute force. Are there methods out there that
> treat it as a front propagation problem?
>

In Pop III AGB stars or even very low metallicity AGb stars you will  
encounter convective-overshoot induced H-flame propagation into the  
core when the convective envelope gets in touch with the hot CO core.  
This is not the regular H-shell in AGB stars, but rather a hot dregde- 
up after thermal pulses. That is a situation where a flame model would  
be needed, but I believe we have not much right now to base this on.  
Note that this is a flame across a fuel-mix boundary.

BEst, Falk.

> Interested in any information anyone has.
>
> -- Kent G. Budge
> CCS-2, LANL
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

--
Falk Herwig
Dept of Physics & Astronomy, U of Victoria
fh...@uv..., tel: +1 (250) 721-7743

Re: [mesa-users] On "modus videndi with very thin shell burning"

[Falk H. <fh...@uv...>]

Kent,

as Bill pointed out some shell-shifting algorithms have been tried in  
MESA in the past, and they were ejected when it came to rigourous  
verification leading up to the MESA paper. These  showed in addition  
to the data that Bill sent on RGB stars, that AGB stars would not  
produce proper mixing behaviour, in particular the absence or weaker  
appearance of the third dredge-up event.

As to how long things can run to be practical of course depends on the  
goals you have in mind. MESA does in 'high-fidelity' mode whatever it  
does at least 10 if not 20 times faster than what people including  
myself have been using before (and it does it better). Which does not  
mean that we should not try to improve further in speed, but just to  
give you a users perspective.

Best, Falk.



>
> I haven't run a calculation with a very thin shell all the way up the
> AGB. I'm not that patient. My guess, based on my attempts, is: At
> *least* several days even with four threads running. Sometimes it  
> may be
> worth the brute calculation, but it seems to me that it would be
> worthwhile to experiment with some kind of front propagator method.
> Frank, you pointed me at some leads; I'll take a look at these but I
> can't promise I'll be able to put anything useful in the code anytime
> soon. (Or ever.)

Re: [mesa-users] Changing gravity

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

Hi Jeremy,

I made the physical "constants" variables in mesa/const just so that you could change them at runtime without recompiling.  

If you are using mesa/star, you might want to change cgrav from you run_star_extras rather than editing the const module.

Cheers,
Bill



On Mar 26, 2011, at 9:35 AM, Jeremy Sakstein wrote:

> Hello everyone,
> 
> Just a quick question, if I want to change the value of G can I do that by 
> straight editing const or do I need to reinstall?
> 
> Regards,
> 
> Jeremy
> 
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software 
> be a part of the solution? Download the Intel(R) Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] Changing gravity

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

Hello everyone,

Just a quick question, if I want to change the value of G can I do that by 
straight editing const or do I need to reinstall?

Regards,

Jeremy

[mesa-users] read_data in movie_batch.rb

[Shawfeng D. <do...@uc...>]

Hi,

We are learning Mesa and its plotting tool Tioga, in the hope that we
can use them in our coming Stellar evolution and nuclear synthesis
course. Tioga itself appears to be working fine on my iMac. And I can
use Mesa to generate some simple outputs as instructed at:
http://mesa.sourceforge.net/how_to_use_mesa_star.html

However, when I try to use the Ruby script  movie_batch.rb at
mesa/star/test/star_profile, it always fails with some obscure error
messages. After some digging, it appears that the script fails when
calling 'read_data' on line 26 of the 'run' function. 'read_data' has
not been defined, not in any script in the directory, nor in the Tioga
library. Has anyone successfully got the script to work? Any advice is
highly appreciated!

Best,
Shaw
-- 
------------------------------------------------------
Shawfeng Dong
Astrophysics & High Performance Computing
ISB 331, UCO / Lick Observatory
Google Voice: (831) 824-4086
------------------------------------------------------

Re: [mesa-users] using Tioga

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

Hi,

Regarding wind schemes:
open star/public/star_defaults.dek in a text editor.
near the start you'll find a listing of sections, one of which is "mass gain or loss"
search for "mass gain or loss" and you'll find the details.
if you don't find your favorite scheme, you can implement it yourself -- see star/public/other_wind


And about the broken links for Tioga:  
it seems that KITP has changed server names on me -- even my homepage link is broken!
I'll fix the mesa website, but in the meantime this link seems to work to get you to the Tioga tutorial:
http://www.kitp.ucsb.edu/~paxton/tioga_doc/classes/Tioga/Tutorial.html


Cheers,
Bill










On Mar 25, 2011, at 11:44 AM, naveen yadav wrote:

> 
> Hi
> I have two queries:
> 1). How to set controls to use wind schemes in massive star evolution, and the wind schemes that are available.
> 2). How to use Tioga? The link on the page "http://mesa.sourceforge.net/how_to_use_mesa_star.html" pointing
> to the tioga webpage  and tutorials doesn't work. Please elaborate a little on the usage.
> 
> 
> 
> Regards
> Naveen Yadav
> T.I.F.R.
> Mumbai-400 005
> 
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software 
> be a part of the solution? Download the Intel(R) Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] using Tioga

[naveen y. <nav...@ya...>]

Hi
I have two queries:
1). How to set controls to use wind schemes in massive star evolution, and the 
wind schemes that are available.
2). How to use Tioga? The link on the page 
"http://mesa.sourceforge.net/how_to_use_mesa_star.html" pointing
to the tioga webpage  and tutorials doesn't work. Please elaborate a little on 
the usage.



Regards
Naveen Yadav
T.I.F.R.
Mumbai-400 005

Re: [mesa-users] On "modus videndi with very thin shell burning"

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

Hi,

Just for the record -- 
I've already implemented and discarded one shell tracking scheme in mesa for speedier evolution up the RGB.  It isn't in the current version and I don't recall when exactly it went away -- sometime after June last year.  I'm doing some work on 2308 at the moment, and I notice that it was still in mesa/star at that point.   I took it out because although it gave a nice speed up the cost in code complexity was high and the difference in results at tip of RGB when using or not using it were big enough to make me uncomfortable.  (see attached email for details)   Of course you can increase the mesh resolution to give up some of the performance improvement in order to improve the agreement with the "no tracking" results.  I didn't check what you'd find if you tried that -- perhaps something useful is possible.

If you are interested in shell tracking in mesa, you might want to take a look at what I tried.   Back in the old versions such as 2308, there is a case in the test_suite called "track_h_shell" that uses a moving mesh to speed up the climb of the RGB.

There is also an entire section in star_defaults.dek about it: search for "mesh shell tracking".

To compare with vs. without, change mesh_track_RGB_H_burn_shell.

In the inlist_track_h_shell, you can set 
	trace_shell_tracking_choice = .true.
to get info about when it is on (q_flag = true when mesh tracking is on).

To see the relevant code, grep for "q_flag" in star/private.

It works by adding variables for q and dq (which means adding a ton of partials wrt q and dq).  The equations for q and dq are in the file hydro_lnq_eqns.f    The equation for dq simply asserts that dq = difference of adjacent q's. The equation for q does the hard work.  In a region around the max H burning shell, it asserts that the H abundance is not changing.  That forces the cell to move to keep the constant abundance.  The moving of the cell causes new fuel to be advected into the cell from above to compensate for the fuel being consumed by nuclear reactions.  For cells away from the H shell burning, the q equation requires uniform expansion or contraction: dq(k)/dq(k-1) = dq_old(k)/dq_old(k-1).  Since the shell is moving outward, this means cells below the shell expand while those above the shell contract.  All very lovely, and after a lot of effort I was able to make it work.

But I threw it out.  Maybe it should make a return.   Or maybe it will inspire someone to come up with a better solution.   Anyway, thanks to svn it is out there if anyone wants to play.

Cheers,
Bill


p.s.  Here's an email I sent to the folks working on the mesa paper last June.   I hadn't removed shell tracking then, but I was clearly headed in that direction. 


Begin forwarded message:

> From: Bill Paxton <pa...@ki...>
> Date: June 10, 2010 9:09:49 AM PDT
> To: Falk Herwig <fh...@uv...>, Aaron Dotter <aar...@gm...>, Frank Timmes <fx...@ma...>, Lars Bildsten <bil...@ki...>
> Subject: downgrade H burn shell tracking to experimental feature
> 
> Hi,
> 
> The ability to do a moving mesh to tracking the H burn shell results in a large improvement in performance (2hr -> 0.5 hr up the rgb).
> However, it seems that the cost is that the outcome is rather different once you get to He ignition.
> 
> Here are two runs, one with and one without tracking.   same starting model at base of rgb.
> 
> 
> with tracking
> __________________________________________________________________________________________________________________________________________________
> 
>        step    lg_Tcntr    Teff       lg_LH     lg_Lnuc     Mass       H_rich     H_cntr     N_cntr     Y_surf     X_avg     eta_cntr   pts  retry
>    lg_dt_yr    lg_Dcntr    lg_Rsurf   lg_L3a    lg_Lneu     lg_Mdot    H_poor     He_cntr    O_cntr     Z_surf     Y_avg     gam_cntr  jacs  bckup
>      age_yr    lg_Pcntr    lg_L       lg_LZ     lg_Psurf    lg_Dsurf   He_poor    C_cntr     Ne_cntr    Z_cntr     Z_avg     v_div_cs     dt_limit
> __________________________________________________________________________________________________________________________________________________
>        3663   7.855993       3220   3.229236   3.229500   0.817264   0.372606   0.000000   0.009489   0.301727   0.308935  18.974893   1417      0
>    3.183611   5.856156   2.126318   0.003064   2.064288  -7.247372   0.444657   0.980081   0.004190   0.020073   0.671233   0.733377      5      0
>  1.2394E+10  22.222585   3.237919  -1.671797   2.859976  -8.440533   0.000000   0.000053   0.002100  1.992E-02  1.983E-02  0.849E-07    varcontrol
> 
> without tracking
> __________________________________________________________________________________________________________________________________________________
> 
>        step    lg_Tcntr    Teff       lg_LH     lg_Lnuc     Mass       H_rich     H_cntr     N_cntr     Y_surf     X_avg     eta_cntr   pts  retry
>    lg_dt_yr    lg_Dcntr    lg_Rsurf   lg_L3a    lg_Lneu     lg_Mdot    H_poor     He_cntr    O_cntr     Z_surf     Y_avg     gam_cntr  jacs  bckup
>      age_yr    lg_Pcntr    lg_L       lg_LZ     lg_Psurf    lg_Dsurf   He_poor    C_cntr     Ne_cntr    Z_cntr     Z_avg     v_div_cs     dt_limit
> __________________________________________________________________________________________________________________________________________________
>       13029   7.873137       3074   3.365682   3.365873   0.767695   0.308389   0.000000   0.009489   0.301727   0.272260  19.996251   1376      0
>    2.399317   5.922250   2.232614   0.000631   2.200669  -6.981584   0.459306   0.980079   0.004190   0.020073   0.707940   0.741678      3      0
>  1.2394E+10  22.325161   3.370038  -1.733428   2.718511  -8.560218   0.000000   0.000055   0.002100  1.992E-02  1.980E-02  0.198E-06    varcontrol
> 
> 
> 
> 
> 
> It looks to me like we need to make "no tracking" the default and add a warning to the "with tracking" option.
> 
> We can also drop the complexity of the tracking equations from the paper.
> 
> I don't plan to remove from the code (yet) since it may be possible for someone to salvage something someday.
> 
> But I can't at the moment come up with a situation in which saving 1.5 hours is worth getting such different results.
> 
> -B
> 
> 
> 
> 
> 

Re: [mesa-users] On "modus videndi with very thin shell burning"

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

hi kent,

thanks! waiting several days for a calculation to finish is not an issue
in my world. i agree though, that having some subgrid front propagation 
methods in mesa would pay dividendson a number of interesting problems.

fxt



On Mar 22, 2011, at 11:00 AM, Kent Budge wrote:

> The problem is not so much resolving the front. There's no particular
> limit on the number of levels of refinement in an adaptive method. I'm
> told some early universe simulations span thirty orders of magnitude.
> The problem is the restriction on the time step that results, a common
> problem with spatially adaptive time-dependent hydro methods. You have
> to take a very small time step to avoid rapid changes in the variables
> in the fine zones, or you might even take the burn front into a coarsely
> refined zone faster than the mesh can adapt if the time step is too
> small.
> 
> I haven't run a calculation with a very thin shell all the way up the
> AGB. I'm not that patient. My guess, based on my attempts, is: At
> *least* several days even with four threads running. Sometimes it may be
> worth the brute calculation, but it seems to me that it would be
> worthwhile to experiment with some kind of front propagator method.
> Frank, you pointed me at some leads; I'll take a look at these but I
> can't promise I'll be able to put anything useful in the code anytime
> soon. (Or ever.)
> 
> On Sun, 2011-03-20 at 14:31 -0700, Frank Timmes wrote:
>> hi alfred (& kent & theodore),
>> 
>> i'm curious what "taking forever" means for these "brute force"
>> thin shell calculations. an hour, a day, a week, on how may threads?
>> 
>> i agree with you that adaptive grids can help in a number
>> of situations, including maybe these particular thin shell problems.
>> there are limits though as to what adaptive grids can do. for example,
>> laminar flame fronts in nascent sn1a have widths on the order of microns, 
>> and are unlikely to be resolved in full star calculations, even those 
>> with 1d adaptive meshes. other examples where 1d adaptive grids may have 
>> limited utility include off-center neon burning in ~10 msun zams stars, 
>> edge-lit co white dwarfs, various dredge-up scenarios, or the thin shell instability. 
>> 
>> for cases that involve a subsonic propagating front, which is one way
>> of looking at the thin shell evolution, one might want to examine level-set 
>> or fat-flame technologies. both are general, fairly flexible 
>> methods of transporting a propagating front. of course, any such sub-grid models 
>> will need input that is guided by resolved microphysics calculations 
>> (e.g., how fast is the flame or thin shell propagating). such sub-grid models 
>> will also probably have to be explicitly toggled on/off by a user for 
>> specific regions at specific times in a given model.
>> 
>> just my thoughts at the moment ...
>> 
>> fxt
>> 
>> 
>> 
>> 
>> On Mar 17, 2011, at 12:26 PM, Alfred Gautschy wrote:
>> 
>>> The thin-shell evolution problem is indeed quite an old one; it is also
>>> well described together with a numerical solution to solve it in the
>>> Kippenhahn, Weigert, Hofmeister article of 1967 in "Methods in
>>> Computational Physics", vol. 7, 129 - 190. The solution that was adopted
>>> then was appropriate for the time when computers were slow and memory
>>> was small and after all it was implemented during a first expedition to
>>> the field of stellar evolution where much was terra incognita. Up to
>>> now, I assumed that the adaptive-grid approach of Eggleton & Co.
>>> actually solved the kludge solution of Schwarzschild et al. and
>>> Kippenhahn et al. and whomever it concerns too. 
>>> 
>>> As Sande correctly observes, in the frame of the thin shell, the
>>> structure of its environment stays almost stationary, this is just what
>>> the adaptive grid (properly tuned, i.e. if made sensitive to the proper
>>> physical quantities) takes advantage of to let the star evolve easily
>>> through this phase of life. Of course there is a price to pay, namely
>>> that mass advection has to be dealt with numerically. Eggleton's code
>>> applies essentially a donor-cell method (as far as I have seen); this is
>>> first order accurate and might be good enough for all quasistatic phases
>>> of evolution (I am not so sure regarding the nuclear species movement in
>>> diffusion like equations) but it might degrade inacceptably the quality
>>> of models in dynamical phases. (This was never a point for the Eggleton
>>> code, but might be one for MESA). 
>>> 
>>> Finally, the point I would like to make is: If MESA is intended to play
>>> the role in the future of a core set of numerically reliable and robust
>>> routines for 1d stellar evolution, one should refrain from adding
>>> klutches on a deep level just to get through whatever phases of
>>> evolution for whatever classes of stars. Such kludges will accumulate as
>>> there are always phases that need separate treatement. This will
>>> diminish the usefulness of such a collection of modules in the long run.
>>> I would prefer to see innovative numerical methods being implemented to
>>> get the best results for the problem at hand. After all, there is quite
>>> advanced software engineering going into the project already, why then
>>> fall back on quick-fix solutions that were invented in the 1960s to deal
>>> physical problems. After all, I think for the thin-shell problem there
>>> is a better solution already having been put forth: this is the adaptive
>>> grid. It is not unlikely that also other tricky phases of stellar
>>> evolution (whereever strong gradients occur that have to be resolved)
>>> would benefit from such a treatment.   
>>> 
>>> Actually, Bill Paxton (and possibly others in the group of MESA
>>> users/developers) should have gained some experience with the behavior
>>> of Eggleton's scheme in the thin-shell regime. 
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Colocation vs. Managed Hosting
>>> A question and answer guide to determining the best fit
>>> for your organization - today and in the future.
>>> http://p.sf.net/sfu/internap-sfd2d
>>> _______________________________________________
>>> mesa-users mailing list
>>> mes...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>> 
>> 
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> mesa-users mailing list
>> mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> -- 
> 

Re: [mesa-users] On "modus videndi with very thin shell burning"

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

The problem is not so much resolving the front. There's no particular
limit on the number of levels of refinement in an adaptive method. I'm
told some early universe simulations span thirty orders of magnitude.
The problem is the restriction on the time step that results, a common
problem with spatially adaptive time-dependent hydro methods. You have
to take a very small time step to avoid rapid changes in the variables
in the fine zones, or you might even take the burn front into a coarsely
refined zone faster than the mesh can adapt if the time step is too
small.

I haven't run a calculation with a very thin shell all the way up the
AGB. I'm not that patient. My guess, based on my attempts, is: At
*least* several days even with four threads running. Sometimes it may be
worth the brute calculation, but it seems to me that it would be
worthwhile to experiment with some kind of front propagator method.
Frank, you pointed me at some leads; I'll take a look at these but I
can't promise I'll be able to put anything useful in the code anytime
soon. (Or ever.)

On Sun, 2011-03-20 at 14:31 -0700, Frank Timmes wrote:
> hi alfred (& kent & theodore),
> 
> i'm curious what "taking forever" means for these "brute force"
> thin shell calculations. an hour, a day, a week, on how may threads?
> 
> i agree with you that adaptive grids can help in a number
> of situations, including maybe these particular thin shell problems.
> there are limits though as to what adaptive grids can do. for example,
> laminar flame fronts in nascent sn1a have widths on the order of microns, 
> and are unlikely to be resolved in full star calculations, even those 
> with 1d adaptive meshes. other examples where 1d adaptive grids may have 
> limited utility include off-center neon burning in ~10 msun zams stars, 
> edge-lit co white dwarfs, various dredge-up scenarios, or the thin shell instability. 
> 
> for cases that involve a subsonic propagating front, which is one way
> of looking at the thin shell evolution, one might want to examine level-set 
> or fat-flame technologies. both are general, fairly flexible 
> methods of transporting a propagating front. of course, any such sub-grid models 
> will need input that is guided by resolved microphysics calculations 
> (e.g., how fast is the flame or thin shell propagating). such sub-grid models 
> will also probably have to be explicitly toggled on/off by a user for 
> specific regions at specific times in a given model.
> 
> just my thoughts at the moment ...
> 
> fxt
> 
> 
> 
> 
> On Mar 17, 2011, at 12:26 PM, Alfred Gautschy wrote:
> 
> > The thin-shell evolution problem is indeed quite an old one; it is also
> > well described together with a numerical solution to solve it in the
> > Kippenhahn, Weigert, Hofmeister article of 1967 in "Methods in
> > Computational Physics", vol. 7, 129 - 190. The solution that was adopted
> > then was appropriate for the time when computers were slow and memory
> > was small and after all it was implemented during a first expedition to
> > the field of stellar evolution where much was terra incognita. Up to
> > now, I assumed that the adaptive-grid approach of Eggleton & Co.
> > actually solved the kludge solution of Schwarzschild et al. and
> > Kippenhahn et al. and whomever it concerns too. 
> > 
> > As Sande correctly observes, in the frame of the thin shell, the
> > structure of its environment stays almost stationary, this is just what
> > the adaptive grid (properly tuned, i.e. if made sensitive to the proper
> > physical quantities) takes advantage of to let the star evolve easily
> > through this phase of life. Of course there is a price to pay, namely
> > that mass advection has to be dealt with numerically. Eggleton's code
> > applies essentially a donor-cell method (as far as I have seen); this is
> > first order accurate and might be good enough for all quasistatic phases
> > of evolution (I am not so sure regarding the nuclear species movement in
> > diffusion like equations) but it might degrade inacceptably the quality
> > of models in dynamical phases. (This was never a point for the Eggleton
> > code, but might be one for MESA). 
> > 
> > Finally, the point I would like to make is: If MESA is intended to play
> > the role in the future of a core set of numerically reliable and robust
> > routines for 1d stellar evolution, one should refrain from adding
> > klutches on a deep level just to get through whatever phases of
> > evolution for whatever classes of stars. Such kludges will accumulate as
> > there are always phases that need separate treatement. This will
> > diminish the usefulness of such a collection of modules in the long run.
> > I would prefer to see innovative numerical methods being implemented to
> > get the best results for the problem at hand. After all, there is quite
> > advanced software engineering going into the project already, why then
> > fall back on quick-fix solutions that were invented in the 1960s to deal
> > physical problems. After all, I think for the thin-shell problem there
> > is a better solution already having been put forth: this is the adaptive
> > grid. It is not unlikely that also other tricky phases of stellar
> > evolution (whereever strong gradients occur that have to be resolved)
> > would benefit from such a treatment.   
> > 
> > Actually, Bill Paxton (and possibly others in the group of MESA
> > users/developers) should have gained some experience with the behavior
> > of Eggleton's scheme in the thin-shell regime. 
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > mesa-users mailing list
> > mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
> 
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
-- 

Re: [mesa-users] mesa takes a mulligan -- new version is now 3107

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

MESA++ version 92 has now been released. This is a co-release with MESA
version 3107. The new MESA++ release features improved support for
inheritance of the Star class, plus a template (MyStar) illustrating
these features.

--Kent G. Budge
CCS-2, LANL

Re: [mesa-users] mesa takes a mulligan -- new version is now 3107

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

Also builds and runs on an 8-processor 64-bit 686 Linux box.

On Mon, 2011-03-21 at 10:34 -0600, Kent Budge wrote:
> Seems to work for me on a two-processor 686 Linux box. 
> 
> On Sun, 2011-03-20 at 11:17 -0700, Bill Paxton wrote:
> > thanks to Chris Richardson for quickly finding this one.
> > let's try version 3107 and see show that works!  ; )
> > 
> > -B
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > mesa-users mailing list
> > mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
-- 

Re: [mesa-users] mesa takes a mulligan -- new version is now 3107

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

Seems to work for me on a two-processor 686 Linux box. 

On Sun, 2011-03-20 at 11:17 -0700, Bill Paxton wrote:
> thanks to Chris Richardson for quickly finding this one.
> let's try version 3107 and see show that works!  ; )
> 
> -B
> 
> 
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
-- 

Re: [mesa-users] On "modus videndi with very thin shell burning"

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

hi alfred (& kent & theodore),

i'm curious what "taking forever" means for these "brute force"
thin shell calculations. an hour, a day, a week, on how may threads?

i agree with you that adaptive grids can help in a number
of situations, including maybe these particular thin shell problems.
there are limits though as to what adaptive grids can do. for example,
laminar flame fronts in nascent sn1a have widths on the order of microns, 
and are unlikely to be resolved in full star calculations, even those 
with 1d adaptive meshes. other examples where 1d adaptive grids may have 
limited utility include off-center neon burning in ~10 msun zams stars, 
edge-lit co white dwarfs, various dredge-up scenarios, or the thin shell instability. 

for cases that involve a subsonic propagating front, which is one way
of looking at the thin shell evolution, one might want to examine level-set 
or fat-flame technologies. both are general, fairly flexible 
methods of transporting a propagating front. of course, any such sub-grid models 
will need input that is guided by resolved microphysics calculations 
(e.g., how fast is the flame or thin shell propagating). such sub-grid models 
will also probably have to be explicitly toggled on/off by a user for 
specific regions at specific times in a given model.

just my thoughts at the moment ...

fxt




On Mar 17, 2011, at 12:26 PM, Alfred Gautschy wrote:

> The thin-shell evolution problem is indeed quite an old one; it is also
> well described together with a numerical solution to solve it in the
> Kippenhahn, Weigert, Hofmeister article of 1967 in "Methods in
> Computational Physics", vol. 7, 129 - 190. The solution that was adopted
> then was appropriate for the time when computers were slow and memory
> was small and after all it was implemented during a first expedition to
> the field of stellar evolution where much was terra incognita. Up to
> now, I assumed that the adaptive-grid approach of Eggleton & Co.
> actually solved the kludge solution of Schwarzschild et al. and
> Kippenhahn et al. and whomever it concerns too. 
> 
> As Sande correctly observes, in the frame of the thin shell, the
> structure of its environment stays almost stationary, this is just what
> the adaptive grid (properly tuned, i.e. if made sensitive to the proper
> physical quantities) takes advantage of to let the star evolve easily
> through this phase of life. Of course there is a price to pay, namely
> that mass advection has to be dealt with numerically. Eggleton's code
> applies essentially a donor-cell method (as far as I have seen); this is
> first order accurate and might be good enough for all quasistatic phases
> of evolution (I am not so sure regarding the nuclear species movement in
> diffusion like equations) but it might degrade inacceptably the quality
> of models in dynamical phases. (This was never a point for the Eggleton
> code, but might be one for MESA). 
> 
> Finally, the point I would like to make is: If MESA is intended to play
> the role in the future of a core set of numerically reliable and robust
> routines for 1d stellar evolution, one should refrain from adding
> klutches on a deep level just to get through whatever phases of
> evolution for whatever classes of stars. Such kludges will accumulate as
> there are always phases that need separate treatement. This will
> diminish the usefulness of such a collection of modules in the long run.
> I would prefer to see innovative numerical methods being implemented to
> get the best results for the problem at hand. After all, there is quite
> advanced software engineering going into the project already, why then
> fall back on quick-fix solutions that were invented in the 1960s to deal
> physical problems. After all, I think for the thin-shell problem there
> is a better solution already having been put forth: this is the adaptive
> grid. It is not unlikely that also other tricky phases of stellar
> evolution (whereever strong gradients occur that have to be resolved)
> would benefit from such a treatment.   
> 
> Actually, Bill Paxton (and possibly others in the group of MESA
> users/developers) should have gained some experience with the behavior
> of Eggleton's scheme in the thin-shell regime. 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] mesa takes a mulligan -- new version is now 3107

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

thanks to Chris Richardson for quickly finding this one.
let's try version 3107 and see show that works!  ; )

-B

[mesa-users] On "modus videndi with very thin shell burning"

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

The thin-shell evolution problem is indeed quite an old one; it is also
well described together with a numerical solution to solve it in the
Kippenhahn, Weigert, Hofmeister article of 1967 in "Methods in
Computational Physics", vol. 7, 129 - 190. The solution that was adopted
then was appropriate for the time when computers were slow and memory
was small and after all it was implemented during a first expedition to
the field of stellar evolution where much was terra incognita. Up to
now, I assumed that the adaptive-grid approach of Eggleton & Co.
actually solved the kludge solution of Schwarzschild et al. and
Kippenhahn et al. and whomever it concerns too. 

As Sande correctly observes, in the frame of the thin shell, the
structure of its environment stays almost stationary, this is just what
the adaptive grid (properly tuned, i.e. if made sensitive to the proper
physical quantities) takes advantage of to let the star evolve easily
through this phase of life. Of course there is a price to pay, namely
that mass advection has to be dealt with numerically. Eggleton's code
applies essentially a donor-cell method (as far as I have seen); this is
first order accurate and might be good enough for all quasistatic phases
of evolution (I am not so sure regarding the nuclear species movement in
diffusion like equations) but it might degrade inacceptably the quality
of models in dynamical phases. (This was never a point for the Eggleton
code, but might be one for MESA). 

Finally, the point I would like to make is: If MESA is intended to play
the role in the future of a core set of numerically reliable and robust
routines for 1d stellar evolution, one should refrain from adding
klutches on a deep level just to get through whatever phases of
evolution for whatever classes of stars. Such kludges will accumulate as
there are always phases that need separate treatement. This will
diminish the usefulness of such a collection of modules in the long run.
I would prefer to see innovative numerical methods being implemented to
get the best results for the problem at hand. After all, there is quite
advanced software engineering going into the project already, why then
fall back on quick-fix solutions that were invented in the 1960s to deal
physical problems. After all, I think for the thin-shell problem there
is a better solution already having been put forth: this is the adaptive
grid. It is not unlikely that also other tricky phases of stellar
evolution (whereever strong gradients occur that have to be resolved)
would benefit from such a treatment.   

Actually, Bill Paxton (and possibly others in the group of MESA
users/developers) should have gained some experience with the behavior
of Eggleton's scheme in the thin-shell regime. 

Re: [mesa-users] modus videndi with very thin shell burning

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

Hi,

First, let's eliminate the gfortran+4 GB ram problem -- if you are using gfortran on a machine with 4 GB ram, then the performance of star can fall off a cliff and get worse by factor of 10 or more.  If that might be happening, you should try running on a machine with at least 8 GB or get a free trial of ifort (it doesn't seem to have any problems with 4 GB).

If that's not the problem, please give me a bit more background.  How long is it taking for a Z=0.0, M=1Msun run to get to helium ignition -- 1 hour, 2 hours, ... ?    What target runtime must you reach in order to do your desired project?   How much difference between fast-approximate vs. slow-precise solutions are you willing to tolerate?  1%?  5%?

Alternatively, are you more interested in algorithm development than in the astrophysics of the RGB tip?  (I can relate to that!)   In other words, is your primary goal to develop a better algorithm for climbing the rgb, or is it to find any way to get RGB tip models fast enough and with a small enough error to allow you to do the science?   Are you open to considering less elegant solutions that would avoid doing substantial code development?

Cheers,
Bill







On Mar 15, 2011, at 5:30 PM, Theodore Arthur Sande wrote:

> dear mesa-users:
> 
> The entrainment of the henyey algorithm to progressively smaller time steps
> is a general consequence of the accentuation of shell thinness in low mass stars
> ascending the RGB, worsening inversely with mass and metallicity. Sub-stellar
> mass Pop. III stars thus exhibit the worst manifestation of this problem.
> 
> However, in the star's quiescent climb up the RGB, you should graphically
> observe that, in the expanding shell front's frame of reference, the shell's
> profile appears almost structurally static. One physically sound resolution is
> to artificially propagate, or shift, the composition profile's outward using a
> larger time-step, interspersing this with smaller henyey chosen time steps.
> 
> Harm and Scwarzschild adumbrated this "shell shifting" method during the late
> dark age of stellar modeling ( see sec. (d) the hydrogen burning shell,
> attached .pdf for RED GIANTS OF POPULATION II. IV )
> 
> Perhaps a more sophisticated version with an attendant "error" control could be
> incorporated into MESA. I would be interested to assist on this, especially on
> ascertaining the divergence between the brute force evolution and that
> incorporating a subset of shell shifting steps expediting the RGB ascent. My
> intuition is that, with the exception of detailed calculations of precise core
> mass and luminosity at the RGB tip, the error introduced via a judicious
> admixture of shifting steps could be negligible. I could be wrong, but, if not,
> the computational burden could be substantially alleviated, esp. if a large
> array of runs are required.
> 
> Theodore Arthur Sande
> 
> MIT Department of Physics
> ta...@mi...<1966ApJ...145..496H.pdf>------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

Re: [mesa-users] PGstar help

[Duligur I. <du...@gm...>]

Yes, it works on revision 3075.

Thanks,
Duligur

On Tue, Mar 15, 2011 at 6:27 PM, Bill Paxton <pa...@ki...> wrote:

> Hi,
>
> Are you using the current release version?  I believe I recently fixed the
> problem you report -- and it works when I try it on my machine just now.
>
> -Bill
>
>
>
>
> On Mar 15, 2011, at 3:54 PM, Duligur Ibeling wrote:
>
> > Hello,
> >
> > I am having some trouble with the PGstar window.  I would like to disable
> it but still run PGstar, just output PNG files.  So I have set in the inlist
> file:
> >
> > &pgstar
> > ...
> > MAIN_win_flag = .false.
> > ...
> > MAIN_file_flag = .true.
> > ...
> > /
> >
> > Yet, the window still opens, although files are now output.  I have been
> going through various files and nothing seems to fix it.
> >
> > Thanks,
> > Duligur
> >
> ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> >
> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> > mesa-users mailing list
> > mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

Re: [mesa-users] Issue running the opacity preprocessor

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

Hi Nathan,

I've tried to run the preprocessor under version 3075 and it seems to work
fine.  What is your version number?

If you still have trouble, you can forcibly disable use of the Freedman
opacity data by setting low_T_table = .false. in kap_support.f.  Currently,
I see it is defined by:

         low_T_table = ( &
               (.not. co_enhanced) .and. &
               abs(Zbase - 0.02) < 1d-6 .and. &
               0.69 < X .and. X < 0.81)

You can replace that logic statement with a simple .false. and it should
work.  We need to make this transparent in the inlist and I hope that will
make it into the next release.

Aaron


On Wed, Mar 16, 2011 at 4:04 AM, Nathan Thompson <nlt...@wi...>wrote:

> I am attempting to use the opacity preprocessor and it successfully
> complies (I use gfortran 4.5). During the run, however, I receive the
> following error when attempting to run the ./rn_all script
>
>
> creating data/kap_data/gn93_z2m2_x50.data
>
>  creating data/kap_data/gn93_z2m2_x70.data
>  init_freedman: read kap_input_data/freedman.data
>  init_freedman failed to open kap_input_data/freedman.data
> STOP 1
>
> I tried to comment out the relevant lines in the inlist files, but the
> error still occurs. I checked, and the file kap_input_data/freedman.data
> does not appear to exist. I'm using the opacity preprocessor to generate
> modified opacity tables, but I can't get the ones supplied with MESA to
> rebuild at present.
>
> Your help is resolving this issue is greatly appreciated.
>
> Thanks,
> Nathan
>
> Wichita State University
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>

[mesa-users] Issue running the opacity preprocessor

[Nathan T. <nlt...@wi...>]

I am attempting to use the opacity preprocessor and it successfully complies
(I use gfortran 4.5). During the run, however, I receive the following error
when attempting to run the ./rn_all script


creating data/kap_data/gn93_z2m2_x50.data

 creating data/kap_data/gn93_z2m2_x70.data
 init_freedman: read kap_input_data/freedman.data
 init_freedman failed to open kap_input_data/freedman.data
STOP 1

I tried to comment out the relevant lines in the inlist files, but the error
still occurs. I checked, and the file kap_input_data/freedman.data does not
appear to exist. I'm using the opacity preprocessor to generate modified
opacity tables, but I can't get the ones supplied with MESA to rebuild at
present.

Your help is resolving this issue is greatly appreciated.

Thanks,
Nathan

Wichita State University

[mesa-users] (no subject)

[Theodore A. S. <ta...@MI...>]

P.S. I meant "modus vivendi". Mea culpa!

Theodore Arthur Sande

MIT Department of Physics
ta...@mi...

[mesa-users] modus videndi with very thin shell burning

[Theodore A. S. <ta...@MI...>]

dear mesa-users:

The entrainment of the henyey algorithm to progressively smaller time steps
is a general consequence of the accentuation of shell thinness in low mass stars
ascending the RGB, worsening inversely with mass and metallicity. Sub-stellar
mass Pop. III stars thus exhibit the worst manifestation of this problem.

However, in the star's quiescent climb up the RGB, you should graphically
observe that, in the expanding shell front's frame of reference, the shell's
profile appears almost structurally static. One physically sound resolution is
to artificially propagate, or shift, the composition profile's outward using a
larger time-step, interspersing this with smaller henyey chosen time steps.

Harm and Scwarzschild adumbrated this "shell shifting" method during the late
dark age of stellar modeling ( see sec. (d) the hydrogen burning shell,
attached .pdf for RED GIANTS OF POPULATION II. IV )

Perhaps a more sophisticated version with an attendant "error" control could be
incorporated into MESA. I would be interested to assist on this, especially on
ascertaining the divergence between the brute force evolution and that
incorporating a subset of shell shifting steps expediting the RGB ascent. My
intuition is that, with the exception of detailed calculations of precise core
mass and luminosity at the RGB tip, the error introduced via a judicious
admixture of shifting steps could be negligible. I could be wrong, but, if not,
the computational burden could be substantially alleviated, esp. if a large
array of runs are required.

Theodore Arthur Sande

MIT Department of Physics
ta...@mi...

Re: [mesa-users] PGstar help

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

Hi,

Are you using the current release version?  I believe I recently fixed the problem you report -- and it works when I try it on my machine just now.

-Bill




On Mar 15, 2011, at 3:54 PM, Duligur Ibeling wrote:

> Hello,
> 
> I am having some trouble with the PGstar window.  I would like to disable it but still run PGstar, just output PNG files.  So I have set in the inlist file:
> 
> &pgstar
> ...
> MAIN_win_flag = .false.
> ...
> MAIN_file_flag = .true.
> ...
> /
> 
> Yet, the window still opens, although files are now output.  I have been going through various files and nothing seems to fix it.
> 
> Thanks,
> Duligur
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d_______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users

[mesa-users] PGstar help

[Duligur I. <du...@gm...>]

Hello,

I am having some trouble with the PGstar window.  I would like to disable it
but still run PGstar, just output PNG files.  So I have set in the inlist
file:

&pgstar
...
MAIN_win_flag = .false.
...
MAIN_file_flag = .true.
...
/

Yet, the window still opens, although files are now output.  I have been
going through various files and nothing seems to fix it.

Thanks,
Duligur

Re: [mesa-users] Load model

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

Hi Shih-Hsin,

Please provide a bit more information so that we can help you diagnose your
problem.

1. the inlist

2. the saved model

3. MESA version number


Aaron




On Tue, Mar 15, 2011 at 5:38 AM, 張世昕 <ss...@as...> wrote:

> Dear mesa-users,
>
> I have problem about loading the saved model.
>
> It shows that,
> "finish_load_model: failed in set_vars
>  failed in finish_load_model
>  star_read_model ierr          -1
> WARNING: allocate failed for eos tables
>  do_load1_star ierr          -1
> WARNING: allocate failed for eos tables"
>
> I did nothing but edit the inlist file. (without touching the eos stuff)
> Once the wrong message show up, mesa can't load
> any saved model any more.
> How do I fix it?
>
> Cheers,
> Shih-Hsin
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> mesa-users mailing list
> mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>