You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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:
{solar_system: <true|false>}
, propagate this to the SP filtering extension{solar_system: true}
(see https://docs.fritz.science/user_guide.html#upstream-aggregation-pipeline-stages) that would:candidate.ssnamenr
is not null andcandidate.distssnr
is < 2 or something similar.candidate.ssnamenr
(and notprv_candidates
as for transient filters)magpsf
time series and report the "predicted" value?candidate.ssnamenr
and notobjectId
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:
candidate.ssnamenr
that is not null andcandidate.distssnr
that is < 2 or somethingcandidate.ssnamenr
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
The text was updated successfully, but these errors were encountered: