From: Bill P. <pa...@ki...> - 2010-07-02 18:30:20
|
Hi Max, Please try a different WD --- one that already has some H/He on the surface. Most of the ones in data/star_data/white_dwarf_models have some. I artificially removed the outer H/He for the 1.000 Msun WD's, and that might be the source of the problem you are seeing. -B On Jul 2, 2010, at 11:23 AM, Max Katz wrote: > Bill, > > After playing around some more I realized a critical flaw - I did not change one of the other necessary parameters, mass_change_full_off_dt - this parameter gives the number of seconds below which mass change is automatically turned off. Since it is initially set at 1d3, the code was just going to a lower time-step where the mass change would be turned off. To combat this, I decreased this to a very small number (like 1e-7) and also changed min_timestep_limit to 1e-10 (the latter is also measured in seconds). However, the code just kept on changing to a smaller time-step, low enough that it could evade mass addition (at one point it was around 10^-13 years). > > I also tried starting with accretion composition the same as the surface, then after it was satisfied with the accretion, dropping the accretion rate to a lower number and manually changing the composition. This, unfortunately did not work either - as soon as I changed the composition, it went to very low time-steps where mass change was zero. I'm open to other suggestions if anyone has ideas on how to relax the mass change in. > > I also wanted to see if I could relax in the composition change - so I set the following in the controls inlist - the idea was to accrete something of similar, but not the same, composition, and then gradually increase the H/He and decrease the C/O. However, when I do this the code returns an error and crashes (*** glibc detected *** ./star: free(): invalid pointer: 0x00007fdfcc000d50 ***). > > accretion_h1 = 0.01 ! mass fraction > accretion_h2 = 0. > accretion_he3 = 0. > accretion_he4 = 0.01 > accretion_zfracs = 0 > > z_fraction_li = 0. > z_fraction_be = 0. > z_fraction_b = 0. > z_fraction_c = 0.63 > z_fraction_n = 0. > z_fraction_o = 0.37 > z_fraction_f = 0. > z_fraction_ne = 0. > z_fraction_na = 0. > z_fraction_mg = 0. > z_fraction_al = 0. > z_fraction_si = 0. > z_fraction_p = 0. > z_fraction_s = 0. > z_fraction_cl = 0. > z_fraction_ar = 0. > z_fraction_k = 0. > z_fraction_ca = 0. > z_fraction_sc = 0. > z_fraction_ti = 0. > z_fraction_v = 0. > z_fraction_cr = 0. > z_fraction_mn = 0. > z_fraction_fe = 0. > z_fraction_co = 0. > z_fraction_ni = 0. > z_fraction_cu = 0. > z_fraction_zn = 0. > > Max Katz > Rensselaer Polytechnic Institute > Physics, Class of 2011 > > > On Fri, Jul 2, 2010 at 1:06 PM, Max Katz <ka...@rp...> wrote: > Bill, > > The simulation works just fine without accretion, and mass change without manual composition change works fine - it just accretes C and O (I noticed that after a while something started happening where the timestep got really small, but I didn't wait around long enough to see what happened). > > I tried your suggestion, both at your suggested settings and even smaller ones, and the same result occurred. I set max_backups_in_a_row to 50, and I noticed that after a number of retries, it eventually gives up on mass change and continues without it (lg Mdot is -99 on the pgplot screen); I even stopped it, increased the mass_change rate and restarted, and it continued on with zero mass change, without any backups or retries. > > - Max > > > On Fri, Jul 2, 2010 at 12:08 PM, Bill Paxton <pa...@ki...> wrote: > > > Hi Max, > > The change in accretion composition should be fine. Perhaps the problem is the abrupt start of accretion at the 5d-9 rate. > > Let's separate the 2. What happens if you do the 5d-9 mass change without changing the accretion composition? > > Also, you should try manually turning up the accretion rate while keeping the timestep small. > > Try something like max_years_for_timestep = 1d-7 to start with, and mass_change = 1d-12 -- or whatever it > takes to get things to converge. (BTW: I'm assuming that everything works without accretion turned on, right?) > Let things run for a while until it is happy (i.e., running at max allowed timestep). Then start increasing the > mass_change -- at each increment, let it run until it is happy, then increase again. Once you reach the > desired accretion rate, remove the limit on max_years_for_timestep. > > This is a crude manual version of what the various "relax" operations do. And if you feel ambitious, you can > write your own relax routine to do "relax_to_mass_change". > > Let me know how it goes. > > -Bill > > > > > > On Jul 2, 2010, at 6:46 AM, Max Katz wrote: > > > Hello, > > > > In an attempt to create my own nova, I used the model 1.000_Tc_3e7.mod in mesa/data/star_data/white_dwarf_models. This is a pure C/O white dwarf of 1 solar mass. The goal is to get it to go nova, so I set an accretion rate of 5 x 10^-9 (units are solar masses per year). However, the default behavior for accretion is to use the same composition for the accreted matter as there is on the surface. Since adding C and O to the surface wouldn't yield the nova I was looking for, I set the following in the controls namelist: > > > > mass_change = 5d-9 > > accrete_same_as_surface = .false. > > accretion_h1 = 0.75 > > accretion_h2 = 0. > > accretion_he3 = 0. > > accretion_he4 = 0.25 > > > > However, when I try to run with these settings on, the run cites "adjust_mass_failed", and crashes after hitting the default max number of backups (15). I tried the same settings on a different case and got the same error. If anyone has experience with changing the accretion composition, I would appreciate it if you could give some insight as to what I might be doing wrong. Thanks. > > > > Max Katz > > Rensselaer Polytechnic Institute > > Physics, Class of 2011 > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Sprint > > What will you do first with EVO, the first 4G phone? > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________ > > mesa-users mailing list > > mes...@li... > > https://lists.sourceforge.net/lists/listinfo/mesa-users > > > |