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

Known asteroid photometry and lightcurve from public alerts #431

Open
mcoughlin opened this issue Jun 23, 2022 · 0 comments
Open

Known asteroid photometry and lightcurve from public alerts #431

mcoughlin opened this issue Jun 23, 2022 · 0 comments
Labels
enhancement New feature or request solar system Solar system science

Comments

@mcoughlin
Copy link
Contributor

mcoughlin commented Jun 23, 2022

Feature Summary
Would it be possible to use Fritz to show the photometry as a function of time for all known asteroidal sources taken from the alert stream? Showing the photometry as a function of time would enable monitoring of asteroid brightness and detection of sudden brightening events such as those cause by disruptions.

Implementation
From @dmitryduev :
To allow filtering on that in Fritz, a new kind of a filter needs to be implemented:

  • Add a flag/field to K filter definition {solar_system: <true|false>}, propagate this to the SP filtering extension
  • Define dedicated upstream stages for filters with {solar_system: true} (see https://docs.fritz.science/user_guide.html#upstream-aggregation-pipeline-stages) that would:
    • check if candidate.ssnamenr is not null and candidate.distssnr is < 2 or something similar.
    • pull alerts by candidate.ssnamenr (and not prv_candidates as for transient filters)
    • fit a polynomial to the magpsf time series and report the "predicted" value?
  • The id to use when posting to SP should be candidate.ssnamenr and not objectId as for transients.

Alternative Implementation
Perhaps a faster way to achieve the same thing as discussed above would be to implement a custom sentinel service, somewhat similar to the one I wrote for Tails.
That service would:

  • periodically query Kowalski for the latest batches of alerts with candidate.ssnamenr that is not null and candidate.distssnr that is < 2 or something
    • for the newly identified detections, pull alerts from corresponding asteroids by candidate.ssnamenr
  • fit a curve to the time series, or do whatever complicated thing you want, extrapolate that to the time of observation and compare that to the actual detection
  • if it exceeds a threshold of some kind, post results to Fritz.

From Ashish:
The time series/polynomial fitting will be more involved due to rotations, relative positions of the asteroid, the sun, and Earth. What I was hoping to do is to first get a sense of these variations for a large number of named/known asteroids within ZTF data to be able to define some kind of threshold (as you say in your comment above) which can then be used as a sentinel service. Right now I don't know even the number of observations available within ZTF for various asteroids.

Copied from fritz-marshal/fritz-beta-feedback#37

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request solar system Solar system science
Projects
None yet
Development

No branches or pull requests

1 participant