From: Bill P. <pa...@ki...> - 2011-03-16 16:37:02
|
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 |