Requirement
DMS-REQ-0341 (Priority 1b) calls for:
Specification: A "precovery service" shall be available to end-users to request precovery for a provided sky location across all previous visits, making the results available within precoveryServiceElapsed [24] hours of the request and supporting at least precoveryServicePeakUsers [10] submissions per hour.
Discussion: This is forced photometry on difference images from each visit. This will include a web interface and scriptable APIs.
Because difference images are not kept beyond the 30-day cache from DMS-REQ-xxxx, this service requires re-creation of difference images from raw (PVIs are also not retained - unless compressed PVIs are considered adequate to meet this requirement), followed by forced photometry.
Assuming that the jobs in fact run over a time close to the 24-hour latency requirement, the possibility exists of having up to 240 (24 hours * 10 requests/hour) such requests "in flight" at any time.
Scientifically relevant options
(A) Given the creation of difference images, the option exists to return postage stamps from them to the user in addition to the photometry.
The requirement says "for a provided sky location". Two thoughts:
- (B) The processing time will be completely dominated by re-creating the diffims, so it may be reasonable to permit a request to include multiple locations within a small spatial region. Because of dithering, this would normally produce a slight increase in the number of images needed; it might be reasonable to consider as eligible anything up to, say, a 20% increase in the number of images processed.
- It will surely be of scientific interest to allow the same processing to be performed for a moving-object specification.
- (C) For high-proper-motion objects this would mainly only need to be accommodated in the forced photometry model; the image selection can be handled by asking for images that intersect with a small circle on the sky rather than just a single point. Is there a simple existing standard we could rely on for specification of the 5-parameter model?
- (D) For Solar System object, this requires a non-trivial and non-Butlerized calculation to be done to determine the appropriate image coverage. Once that is done, the forced photometry centers need to be computed for each epoch as for the high-proper-motion objects. If the user were to request diffim cutouts in this situation, there is some additional complexity involved, as a naive FITS temporal cube becomes a less-suitable output. The target could be specified by reference to a name in a well-known moving-object catalog, e.g., the MPC's, or JPL Horizons, or it could be specified parametrically - is there a good community standard for the latter?
(E) A further option which may be of interest: allowing the user to supply their own SED model to be used to correct the photometry returned. This is straightforward to do when the interface is via LSST's Python objects; perhaps less so if the interface is GUI-based or via Web API, where there aren't clear community standards for how to specify an SED.
(F) Finally, users will be interested in at least the option of running the tool on the Nightly versions of difference images vs. on the Data Release versions.
Traceability
Currently, this requirement is traced back in a very generic way to OSS-REQ-0126 (Level 1 Data Products). It may be preferable to connect it more directly to DIAForcedSource via OSS-REQ-0130 (Catalogs (Level 1)).
Science Platform interface
The Discussion says a "web interface and scriptable APIs" will be provided. This language pre-dates the definition of the Science Platform. In an LSP context, the natural interpretation of "web interface" would be an interface in the Portal Aspect. Providing this capability in the Portal Aspect, according to the current Science Platform design, will normally rely on the existence of a callable Web API in the API Aspect; this in turn should be, as much as possible, an IVOA-style API.
The "scriptable APIs" in the contemporary LSP concept