[Mesa-users] Angular momentum change due to tides in binaries

Mon Apr 3 08:12:01 UTC 2023

Dear Ebraheem,

Thank you, it is much clearer now. And thank you for opening the issue 
on github regarding the documentation.
Best,

Ruggero

On 3/31/23 23:47, Ebraheem Farag wrote:
> Hello Ruggero,
>
> This is out of my realm of expertise, but here is what I found:
> --------------------------------------------------
> The default scheme for determining 'delta_j(k)' in each zone is the 
> 'Uniform' prescription, which is toggled through the binary inlist 
> controls:
>
>
> ! + "Uniform" : Each layer is synced independently given the sync 
> timescale.
>
>
> ! ::
>
> sync_mode_1 = 'Uniform'
>
> sync_mode_2 = 'Uniform'
>
>
>
> Looking in binary_tides.f90, subroutine_sync_spin_to_orbit :
>
> *character* (len=strlen), *intent*(*in*) :: sync_mode ! where to 
> put/take angular momentum
>
>
> The default 'Uniform', results from the approach described in section 
> 2.4 of MESA III (Paxton et al. 2015) 
> <https://ui.adsabs.harvard.edu/abs/2015ApJS..220...15P/abstract> :
>
> *if* (sync_mode == "Uniform") *then*
>
> a1 = f2(b% eccentricity)
>
> a2 = pow(1-pow2(b% eccentricity), 1.5d0)*f5(b% eccentricity)
>
> *do* k=1,nz
>
> delta_j(k) = (1d0 - exp(-a2*dt_next/t_sync))*(s% j_rot(k) - 
> a1/a2*j_sync(k))
>
> *end* *do*
>
>
> with f2 and f5 coming from Hut 1981, A&A, 99, 126:
>
>
> *real*(dp) *function* f2(e)
>
> *real*(dp), *intent*(*in*) :: e
>
> f2 = 1d0
>
>
> ! Hut 1981, A&A, 99, 126, definition of f2 after eq. 11
>
> *if* (e > 0d0) *then*
>
> f2 = 1d0 + 15d0/2d0*pow2(e) + 45d0/8d0*pow4(e) + 5d0/16d0*pow6(e)
>
> *end* *if*
>
> *end* *function* f2
>
>
>
> *real*(dp) *function* f5(e)
>
> *real*(dp), *intent*(*in*) :: e
>
> f5 = 1d0
>
>
> ! Hut 1981, A&A, 99, 126, definition of f5 after eq. 11
>
> *if* (e > 0d0) *then*
>
> f5 = 1d0 + 3d0*pow2(e) + 3d0/8d0*pow4(e)
>
> *end* *if*
>
> *end* *function* f5
>
>
> --------------------------------------
> On the other hand the (non-default) sync mode:
>
> *else* *if* (sync_mode == "tdyn_div_tkh")
>
>  refers to a seperate iterative method for determining the 
> specific angular momentum "J(k)" of each model zone/cell by 
> iteratively solving for the efficiency 'ff' of angular momentum 
> transport in each zone. This iterative calculation is done until the 
> total change in angular momentum summed over all the zones is 
> equivalent to the 'delta_total_J', the total angular momentum change 
> of the model of the given timestep:
>
> delta_total_J = delta_total_J*(1d0- exp(-dt_next/t_sync))
>
>
> This is done by calculating the local dynamical timescale and the 
> local thermal timescale in each model zone, I suspect to provide some 
> physical basis for this parameterization, and then iterating to solve 
> for an ff that allows the total angular momentum to converge to the 
> "delta_total_J" calculated from the synchronization timescale.
>
> The comment you were referring to describes this iterative process:
>
>
>
> ! Iteratively solve the scaling factor ff to add (or remove) 
> delta_total_J.
>
> ! At each iteration, ff is solved such that each zone k has a change on
>
> ! its angular momentum J_k of the form:
>
> !
>
> ! Delta J_k = (J_k-J_{k,sync})*tdyn_div_tkh(k)**2*ff,
>
> !
>
> ! and the total change adds up to delta_total_J.
>
> ! Since tides can at most drive a layer into sync, ff cannot be
>
> ! solved right away. Then, each iteration solves ff ignoring layers
>
> ! going over sync, spreads the angular momentum to see which ones
>
> ! become synced, and then recalculates taking this into account
>
> ! until it converges.
>
>
> I did not write this routine, but I suspect that scaling Delta_J(k) 
> with tdyn_div_tkh(k)**2 is based off a physical argument that goes 
> something like this: zones which are evolving dynamically (sound 
> crossing time) will likely transport significantly more angular 
> momentum and tidally sync much faster than zones which are are 
> otherwise dynamically stable. Likely the thermal timescale is just 
> used for reference.
>
> Again, I am no expert in this topic, and others (particularly the 
> person who wrote this subroutine) might be able to provide a more 
> complete argument for this scaling relation.
> ------------------------------
> Since you brought this up, I actually looked into 
> the binary_controls.defaults to find that there is in fact no control 
> or documentation to toggle 'tdyn_div_tkh'. The documentation for this 
> control might have been accidentally overlooked control, and a 
> bug_report on the MESAHub Github <https://github.com/MESAHub> might be 
> in order to add something like the following to binary_controls.defaults:
>
>
> "! + "tdyn_div_tkh" : Each layer is synced independently using 
> tdyn_div_tkh to iteratively calculate the efficiency, given 
> the timescale."
>
>
> Hope this helps,
> EbF
>
>
> On Fri, Mar 31, 2023 at 3:04 AM Ruggero Valli 
> <ruvalli at mpa-garching.mpg.de> wrote:
>
>     Hello,
>     I am trying to understand how tidal torque is implemented in mesa.
>     In the 2015 instrument paper it is explained that each shell is
>     treated separately as a rigid body rotator, and each cell has the
>     same synchronization timescale t_sync
>     Therefore, I would expect that for each shell k the variation of
>     angular momentum Delta J_k would be
>
>     Delta J_k = -(J_k-J_{k,sync}) * dt/t_sync
>
>     Instead, looking at the subroutine sync_spin_to_orbit in
>     binary_tides.f90, it seems to me that
>
>     Delta J_k is proportional to (J_k-J_{k,sync}) *
>     tdyn_div_tkh(k)**2//(as explained in a comment in the code)
>
>     And the synchronization timescale t_sync//is only used to set the
>     proportionality constant by imposing that the total angular
>     momentum change of the star is
>
>     delta_total_J = (total_J - total_J_sync)*(1 - exp(-dt/t_sync))
>
>     My question is:
>     *Where does the factor *tdyn_div_tkh(k)**2/**/*come from and why
>     is it used instead of *dt/t_sync*?*
>
>     Cheers,
>
>     Ruggero
>
>     _______________________________________________
>     mesa-users at lists.mesastar.org
>     https://urldefense.com/v3/__https://lists.mesastar.org/mailman/listinfo/mesa-users__;!!IKRxdwAv5BmarQ!cTwhMimk4tUBA_PAcjTfciv-vPll2mS1DxOczgrouAMM1SOD9lr6KZBa-tdpzO1PjFmNuvRZM97s7I4HNN1wbGyDLQ$
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20230403/fdab6423/attachment.htm>