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

How should we handle failures? #84

Closed
vijayvarma392 opened this issue Jun 17, 2022 · 1 comment
Closed

How should we handle failures? #84

vijayvarma392 opened this issue Jun 17, 2022 · 1 comment
Assignees
Labels
medium priority inbetweener

Comments

@vijayvarma392
Copy link
Owner

vijayvarma392 commented Jun 17, 2022

What should the code do when it cannot measure ecc?
For example, for the Amp method when we are at small ecc and very close to the merger.
When tref_in has a bunch of times/freqs, it just returns those times/freqs where it can measure ecc, but think of the PE scenario where the user has one time/freq and sometimes that happens to not work.

How about the following behavior:
By default, it raises an error.
But if an option like "failures_are_set_to_zero" = True, the method then sets ecc=mean_ano=0.
There should be a big warning in the docs about using this.

But, at least for the Amp method, we expect failures only when ecc is really small, so this might be good enough at current sensitivities. I mean, who cares about the difference between ecc=1e-5 and 1e-3?

One would have to be more careful for FrequencyFits, of course, at least until we are happy with its robustness.

@vijayvarma392 vijayvarma392 changed the title How should be handle failures? How should we handle failures? Jun 17, 2022
@vijayvarma392 vijayvarma392 added the medium priority inbetweener label Jun 18, 2022
@md-arif-shaikh
Copy link
Collaborator

Moving this to #206

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
medium priority inbetweener
Projects
None yet
Development

No branches or pull requests

2 participants