[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