Cosmic integration edits to compute WDWD merger rates

[melanie-santiago26]

Added a bool for WDWD systems in Class COMPAS so that you can calculate the WDWD merger rates.

Added two flags (keep_pessimistic_CEE, keepRLOF_postCE) to fastcosmicintegration.py

Updated the analytical calulation of the star forming mass to allow for a varying f_binary fraction with mass now that f_binary is None, piecewise constant value for f_binary will be used reflecting Offner 2023.

Analytical derivation of the function analytical_star_forming_mass_per_binary_using_kroupa_imf is shown in the attached notebook: Test_fbinary_perM.zip

Warning - There seems to be a small discrepancy between MC sampled average and analytical function (but I think the MC sampler might be wrong).

[SimonStevenson]

Hi Melanie, thanks for the contribution!

Do you have a dataset (or command that produces a dataset) that works to test this change? I did a small population run with

./COMPAS --initial-mass-min 1.0 -n 10000 --metallicity-distribution LOGUNIFORM --evolve-double-white-dwarf TRUE

and then ran cosmic integration with

python ./FastCosmicIntegration.py --path /Users/spstevenson/Github/melaniesantiago/COMPAS/src/COMPAS_Output_2/COMPAS_Output.h5 --dco_type WDWD

but got

    if max(chirp_masses)*(1+max_redshift_detection) > Mc_max:
       ^^^^^^^^^^^^^^^^^
ValueError: max() arg is an empty sequence

which I guess means there are no merging WDWD binaries in my sample. Perhaps we could add a check that n_binaries > 0 so that we could tell the user if there are none of their requested DCOs in their sample.

What do you assume about Pdet for WDWD binaries? Presumably this should be 0, since WDWD binaries are not sources for ground-based GW detectors like LIGO. It wasn't clear to me whether the current code would do this.

Is the science case here things like comparing to the SN 1a rate as a function of redshift? (like Figure 3/4 in Eldridge et al. 2018)

We shouldn't comment out lines we are not using any more, those should be deleted. The previous behaviour is saved in the git history, so we can always go back to see what we were doing before.

Should we consider enabling rate calculations for other DCO binaries (BH-WD, NS-WD etc) as well? These may be useful to someone. This could also be left to a future update.

[jeffriley]

@avivajpeyi fyi

[melanie-santiago26]

Hello Simon!

Thank you for reviewing everything and sorry for my delayed reply!

To combat the lack of WDWDs in your stimulation I (and Lieke) would suggest adding the flag "--include-WD-binaries-as-DCO: True" and sampling with low enough M1 (i.e. of 0.9 $M_{\odot}$). Lieke also has some simulations that she will try to share with you, but if you want you can also run a small simulation with the flag suggested above.

Also, yes I agree that a check or a print statement alerting the user when there are none of the specific DCOs that they are masking for would be very helpful! I will implement that soon.

Yes! We are trying to get a feel for the SNe Ia rates as a function of redshift. I have attached below examples of the WDWD merger rates with a run of $\alpha_{CE}=1$ for the progenitor systems motivated by Shen 2025 (Figure 6).

I can add an error statement that warns people that the WDWD systems they are masking for are not relevant for LVK observations and making it clear that intrinsic rates are only being computed.

Also, I will add the two masks for BH-WD and NS-WD systems because we were thinking of doing that soon as well!

(Will also be sure to delete any comment lines – sorry about that!)

[ilyamandel]

I am not a python coder, so I hope someone else (@SimonStevenson ? @jeffriley ? ) can do a proper code review. That said, here are a few queries:

"BHNS": np.logical_and(np.isin(stellar_type_1,[13,14]),np.isin(stellar_type_2,[13,14])),

Won't this flag NS-NS and BH-BH binaries too, not just NS+BH ones? Cf. original code

"BHNS": np.logical_or(np.logical_and(stellar_type_1 == 14, stellar_type_2 == 13), np.logical_and(stellar_type_1 == 13, stellar_type_2 == 14))

While adding WDWD, do you want to also add WDNS and WDBH, or at least WDCO?

type_masks["CHE_BBH"] = np.logical_and(self.CHE_mask, type_masks["BHBH"]) if types == "CHE_BBH" else np.repeat(False, len(dco_seeds))

You changed BBH to BHBH in some places but not others -- I find this mixing rather more confusing / more likely to lead to typos in future development (i.e., I don't mind if you prefer BBH or BHBH, but suggest you pick one and stick with it)

from compas_python_utils.cosmic_integration import ClassCOMPAS

import ClassCOMPAS

There are a variety of places in different files where some of the import statements were commented out and replaced. If the new imports are preferred (why? see above about my not being a python coder), just delete the old ones: commented out code lines bloat the code and make it harder to read.

5. Repeated words in text:
   "will mask binaries that binaries that experience a CEE while on the HG"

The number of merging BHBHs that need a weight

I think this comment should refer to DCOs, not just BHBHs

I have not had time to check the new normalisation code, but I am concerned by the statement that it doesn't agree with a Monte Carlo calculation. I think that's a necessary test, and it would be good to understand why they disagree.

[LiekeVanSon]

Thanks Simon and Ilya for helping reviewing this :)

