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

Feed positions analyser #116

Open
1 of 6 tasks
jrs65 opened this issue Jul 19, 2019 · 2 comments
Open
1 of 6 tasks

Feed positions analyser #116

jrs65 opened this issue Jul 19, 2019 · 2 comments
Assignees
Labels
analyzer Add a new Analyzer

Comments

@jrs65
Copy link
Contributor

jrs65 commented Jul 19, 2019

A brief summary of changes that would be good to have for the feed positions analyser:

Grafana:

  • the singlestats should show only the last 24 hours, but seem to vary depending on the time range selected.
  • it would be nice to have a good/bad stat that summarise whether the data is good or not.

Analyzer:

  • at the moment the good/bad thresholds are actually hardcoded in the analyzer. This is a policy decision that's probably better at a higher layer. We should expose relevant statistics into prometheus and let those decisions be made higher up. The key question is what are the statistics to export, possibly num_feeds_above_threshold{threshold="1.0",freq_id="14"}, i.e. we pick a few (maybe ~10) distance thresholds and just return the number above each.

Analysis:

There's a few questions we need to address from the analysis:

  • when is a feed good/bad?
  • when is the instrument good/bad? What statistic do we test, and what threshold should we use?
  • look back at historical data to see if/when/how this analyser is catching periods of bad data? There are certain failures it should be immune from (i.e. calibration/flagging), but it should catching rain event jumps, decorrelated cylinders, massive RFI issues etc.
@jrs65
Copy link
Contributor Author

jrs65 commented Jul 19, 2019

@mondana anything else we want on here?

@cahofer
Copy link
Contributor

cahofer commented Aug 8, 2019

@jrs65 I substituted the percentage of bad feeds metric with a num_feeds_above_threshold metric which has labels frequency, source and threshold. I chose threshold levels 2.0, 3.0, 4.0, 5.0, 7.0, 10.0. The unit is a foot (one feed separation)

Feeds that are flagged by flagging broker are excluded when calculating the number of bad feed positions above these thresholds. This should make the analyzer immune against flagged bad feeds.

If lets say eigenvalue on versus off source is greater than some threshold, then the analyzer will flag the data for that specific frequency. This was intended to serve as a test for RFI issues in a frequency bin.

Since it's using the chemical dataset - I think the only thing that needs to have worked is the eigen decomposition of the visibility matrix at source transit. If understand that remark correctly, the feed position does not rely on derived gains/ or calibration.

As for rain jumps and decorrelated cylinders ... I have no idea at this point.

@ketiltrout ketiltrout added the analyzer Add a new Analyzer label Mar 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer Add a new Analyzer
Projects
None yet
Development

No branches or pull requests

3 participants