Truncate at flow

[md-arif-shaikh]

• Addresses Need to be more careful in truncate_waveform_by_flow #154
• move truncate_at_flow inside eccDefinition.py
• write a wrapper for truncate_at_flow in gw_eccentricity.py

[vijayvarma392]

Question first: Have you tested this code in different scenarios?
Two things come to mind (but any other scenarios you can think of would be good as well).

1. What if I give you a waveform where the first perisastron frequency is like 25Hz, and I ask for flow=20Hz. Does the code catch this and give a useful error message?
2. What if you can't find enough periastrons? To test this, you could use ecc~1e-6 or something and method=Amplitude so we know it won't catch all periastrons. What's the behavior then? This is important because we want to know what the code will do if someone tries to use it on a quasicircular waveform (which you should also test by passing it an SEOBNRv4 waveform, the noneccentric one).

[md-arif-shaikh]

I thought something similar to the first question. I thought about checking the initial frequency in the waveform. If the waveform starts at an instantaneous frequency > flow, should not we just return the original dataDict without doing anything?

[vijayvarma392]

I thought something similar to the first question. I thought about checking the initial frequency in the waveform. If the waveform starts at an instantaneous frequency > flow, should not we just return the original dataDict without doing anything?

No, if the given waveform is too short, we should raise an error.
But initial instantaneous frequency is not the best way to do that. You can have initial instantaneous frequency = 20Hz and still have periastron frequencies at earlier times that are >20Hz...think of the scenario where the initial time is at an apastron.
Instead, what you need to do is check if the first periastron frequency is > 20Hz, as that is what is used to determine tlow anyway.

[md-arif-shaikh]

@vijayvarma392
I have addressed the first question by adding a check. The second question, however, is tricky to manage and applies to the general case of eccentricity measurement. How do we handle issues where no extrema are found? Extrema might not be found in atleast three cases

• The waveform is genuinely quasi-circular
• The waveform is too short
• The method is not efficient

I think we can have a sequence of checks when no extrema are found

• First, we note what method is being used. If it is Amplitude or Frequency or some other method that is not efficient or robust enough we recommend using ResidualAmplitude since it is the most robust method so far
• If with ResidualAmplitude we find no extrema, then we check the number of cycles in the waveform by assuming 4pi phase diff for one cycle in 22 mode phase. If the number of cycles is less than 5 or so we say it is not long enough and raise the error
• If the number of cycles is > 5 and already using ResidualAmplitude but find no extrema, we assign eccentricity = 0 with a warning.
  What do you think?

[vijayvarma392]

Can you only do the flow stuff in this PR? Will be easier to review.

[md-arif-shaikh]

Closing this to address this in a later PR.