The TVS SN WG will discuss "Preparing for working with alerts" at their 27 April meeting
Melissa will be present, SN WG has a kickstarte grant - basci stuff - what is a broker
Pictures of the Camera assembled at SLAC - #cam-ir2-ops . Front view of the camera focal plan - can see the colour difference btw ITL vs E2V. Corner rafts are ITL. https://faculty.washington.edu/ecbellm/image/ztf_focal_plane.jpg - ZTF comapre, has a nice pattern.
Follow up onAlert Distribution handover to Ops & Descoping the AFS
Eric, Leanne, Bob met with the ANTARES team to propose that ANTARES take on the finctionality of the proposed Alert Filtering System (AFS). Summary of the points discussed:
Agreement that the best course of action now following the Broker seleection is to explore how ANTARES could provide the functionality of the Rubin Alert Filtering Service (AFS) and not for Rubin to implement its own AFS.
Close cooperation between Rubin and ANTARES to provide AFS functionality is not expected to be problematic for our relationship with the wider community now that the Community Broker selection is complete and that all proposing brokers were accepted.
We will look to loop SNAPS in to the plans for solar system moving objects. ANTARES work closely with SNAPS already (based in Flagstaff, AZ).
There is no latency requirement on the AFS (OTT1)
Respective directors, Bob and Adam will work out the 'colour of money' issues
Eric and Leanne have started a TN to describe how we see this working with ANTARES https://dmtn-226.lsst.io/ Deadline for solid first draft of the is end May 2022.
Some formal agreement between NOIRLab, NSF, Rubin will be needed.
Goal is to avoid messing with the SRD - could strictly descope the AFS but we would need to touch the SRD. This partnership with ANTARES is positive
RHL/LPG - propose to draw boundary between commissioning and what the Alert Brolerss will deliver. Commissioning will deliver the contents of the alert packets, reveiwing the alert brokers this is outside the commissioning scope. Likewise fo the RSP - we commissionin what goes into the RSP but not how the community will work with the data products via the RSP.
EB - supportive of this - alerts will not coming fast during the cmn period. Look for best-eforts opportunities. Alert brokers being able to handle our stuff is out of our control.
EB- Need a clear story about technical support for brokers - not the but how does this flow? Need to flag as activity.
How closely will brokers work with Rubin? CET will help to support Data Production piece to make sure that the brokers can receive the stream. During comissioning, the AP tean who built the system will be supporting the brokers to get commissionined. Expectation is that this will not be a lot of work based on success running on ZTF
CS : Need the Spencer Nelson replacement.
LPG: Can we look at starting to bring in ops people.
EB: Want this person at SLAC - make sure Richard is aware of this need.
CS: Work with ANTARES - but aren't we just handing it over?
EB: Need to clarify and look at existing requirements. ANTARES is not sorting solar system data (working with SNAPS). ANTARES operational model is more operationally heavy - someone looks at filters and makes sure that they are OK.
CS: Are there requiremetns coming back on to us?
EB: Did not see anything coming back on to us - does not seem likely.
CS: No plans to emesh ANT in the RSP - No.
Discussed the possibility of a fork that we run but we prefer not to do that.
Leanne Guy talk to Ricard about support at SLAC for brokers during commissoning Discussion here
Eric Bellm Provide a clear story on technical support for brokers during commissioning Ticket is:
PREOPS-3254
-
Getting issue details...STATUS
DPDD requirement to measure aand alert on a limited number of sources detected below the nominal threshold
The Strong Lensing SC (SLSC) have requested support for a grant proposal for a value-added cut-out service that runs on the USDF in parallel with nightly alert generation for a predefined set of coordinates.
The DPDD states: ", the system will have the ability to measure and alert on a limited number of sources detected below the nominal threshold for which additional criteria are satisfied. For example, a transSNR = 3 source detection near a gravitational keyhole may be highly significant in assessing the danger posed by a potentially hazardous asteroid. The initial set of criteria will be defined by the start of LSST operations
Looking for string lensed Kilonova events - they claim these will be hard to detect in the standard process. They are below the detection threshold - they see these because there is a strong lens. LIGO in a few years will be strong enough to detect these.
Want postage stamp cutouts for areas of sky where they know there are strong lenses on large 2 arcmin scales
SLs for predefined locations seem to be a good example of the intent of the DPDD requirement
Can we bump up the cutout size?
Future possibility - can we start to run some of their code. We are not ready, neither ar they. They want to propose for funding to run in that manner.
We need to come up with a proposal aparatus for this DPDD requirement
JB requested the SLSC to provide some text for us to approve in their proposal
RHL: we already recover positions of old transients so there is no technical problem - what is the cap? 10/15 %?
LPG: DPDD says no less that 10% of average DIASource per visit rate.
EB: not just the number but also the process of seelction - SL case of specific regions is straightforward and easy to implement. Need to define technical boundaries on what we would allow.
LPG: Propose to make the determination of what is scientifically useful the responsibility of the SC chairs or similar scientific body
EB: What community can request this?Bob has talked about the NOIRLab TAF - is this the SC or a more general community responsibility?
CS: SLSC case is that the sceince is such that we need to do it in this way. Wary of proposing a new feature and so worry that everyone will want to use this to say, measure 16th mag star. Set the bar high - define this for cases that cannot be done in any other way.
YAS: request from the AGN SC (extra galactic variability ) at LINCC - they don't need postage stamps - they want Forced Photometry during prompt processing of a list of objects of interest - this could be up to 20millions.
JB: Must be something timely, e.g KN events(NSNS fade in a day) If it can wait loinger - can do at a DF. e.g SLAC
EB - diff between forced photometry on existing DIAObject and alerting on these lists. Former is not sent as an alert - latter does - goes out and takes bandwidth.
CS: All depends on the level of complexity/sophistication. Some are simple to productionize. e.g ingest a list. AGN case seems like more effort.
EB: Write down what we think the science needs are that require this - sub 24h - will get forced photometry from the daily PPDB update for everything that has been varying, or requires the use of the pixels.
... but full WL analysis is out of scope. Look at how many sources we are tracking. Need to put bounds on things.
Procedure / process?
JB: Don't need a stong spec. But who do they propose to and who do they get endorsement to to get money. Similar processes. Not a special program - similar to PZ
MG: Like PZ we need to clarify the boundaries - but this is a different case in terms of science prioritization.
MS: Host association - also said we'd take a list of hosts within a certain effective radii - whose list? Similar use case to this
Robert Lupton Clarify the meaning of time in the object table. 1 sentence description in sdm_schemas, can link to a short DMTN. Update 2022-02-09: Meeting to resolve this on 2022-02-21
Leanne Guy Prepare to consult the PST on the question of providing compressed PVIs for AP outputs, to cover the period before the data become available in a DR.
Parker FagreliusPatrick Ingraham how long will it take to do a scan as described? No need to scan the whole WL range but will require additional points outside nominal lambda range.
Eli Rykoff , Leanne Guy Develop a proposal for what calibration processing, hardware, data we actually need and what will be needed for DR1. This has implications for the ORR and for prioritisation of work in commissioning
