some comments here for you from UK and Lasair view, with a focus on the questions you raised in some of the sections (Q4.1 below refere to Question raised in Section 41. etc…)
Agree with Eric’s assessment : alert packet timeseries features need not be as extensive as the DRP timeseries features. Variable star features are much more useful in the DRP. Agree that disparate feature sets in the AP and DRP are not a problem and users will get used to those.
Would note that on the statement “only objects that vary relative to the template image will produce
This should more accurately read
“only objects that vary relative to the template image (by at least 5 times the noise level in the input image, assuming the input noise dominates over template) will produce
Otherwise there will be no
DIASource and no measurement or data point (apart from ForcedPhot). Hence the alert LC will be sparser than the DRP (as noted in Section 4.10).
Q4.2 & 4.3
For transients, our thoughts would be, to run a simple Bazin (or similar) lightcurve fit, and report the parameters in each band. This will allow users to combine the information from multiple bands whatever way they like.
Fairly basic statistics such as latest
dy/dt (where y is either flux or mag), will be very useful. I (Stephen) would be willing to look more carefully at exactly what statistics are provided and how they are computed. Example variations would be :
- when three epochs exist, then 2 values of
- colors (when multiple taken on same night)
- latest mag (and/or flux) in each filter (and MJD of that)
- peak mag (and/or flux) in each filter (and MJD of that)
Careful attention to the errors and the
dt intervals are required, since two low significance fluxes separated by 2-3sigma on the same night (
dt is small) lead to spuriously large
The basic statistics should be run when there are at least 2 data points. For the basic model fits (e.g. Bazin), agree with the document, that empirical checks on how many points are required should be done. When minimum reached, then run the fit.
For Lasair - we recognise Eric’s words in Section 4.3.1. This basically says lightcurve classification of periodic and aperiodic stellar Alert data in LSST is not particularly useful. It is much more of a DRP problem./solution.
Agree with Eric’s thoughts here. Main question is where responsibility lies (Rubin/Broker/user)
For transient like objects (which means no underlying stellar source), a parametrised fit such as the Bazin model (or similar) would suffice from Rubin. This is a way for users to select sources of interest through a broker, and then to extract the lightcurve data for their own model fits. An example would be :
- Give me all transients not coincident with stars, with a peak flux constraint (e.g. brighter than flux equivalent of m=23)
- Find most likely host galaxy and get host photoz (or existing specz) from Lasair
- Make a selection on the Bazin model parameters from the latest fits
- Design a query to get all lightcurves of objects that satisfy the above
- Run their own SALT2 models on all of these lightcurves
So the Rubin AP content would allow a user to do 1-3, and a Broker would facilitate 1-3 through 4, and
also provide the storage and compute for a user to run 5.
Does that help you ?
This is important point - there are arguments to use the forced photometry fluxes in the transient parameter fit, as flux measured below 5sigma can significantly contribute information. Where possible, we would always recommend using the forced photometry fluxes. This is from experience of comparisons of early fitting/classifications from forced and non-forced.
But it does need done relatively quickly - at the same time as the forced photometry is triggered.