mesa-users] Manual Change of Accretion Composition

[Max Katz]

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/a9123864/attachment.html>