Menu
▾
▴
Re: [mesa-users] On "modus videndi with very thin shell burning"
|
From: Bill P. <pa...@ki...> - 2011-03-22 20:34:49
|
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 > > > > > |
