mesa-users] Manual Change of Accretion Composition

Fri Jul 2 14:30:13 EDT 2010

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 <katzm3 at rpi.edu> 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 <paxton at kitp.ucsb.edu> 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
> > mesa-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mesa-users
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20100702/b75f5e27/attachment.html>