KAPIL2024 and circularisation at RLOF/CE #1382
Replies: 3 comments
-
Hi @AldanaGrichener , First of all, thank you very much for exploring this! I am pinging @veome22 , who is in the process of writing a couple of papers, in which the KAPIL2024 tides model will be explained and investigated in more detail. As you say, self-consistently handling CEs from eccentric binaries is a challenge. At least in the energy (alpha-lambda) formalism, it may not make too much difference to the outcome, since the initial orbital energy is almost irrelevant if the binary is to be hardened by orders of magnitude (to a good approximation, for alpha=1, the post-CE orbital energy is just the negative of the envelope binding energy). Physically, it may make a difference because, if the orbit isn't circularised, the donor is also not synchronised, so there's no co-rotation from the start, and hence there's presumably an immediate dynamical plunge-in, without a preceding thermal timescale mass transfer phase. 3d hydro simulations, such as @themikelau 's models, have played around with the impact of initial conditions, but I don't think we know the answer yet. Hence the choice to circularise at CE onset, for simplicity (and also because, presumably, hydro drag at periapsis will in fact rapidly circularise the orbit there). The "circularise during MT" flag was intended to deal with classical stable MT -- and our models for what happens when that's not circularised are very arbitrary (see work by Sepinsky+, Dosopoulou+). I'll leave the super-synchronous spin-up point to @veome22 -- but I agree that more work is required on choosing timesteps efficiently... |
Beta Was this translation helpful? Give feedback.
-
Hi @AldanaGrichener , Thank you for bringing up these points. I actually have wondered about the pre-CE circularization behavior myself, but I see @ilyamandel's point that we do not understand CEs well enough to make more nuanced decisions. As for your points on the KAPIL2024 tides prescription:
I should note that this is separate from the issue solved in PR #1318. Even if the pseudo-synchronized rotational velocity should be higher than what we assume, the maximum spin should still be set by some mode of synchronization between the orbit and the stellar rotation. However, for very large eccentricities, non-quadrupolar non-circular modes start dominating the orbital evolution equations (see equations 3.6, 3.7. 3.8 of Zahn 1977) and drive the binary to super-synchronous rotation. My understanding is that these terms are not meant to be used with very high eccentricities, or at least need additional higher order terms to become valid in this regime. So regardless of whether we assume pseudo-synchronization, we probably ought not to drive the binary past synchronization.
|
Beta Was this translation helpful? Give feedback.
-
Thank you very much for your detailed answers! Sorry for the delay in my reply (I was at a conference last week). @ilyamandel It makes a lot of sense that for CEs that end up as double compact objects the initial orbital energy ends up being negligible (though in other CE systems the binding energy does not dominate the initial orbital energy quite as much). What confused me is thinking about the final orbital separation as proportional to the initial orbital separation (since at RLOF R_star = R_RL \propto a), but as the circularisation of the orbit in COMPAS occurs after RLOF has been triggered, this argument doesn't apply. @veome22 Running with --maximum-number-timestep-iterations 1999999 --mass-change-fraction 0.001 --radial-change-fraction 0.001 indeed mostly solves the “Allowed timesteps exceeded” problem (only 8 out of 1000 systems), but at a heavy computational cost: the runtime was ~3400 seconds, compared to the original ~20. Regarding super-synchronization/PR #1318, I don’t have a good understanding of the epsilon terms in Zahn’s Eq. 3.6-3.8, but in the simplified version Eq. 4.3-4.5, it seems that super-synchronous rotation is sort of built into the equations: the rotation equation (4.5) reaches steady-state fastest, and for any finite eccentricity, that steady-state is super-synchronous (on longer timescales it decays to regular synchronization as the orbit circularises). Details of the equations aside, intuitively I would think super-synchronous rotation is to be expected in an eccentric system: tidal forces depend on a high power of the distance between the bodies, so in an eccentric system, the time the bodies spend closer to each other more than makes up for the time they spend farther apart. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I’m currently working on a project where I’m especially interested in stars’ spin, so I am excited to see that COMPAS now includes a realistic tides mode! Having tried it out, I have some questions and comments, mostly about KAPIL2024 but also about circularisation at RLOF and CE.
Results from a small-scale experiment with KAPIL2024
Given the KAPIL2024's computational costs (see below), I ran a large number of systems with no tides, then reran the seeds which ended up as DCOs (that’s how I ran into issue #1378) with KAPIL2024 and also with --circularise-binary-during-mass-transfer FALSE, since I assumed realistic tides should replace it (see below). Since tides can in principle expand the orbit this procedure might result in undercounting DCOs, but that should be fairly rare.
Out of 66 DCO seeds, I found 10 where the tides had a non-negligible affect on the orbital evolution up to CE, in 6 of these the orbit was completely circularized, in 2 of these the binary ended up unbound. In 2 systems the tides expanded the orbit, in 1 of these they also increased the eccentricity.
Circularisation at RLOF and CE
I originally thought that combining KAPIL2024 with --circularise-binary-during-mass-transfer FALSE should have a big effect on CE outcomes, since not all systems will be circularised by tides and those that don’t will have significantly different orbital parameters at the onset of CE, and therefore also after the energy formalism is applied. What I didn’t realize is that COMPAS “assumes immediate circularisation at periastron at start of CE” (quote from BaseBinaryStar::ResolveCommonEnvelopeEvent) regardless of whether and how the orbit was circularised at RLOF (*). I have a few questions/comments in this context:
What is the motivation behind the decision to circularise the orbit at CE onset, thus leaving part of the pre-CE orbital energy out of the energy formalism equation? I would think that this part of the orbital energy is deposited in the envelope just like the rest of it.
I found the current situation regarding circularisation somewhat counterintuitive: turning off circularisation at RLOF doesn’t affect CE outcomes (**) since the orbit is circularised in the same way at CE anyway, while keeping circularisation at RLOF on but making it conserve angular momentum does affect CE, since the semimajor axis is set to a(1-e^2) at RLOF rather than the a(1-e) it would’ve been set to at CE.
To what extent is KAPIL2024 meant to replace circularisation at RLOF? Vigna Gomez 2018 presents circularisation at RLOF “e.g. as a consequence of tidal dissipation prior to mass transfer or during the episode”. The former, at least, is taken care of by KAPIL2024.
(*) Incidentally, I’d like to say that I really appreciate the change which makes every line in detailed output correspond to a single “event”, it made figuring out what was going on much easier.
(**) This ignores systems which were already eccentric before undergoing stable mass transfer. I guess this mostly applies to systems which are created eccentric at ZAMS?
Pseudo-synchronisation
Based on my small-scale experiment, I got the impression that KAPIL2024 doesn’t allow for pseudo-synchronisation, i.e. tides in an eccentric system spinning up a star past what the synchronised angular velocity would’ve been in a circular system with the same semimajor axis. Later I saw the changelog mentions explicitly disallowing this, and found PR #1318. I have been assuming pseudo-synchronisation takes place for the purposes of my project, following Hut 1981 which argues it could be a consequence of the tides being extra strong at periastron. I'll admit I haven't read either Zahn 1977 or Hut 1981 that carefully, so I would appreciate your insight on this.
Computational costs
Running a large number of random systems with KAPLI2024 requires significant additional computational resources. E.g. running ./COMPAS --mode BSE --n 1000 took ~20 seconds on my laptop while ./COMPAS --mode BSE --n 1000 --tides-prescription KAPIL2024 took ~800 seconds.
Relatedly, the COMPAS default for --maximum-number-timestep-iterations seems somewhat incompatible with KAPIL2024: of the 1000 systems, 101 ended up as “Allowed timesteps exceeded” (while none did so in the base run). Maybe it would be good to increase this default when KAPIL2024 is on.
On the other hand this makes it tricky to use --detailed-output with KAPIL2024: I’ve gotten 1GB individual BSE_Detailed_Output files in “Allowed timesteps exceeded” systems even with the current default.
I saw that PR #1353 limited the timestep size to avoid large changes in the orbital parameters, is there room for flexibility there?
Beta Was this translation helpful? Give feedback.
All reactions