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

gradev broken, especially for frequency data #60

Open
jleute opened this issue Oct 4, 2017 · 1 comment
Open

gradev broken, especially for frequency data #60

jleute opened this issue Oct 4, 2017 · 1 comment

Comments

@jleute
Copy link
Contributor

jleute commented Oct 4, 2017

The gap resistant ADEV functions have some issues that should be easy to fix and a more serious issue concerning frequency data.

The easy to fix issues:

  • calc_gradev_phase() calls the function uncertainty_estimate() that doesn't exist.
  • the parameters mj and stride are not converted to integers in calc_gradev_phase().

The more important issue is that gradev() doesn't work properly for frequency data. If the input data is a frequency array with NaN values, the frequency2phase() function is called and it sets all phase values to NaN after the first NaN value occurs in the frequency array. That's a property of np.cumsum(). If you are unlucky and the first value is a NaN you lose all data in this step. There is a function called trim_data() that trims NaNs from the beginning of an array, but it is not used anymore (since the API change).

Additionally, since the API change, the gradev example uses data_type='freq' and the example doesn't work very well due to the issue discussed above.

The core issue here is that for frequency data with gaps, the frequency data can not be converted to phase data and the gradev must be calculated based on the equations for the adev for fractional frequency data.
At the moment all *dev calculations in allantools are based on phase data. What do you think about *dev calculations based on frequency data?

As discussed in I. Sesia and P. Tavella, Metrologia, 45 (2008) p. 134, using the phase data for the adev calculation is preferred in the presence of data gaps, but sometimes there is no choice.

@aewallin
Copy link
Owner

aewallin commented Oct 4, 2017

Thanks for noticing this. Ideally bugs should be caught by tests, but there are probably no tests that run gradev() yet.

if there is a real need for frequency-data based adev functions then they should be included in the library. Are there published efficient algorithms for frequency data input? I would assume a naive code that takes frequency-input is much slower than the current phase-input code - but maybe there are good ways to do the frequency averaging (at longer taus than the data interval) needed?

fmeynadier added a commit to fmeynadier/allantools that referenced this issue Feb 26, 2018
This commit should fix issue aewallin#60, although there is still work to do to
clean up examples, make them be tested systematically, and look more in
detail into the processing of frequency data, as suggested by Julia.

- call to function uncertainty_estimate() has been replaced by its
equivalent simple_edf() / confidence_interval() call (please check that
I understood correctly !)
- the parameters mj and stride have been forced into int()
- example data has been switched to "phase" and now works properly
- Warnings are issued in doc and a message is displayed whenever gradev() is called with freq data
aewallin added a commit that referenced this issue Mar 27, 2018
@aewallin aewallin mentioned this issue Jul 27, 2019
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants