[mesa-users] restarting mesa binary and donor/accretor switching

Pablo Marchant pamarca at gmail.com
Thu Sep 17 15:43:08 EDT 2015


I don't see why it wouldnt work if you copy the relevant parts of the
set_donor_star subroutine into extras_finish_step, with your own criteria
to swap the donor.

write(*,*) "switching donor"

if (b% d_i == 2) then

b% d_i = 1

b% a_i = 2

b% s_donor => b% s1

b% s_accretor => b% s2

else

b% d_i = 2

b% a_i = 1

b% s_donor => b% s2

b% s_accretor => b% s1

end if
Am 17.09.2015 10:37 nachm. schrieb "Sterl Phinney" <esp at tapir.caltech.edu>:

> Dear Pablo,
>         Thanks, indeed the saved models of course didn't have matching
> model numbers.  I can rename the photos to match as you suggest to restart.
>         I've been using mdot_scheme = "Ritter" rather than "roche_lobe".
> You are indeed right that the subroutine set_donor_star seems currently set
> only to operate if mdot_scheme == "roche_lobe" (or "contact"). I can try to
> see if I can continue the evolution for a few steps with roche_lobe and
> then restart with "Ritter", but it would be great if the switch also worked
> with the other more physical schemes.
>         Is there some more elegant work-around to allow a former accretor
> to become a donor than the above? I gather the binary's orbit data is
> stored with star 1. Is this always assumed to be the donor?  And if so, is
> there some way to swap stars 1 and 2 by hand as an alternative?
>         Cheers, Sterl
>
> On Thu, 17 Sep 2015, Pablo Marchant wrote:
>
>
>> Hi Sterl. MESAbinary effectively assumes the photos are synchronized, and
>> actually overrides the photostep control of the stars so they have the
>> same
>> value. I have seen this behaviour when starting with saved models that
>> dont
>> have matching model numbers. This can be sorted out by fixing the initial
>> model numbers at the beginning of the run. I guess something of this sort
>> has to be your issue, as the model numbers are different at the end of
>> your
>> run.
>>
>> Right now I'm only with my smartphone so its a bit complicated to actually
>> check your files. in ~2 weeks I could give them a good look. In the
>> meantime
>> you could just rename the photos to have the same number, and restart
>> using
>> that number.
>>
>> I think the donor switching was only setted up to work with the roche_lobe
>> scheme for mass transfer (you can check it on the subroutine
>> set_donor_star
>> in binary_evolve, just ignore the stuff about "contact" which is something
>> experimental I have in there). I did not experiment to much with these
>> options, so right now I cant remember the reason for that limitation. But
>> we
>> can certainly adjust it for your needs.
>>
>> Cheers!
>>
>> Am 17.09.2015 6:50 nachm. schrieb "Sterl Phinney" <esp at tapir.caltech.edu
>> >:
>>       Dear Pablo, Bill et al,
>>               Following on from my MESA summer school lectures, I have
>>       been experimenting with further with MESA binary and
>>       evolve_both_stars = .true.
>>               I am using mesa-7624 (current release). The inlists and
>>       input saved models in the attached Algol.zip file sort-of
>>       succesfully make Algol (the final exercise of my Lecture 2).
>>       But I decided to run the evolution further, and have encountered
>>       two mysteries.
>>
>>       1. The model numbers in photos1/ and photos2/ are not
>>       synchronized,
>>       while restarts seem to assume that they are, and thus don't work
>>       properly.
>>       Details of mystery 1:
>>        During a run, log output and timestamps confirm that
>>       photos1/x750
>>       photos2/x700
>>       are a pair associated with a single evolutionary time,
>>       and the run terminates also writing unequal photo numbers for
>>       star
>>       1 and star 2:
>>       ---
>>       save LOGS1/profile20.data for model 1790
>>       save photos1/x790 for model 1790
>>       save LOGS2/profile23.data for model 1743
>>       save photos2/x743 for model 1743
>>       termination code: Terminate because accretor (r-rl)/rl >
>>       accretor_overflow_terminate
>>       ---
>>
>>       But when I restart, there are weird jumps in the star mass
>>       suggesting
>>       that non-matched photos are being used to restart star 1 and
>>       star 2.
>>       Looking into run_binary_support.f90
>>       I see lines
>>              doing_restart = (ierr == 0)
>>              if (doing_restart) then
>>                  read(iounit,'(a)', iostat=ierr) photo_filename ! same
>>       for both stars
>>
>>       which suggests to me that MESA is in fact assuming the right
>>       thing to do is to use the same photo for both stars, and I don't
>>       see a way to input
>>       the correct, non-matching photonumbers for the two stars.  What
>>       am I
>>       missing here?
>>
>>       2. When MESA terminates the evolution of Algol (see final log
>>       output in mystery 1 above: "Terminate because accretor (r-rl)/rl
>>       > accretor_overflow_terminate"), star 1 (the first donor, and
>>       initially more massive star) has become a hot white dwarf,
>>       accretion has long ago ceased, and star 2 has just filled its
>>       Roche lobe for the first time and ought to become the new donor
>>       to star 1.
>>
>>       In my inlist, I set
>>       keep_donor_fixed = .false.
>>       which I'd thought would allow the former accretor (star 2) to be
>>       relabelled as the donor, and permit evolution to continue with
>>       accretion from star 2 onto star 1.
>>       But since the termination code is stopping with
>>       "Terminate because accretor (r-rl)/rl >
>>       accretor_overflow_terminate"
>>       clearly that relabelling isn't happening.
>>
>>       I see that I could also set "accretor_overflow_terminate" =
>>       [something >0]
>>       which might allow evolution to continue, but this isn't a case
>>       of both stars filling their Roche lobes, but of a desired switch
>>       of
>>       accretor to a donor. How do I make that happen?
>>       (I'd experiment more myself if I didn't have to run for an hour
>>       to get to this stage: see mystery 1!).
>>
>>       Thanks, Sterl
>>
>>       --
>>       E. Sterl Phinney
>>       Professor of Theoretical Astrophysics &
>>       Executive Officer for Astronomy and Astrophysics
>>       California Institute of Technology, 350-17
>>       Pasadena CA 91125 USA
>>
>>       [on sabbatical until 18 March 2016 as
>>        Radboud Excellence Initiative Professor
>>        Department of Astrophysics
>>        Radboud University
>>        P.O. Box 9010,
>>        6500 GL Nijmegen, The Netherlands]
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20150917/abb1b6ba/attachment.html>


More information about the Mesa-users mailing list