Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementing Eddington limit for BHs based on spinup/ISCO #570

Merged
merged 8 commits into from
Sep 12, 2022

Conversation

michaelzevin
Copy link
Collaborator

@michaelzevin michaelzevin commented Sep 1, 2022

This PR adjusts the Eddington limit for BHs based on the implementation in Marchant et al. 2017, following Equations 3-5. It introduces a new global parameter Mbh_initial that remembers the initial mass of the BH at formation, and calculates the eta parameter that alters the mass transfer rate based on where the ISCO is, assuming the BH is spinning up from stable accretion as in Thorne 1970.

As of now, I added an additional global parameter BHbirth_ind that is 0 before the BH forms and 1 after so that Mbh_initial doesn't get overwritten in hrdiag.f, though there's probably a more glamorous way to ensure this.

This actually causes the Eddington limit for BHs to be ~1 order of magnitude higher for low-spinning BHs than the standard BSE prescription!!! It is unclear where Hurley got the expression for the Eddington limit that is implemented in stock BSE (Equation 67 of Hurley et al. 2002). The two expressions are identical for eta = 0.5, which is slightly above the maximum value of eta=0.42 which is attained for a maximally-spinning BH (one that accreted more than sqrt(6) times its initial mass).

Attached are the mass transfer rates for a few binaries, comparing the current BH accretion limit to the one in this PR. There is still an issue of deltam_1 for the first timestep written into the bcm array not obeying the imposed Eddington limit, which can be seen in a few of these systems.

eddlim

There are probably other changes that need to be made to the unit test files, so let me know what else needs to be done!

@codecov
Copy link

codecov bot commented Sep 1, 2022

Codecov Report

Merging #570 (538753a) into develop (37a19db) will increase coverage by 0.99%.
The diff coverage is 18.75%.

@@             Coverage Diff             @@
##           develop     #570      +/-   ##
===========================================
+ Coverage    87.13%   88.12%   +0.99%     
===========================================
  Files           40       40              
  Lines        25393    25432      +39     
===========================================
+ Hits         22124    22410     +286     
+ Misses        3269     3022     -247     
Impacted Files Coverage Δ
cosmic/src/hrdiag.f 39.24% <0.00%> (-0.30%) ⬇️
cosmic/src/evolv2.f 57.63% <23.08%> (-0.44%) ⬇️
cosmic/sample/cmc/elson.py 88.24% <0.00%> (-0.65%) ⬇️
cosmic/bse_utils/zdata.py 100.00% <0.00%> (ø)
cosmic/bse_utils/zcnsts.py 100.00% <0.00%> (ø)
cosmic/evolve.py 84.58% <0.00%> (+29.17%) ⬆️
cosmic/sample/sampler/multidim.py 86.49% <0.00%> (+68.92%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@@ -800,6 +800,11 @@ SUBROUTINE hrdiag(mass,aj,mt,tm,tn,tscls,lums,GB,zpars,
endif
endif
mt = mrem
* Store the initial BH mass for calculating the ISCO later
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about initializing Mbh_initial to 0, then checking if Mbh_initial.eq.0 instead of BHbirth_ind?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep makes total sense and is definitely cleaner, I’ll push that change to this PR.

Copy link
Collaborator

@katiebreivik katiebreivik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think my question above isn't 100% necessary, but will save on new variable bloat if it works. Otherwise, this looks good to go!

@michaelzevin
Copy link
Collaborator Author

@katiebreivik I've done what you suggested. Looks like the unit tests never encountered super-Eddington accretion so they still pass.

There's still the issue with the deltam1_bcm for the first timestep of the BCM array sometimes still being super-Eddington, though I don't think this is a huge issue.

@katiebreivik
Copy link
Collaborator

Hey @michaelzevin sorry for being slow! -- can you open an issue with an example binary that still goes super Eddington on the first time step? I just want to make sure we don't lose it in the mix. Once that issue's open, feel free to merge!

@michaelzevin
Copy link
Collaborator Author

Good call. I've opened an Issue at #571. I'll now go ahead and merge.

@michaelzevin michaelzevin reopened this Sep 12, 2022
@michaelzevin michaelzevin merged commit 561e8c6 into COSMIC-PopSynth:develop Sep 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants