You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In GitLab by @git.ligo:gregory.ashton on Dec 3, 2020, 09:38
Email from Stephen Feeney:
It's nothing enormous, but it can result in the results.injection_parameter storing the wrong inclination angle, iota. This happens for me because I'm using a reference frequency that is different from bilby's default. In bilby/core/sampler/init.py, in run_sampler, when appending the injection_parameters to the result object, conversion_function is called without passing in the likelihood object (which in turn contains the user-specified minimum and reference frequencies). This means result.injection_parameters uses the default reference_frequency when converting theta_jn etc. into iota, and as a result my results objects' iotas don't match the ones actually used when injected signals. Niche :) But I thought you'd want to know :)
However, this creates a bit of a problem: if users pass in their own conversion functions which don't accept the likelihood it will fall over.
Fundamentally, I think we are missing a standard interface for the "conversion" function. I think the resolution here is to set a convention for the conversion function. What do folks think?
The text was updated successfully, but these errors were encountered:
In GitLab by @git.ligo:moritz.huebner on Dec 10, 2020, 12:58
Also pinging @git.ligo:colm.talbot
I don't know if I fully understand the issue and how to fix it since the conversion functions in bilby can be a bit confusing in how they work and what they do.
I know it is a bit hacky, but couldn't we just do a try/except clause around the line in run_sampler?
In GitLab by @git.ligo:gregory.ashton on Dec 10, 2020, 13:41
This would be a temporary hack (to solve a minor niche problem). I think we are better off taking the time to make a consistent interface for the conversion function to fix this.
I'd also like to see more clarity around conversion/generation functions.
In GitLab by @git.ligo:gregory.ashton on Dec 3, 2020, 09:38
Email from Stephen Feeney:
Pointing to the code, this line needs to also pass in the likelihood.
However, this creates a bit of a problem: if users pass in their own conversion functions which don't accept the likelihood it will fall over.
Fundamentally, I think we are missing a standard interface for the "conversion" function. I think the resolution here is to set a convention for the conversion function. What do folks think?
The text was updated successfully, but these errors were encountered: