Feature request: number of orbits and time to merger in NRPyPN

[Sbozzolo]

I use NRPyPN to set up my binary black hole simulations. It would be very useful for me to have an estimate of the time to merger given some initial data. This is so that I can have a sense of how long the simulations is going to be, and to set up horizon finders more precisely. Additionally, sometimes I want to run simulations for N orbit and I don't care about the initial separation. It would be lovely if NRPyPN could tell me the initial separation given the number of orbits that I want to simulate.

[zachetienne]

Thanks for the request Gabriele! I really want this feature as well.

To this end, we are working on an optimized version of a state-of-the-art gravitational wave approximant, SEOBNRv4P, which is calibrated against NR binary black hole simulations. Once this is ready, I think it'll provide a pretty good estimate of the duration of a simulation.

For now, barring downloading & installing LALSuite (which will give direct access to the official SEOBNRv4P), another idea would be to download a version of
https://bitbucket.org/eob_ihes/teobresums/src/master/
to get an estimate.

[Sbozzolo]

Thanks for your response.

To this end, we are working on an optimized version of a state-of-the-art gravitational wave approximant, SEOBNRv4P, which is calibrated against NR binary black hole simulations. Once this is ready, I think it'll provide a pretty good estimate of the duration of a simulation.

I am (very slowly) developing a package to prepare Einstein Toolkit simulations with a much higher interface than the .par files (https://github.com/Sbozzolo/Jhuki). At the moment, I use NRPyPN to compute the momenta for quasi-circular inspirals. This is where I would like to have functions to estimate number of orbits and merger time.

I can already use PyCBC to estimate the number of orbits and the time to merger using existing approximants. However, PyCBC comes with loads of dependencies (including LALSuite) that I would like to avoid to keep my package easily installable on as many machines as possible (I already had a lot of dependency annoyances with PyCBC/LALSuite for kuibit). So, for my use case, the most ideal solution would be to have a couple of additional functions in NRPyPN. Given what is already in the code, this sounds something that should be doable, but I don't know anything about post-Newtonian theory, so maybe I am completely wrong.

[zachetienne]

This looks like a very interesting and useful package Gabriele. Indeed dependencies can make a mess for new users, and we'll continue to try to minimize them in NRPy+ development. In fact it's the reason I pointed to TEOBResumS as a possible option (though, it's not in Python).

Speaking of things not in Python, I recently wrote a very small C code that does the same thing as NRPyPN, only ~1000x faster (using NRPy+ C code output capabilities). I'd be happy to share if you are interested.