Known asteroid photometry and lightcurve from public alerts

[brycebolin]

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.

[dmitryduev]

We would need to track candidate.ssnamenr (see https://github.com/ZwickyTransientFacility/ztf-avro-alert/blob/master/schema/candidate.avsc) and not objectId, which would be different for essentially every detection. I'll need to index the ZTF_alerts collection on K on that field and add functionality to our filters to track that and post to the proper place on SP.

[stefanv]

@dmitryduev Is the procedure above something you intend to implement, or does this require further discussion?

[dmitryduev]

@stefanv this is fairly straightforward and I don't think this requires further discussion.
Started building the index on candidate.ssnamenr.

[dmitryduev]

There is now an index on candidate.ssnamenr, so pulling alerts by that is very fast.

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.

[dmitryduev]

@brycebolin @AshishMahabal as you can see, it's all very doable, but there's quite a bit of work to do.
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.

[AshishMahabal]

@dmitryduev Thanks. 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.

[mcoughlin]

Closing and opening here: fritz-marshal/fritz#431