@SimonStevenson,

• I have some 10^6 simulations that were AIS for WDWD and NSNS mergers, but they are ~12Gb, so a bit bothersome to transfer. I could discard all non-essential hdf5 data, but it might be easier to run as Melanie suggested with: --include-WD-binaries-as-DCO: True (note this is not the same as --evolve-double-white-dwarf TRUE )

• great point about the error:

    if max(chirp_masses)*(1+max_redshift_detection) > Mc_max:
       ^^^^^^^^^^^^^^^^^
ValueError: max() arg is an empty sequence

I added a few lines in setCOMPASData(self) that should catch both empty DCO tables, and empty lists after the additional masks are applied.

• About Pdet: indeed as Melanie mentioned, we would only be interested in intrinsic rates here. I added a wanring to compute_snr_and_detection_grids

• for the commented out lines, were you referring to the import statements that Ilya is also referring to? (see below)

• As noted by both, I added the BHWD and NSWD masks

Re: @ilyamandel 's points

1. the np.isin behaviour was indeed buggy! changed it back to the logical_or behavior
2. changed all instances from "_BBH" to "_BHBH"
3. I've tried to resolve this by adding compas_root_dir + compas_python_utils/cosmic_integration to the sys path.
4. and 6.: typo fixed
5. This needs some further investigation from my side, but if anyone spots a mistake in the derivation, please let me know

[ilyamandel]

Thanks, @LiekeVanSon ! If you don't find the issue with 7, let me know and I'll take a look. Can you confirm that Monte Carlo and the new analytical calculation agree when the binary fraction is fixed (not mass-dependent)?

[LiekeVanSon]

I can confirm the answers agree when fbin is constant (but have yet to look into the difference when fbin is varied)

[SimonStevenson]

Hi @melanie-santiago26 , @LiekeVanSon ;

Thanks for the changes!

Thanks for the pointer about --include-WD-binaries-as-DCO as well, I guess I had forgotten about that.

I ran a small population and everything worked as expected. For reference, I used:

./COMPAS --initial-mass-min 1.0 -n 50000 --metallicity-distribution LOGUNIFORM --evolve-double-white-dwarf TRUE --include-WD-binaries-as-DCO TRUE

and post-processed it with

python /Users/spstevenson/Github/melaniesantiago/COMPAS/compas_python_utils/cosmic_integration/FastCosmicIntegration.py --path /Users/spstevenson/Github/melaniesantiago/COMPAS/src/COMPAS_Output_3/COMPAS_Output.h5 --dco_type WDWD

I think there is still a problem with computing detection rates for WD populations. The detection rate panel in the default plot shows a non-zero value.

It seems that a warning is printed in compute_snr_and_detection_grids if using WDWD, however it seems that the arrary detection_rate is still computed in the find_detection_rate function. I think the check should be moved to there, and explicitly return an array of zeros for WD binaries.

[ilyamandel]

Hi @LiekeVanSon , @melanie-santiago26 -- it's been quite a while since the last round of comments on this. Have you had any luck with resolving these issues?

[LiekeVanSon]

Hi @ilyamandel

Sorry for leaving this so long!

I have tried to approach this from a few angles, but I must admit I'm a bit stuck: the analytical an numerical calculations don't agree with each other when the f_bin is variable

Specifically:
The "old' and 'new' analytical methods agree with each other when fbin = constant

In this case it also passes the pytests (that I think Avi has set up? ) which just does the integral using quad from script and mock COMPAS data
i.e. running from the $COMPAS_ROOT_DIR:
pytest py_tests/test_total_mass_evolved_per_z.py -v
produces


However, when f_bin is variable (will activate when f_bin = None) the “numerical” and analytical functions disagree.

I thought that the issue was that the quad in get_COMPAS_fraction couldn’t handle sharp edges in the integral, but think I fixed that now and they still disagree. 



I also tried to start from scratch just using MC sampler to create a mock Universe (see notebook in zip file
Test_fbinary_perM_inclMCMC.ipynb.zip
), but I am clearly doing something else wrong here since the my MC sampler doesn’t even match the “old analytical” results.

I must admit I didn't spend a whole lot of time de-bugging the latter MC code, because I now suspect I made a mistake in the analytical calculation after all...!
@ilyamandel could you perhaps have a look at the analytical derivation to see if any obvious mistakes stand out? I've written the math out in full in Test_fbinary_perM_inclMCMC.ipynb.zip, or you can find the the logic with a lot of comments in the function analytical_star_forming_mass_per_binary_using_kroupa_imf() .

Also apologies in advance for an (extra) slow response since I am transitioning to Radboud and taking a lot of offline time in August :)