Closed bilby-bot closed 2 weeks ago
In GitLab by @git.ligo:moritz.huebner on Oct 25, 2018, 01:04
I would not guess that this is too much of a concern, but we should rather be safe with our constants. lalsuite seems to have take more places into account.
I think there are multiple ways we can resolve this:
Update and maintain our constants ourselves (In case somebody comes up with a better measurement of G)
Use the lalsuite constants and give them names in bilby, i.e. parsec = lal.PC_SI
Use some other reference such as astropy.constants
I'd favour the second approach.
Also while we are changing this, we should consider making these constants ALL_CAPS, which indicates that they are in fact constants.
In GitLab by @git.ligo:paul-lasky on Oct 25, 2018, 01:09
I agree with updating this. I believe the reason we initially went away from @git.ligo:moritz.huebner's option 2 is that we tried to rely as little as possible on LAL infrastructure. I don't know how people feel about this moving forward: @git.ligo:moritz.huebner @git.ligo:gregory.ashton @git.ligo:colm.talbot ??
In GitLab by @git.ligo:sebastian-khan on Oct 25, 2018, 10:35
I also compared LAL with astropy just for completeness. I would say being consistent with LALSuite makes most sense, and it's not a big deal to install via pip anymore so that dependency is the same as astropy now right? python3 LAL is coming along too.
Having said that the astropy.constants
module seems quite nice!
But I really don't know anything about it beyond I think it looks nice :p
from astropy import constants
import lal
print(lal.G_SI / constants.G.value)
#0.9999640399875338
print(lal.C_SI / constants.c.value)
#1.0
print(lal.MSUN_SI / constants.M_sun.value)
#1.000035977122355
print(lal.PC_SI / constants.pc.value)
#1.0000000000078348
print(lal.REARTH_SI / constants.R_earth.value)
#1.0000057383860397
In GitLab by @git.ligo:gregory.ashton on Nov 5, 2018, 01:54
I'd vote to use the lalsuite
constants (i.e. option 2).
In GitLab by @git.ligo:paul-lasky on Nov 5, 2018, 11:07
One issue with using lalsuite
for this is that these constants actually live in core/
, not in gw/
. No other part of core
(to the best of my knowledge) relies on any external gravitational-wave codes. This seems like a big additional burden for just a couple of numbers, especially given we'd still like Bilby to be a broader code base than just for GW PE. On the other hand, astropy
is (in some sense) an astronomy-community standard tool.
This is just my 2c, I'm happy to be voted against...
In GitLab by @git.ligo:gregory.ashton on Jan 29, 2019, 03:36
created merge request !343 to address this issue
In GitLab by @git.ligo:gregory.ashton on Jan 31, 2019, 23:16
closed via merge request !343
In GitLab by @git.ligo:gregory.ashton on Jan 31, 2019, 23:16
closed via commit ba9278377c2ae2dd8fb32d00e0c5cc58d5b5e291
In GitLab by @git.ligo:gregory.ashton on Feb 1, 2019, 04:25
mentioned in commit ba9278377c2ae2dd8fb32d00e0c5cc58d5b5e291
In GitLab by @git.ligo:michael.williams on Oct 3, 2024, 17:56
unassigned @git.ligo:gregory.ashton
In GitLab by @git.ligo:sebastian-khan on Oct 22, 2018, 22:13
Hi all, I was poking around the bilby code and noticed you have coded up the following values in core.utils.
I compared these with what is in lalsuite and get the following:
Is this a concern? I remember before I was doing some comparisons and the disagreement was being I wasn't using Newton's constant to the same precision and since then I am paranoid about these things :)