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

[Pablo Marchant]

and also, the binary info is stored independently, there is a type for that

type (binary_info), pointer :: b

the pointer can be assigned using the binary_id integer which is part of
star_info

call binary_ptr(s% binary_id, b, ierr)

in a binary system modelling two stars, both have the same binary_id.
Orbital parameters are stored in this binary_info type, so you can access
things like b% separation. So the switch just requires swapping the
pointers to the stars, plus some indexes that are used to acces either
donor or accretor properties, so the few lines of code I sent before are
all you need to perform a swap.
Am 17.09.2015 10:43 nachm. schrieb "Pablo Marchant" <pamarca at gmail.com>:

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