LSST Science Advisory Committee phonecon Thursday, June 16, 2016 Attending: Michael Strauss, Anze Slosar, Beth Willman, Timo Anguita, Niel Brandt, Risa Wechsler, Renu Malhotra, Amy Mainzer, Jason Kalirai Nelson Padilla, Charles Liu At the end of May, the SAC sent the LSST Project Office a report consisting of a series of questions, comments, and requests on various topics we have been discussing over the last few months, including plans for science operations, Level 1 alerts, and data releases. This report was posted to the SAC website. Today's discussion was led by Beth Willman, LSST Deputy Director, giving responses to these various issues. *******Science Operations Plans***** We responded to Beth's request for feedback on the Science Operations and staffing plan to say that it looked sensible, although the plans were not detailed enough, and we didn't have all the relevant expertise, to give a detailed critique. We did point out a concern that there may not be enough attention paid to documentation. Beth explained that there was a single FTE in her plan, a point person coordinating the documentation effort, but that the responsibility for the actual writing would be spread out among many people throughout the project, i.e., those most familiar with various aspects of it. In answer to a question, Beth explained that the help desk would be open to all those with LSST data access. It would be in English, with a possibility of support in Spanish as well. Nelson Padilla and Timo Anguita (both from Chile) said that English would be fine for professional astronomers in Chile, but pointed out that school teachers, for example, who wish to use LSST for educational purposes, would need support in Spanish. Beth explained that support for EPO activities would be through a separate part of operations, but said that work was needed to flesh out the concept of a help-desk analogy for EPO; they have been focused on chat websites, similar to what Galaxy Zoo does. The question arose whether there may be a mechanism to request that a query to a help desk be kept proprietary. For example, somebody has discovered what appears to be a really interesting object, and asks if there are any concerns about the photometry at that position. She said that this is not part of the current model, and we agreed that because LSST data are not proprietary, the case for keeping queries explicitly hidden was not strong. This brought up the next question, whether questions to the help desk would be cataloged publicly. They will certainly be used to develop FAQs and related documentation, but it is not yet clear whether all queries will be available publicly. We discussed the various mechanisms by which the community would be able to give input to the project during LSST operations. Beth envisioned both a user's committee as well as a cadence committee. It is not yet decided whether there was also need for a separate Science Advisory Committee, perhaps acting as an umbrella to these two committees. Overall, Beth was satisfied with the feedback we had given her on the science operations plans, and will come back to us, perhaps in roughly six months, as that plan becomes more fleshed out, for further feedback. *****Level 1 alerts: In our report, the SAC raised a variety of concerns about how Level 1 alerts would be distributed in practice, and what the role of the event brokers (which would be the mechanism by which one could get information about alerts in close-to-real time) would be. Beth clarified a number of aspects of this that we hadn't understood fully. First, within 24 hours of a given exposure, all information about a given alert would be loaded into the Level 1 database, to which all people with LSST data rights would have full access, with no need to go through an event broker. Please see the LSST Data Products Definition Document, Section 4.3, https://docushare.lsstcorp.org/docushare/dsweb/Get/LSE-163/ for a full description of what will be included in a given alert. There is a nice description of this in the presentation Mario gave to the SAC in March (see https://project.lsst.org/groups/sac/sites/lsst.org.groups.sac/files/LSST-SAC-Brokers-And-DRs-1.pdf). See also a technical note from the DM team on the Level 1 database design for use in the alert production pipeline (https://dmtn-018.lsst.io). The LSST DM overview paper, http://adsabs.harvard.edu/abs/2015arXiv151207914J and the LSST overview paper, https://arxiv.org/pdf/0805.2366.pdf (the LSST overview paper) also make reference to the LSST alerts. Second, the LSST itself will run its own limited event broker. It will do no screening, filtering or classification of the events themselves, but one could run simple filters on the information associated with each event to identify objects of interest. There will also be an additional 3-4 community event brokers, a number limited by bandwidth considerations (see below). Mansi Kasliwal had mentioned in a previous meeting that she knows of 5-6 groups that wish to produce event brokers, either for their own science needs or to serve the broader community. The LSST Project will need to set up criteria to decide whom to allow; presumably those with a mission to serve as a broker to members of the LSST community will be . This is a discussion that hasn't yet happened; the SAC expressed its eagerness to help think through this process. Given roughly 50 KB of data associated with each alert, and of order 10,000 alerts for each 30-second visit of LSST, and the requirements to push the alerts out in ~5 seconds, the data stream associated with alerts is roughly 1 Gbit per second. This is large enough to really limit the number of event brokers that can have access the data stream. We did not have an immediate use case in which the combination of the LSST event broker, plus those developed by the community, would not be adequate. This is a topic we should discuss further; we are looking into the possibility of a breakout session during the LSST2016 meeting in August on this topic. We could also invite Tom Matheson to give a presentation at a future SAC meeting to describe the NOAO event broker effort. ****Data Releases**** In our report, we wrote: -It is important that all LSST data releases be kept spinning (or at least accessible via tape robot in a user-friendly and database-enabled way) through the life of the project. This is needed to allow published results to be reproduced, and to make sure that science projects started with a given data release can be completed. Statistics from SDSS show that data releases even from many years previous continue to be accessed at a substantial rate. Beth pushed back to ask us what latency would be acceptable for access to old data releases. We agreed that making old data releases available in a user-friendly way, but with longer latencies (say a week) may be acceptable. Mario Juric had estimated that the hardware costs to spin these data would be modest, but there are additional costs, not yet quantified, for the people needed to maintain that software. The SAC argued that keeping the *first* data release spinning for the life of the survey could be valuable, as it will be a useful comparison point as the survey and the software progress. The report also stated: -The Project should prepare a detailed description of the alerts and data release plan, to be made available to the LSST community. There is a lot of misinformation and confusion on these topics, even among the SAC members. Beth explained that the Project Office would like to prepare appropriate documentation, but is overwhelmed with other responsibilities. She is interested in updating the LSST FAQ page, https://www.lsst.org/scientists/scientist-faqs to include more information on this topic. The Project Office will be getting new scientists on-board who can help on this. All of this can be a topic for the LSST2016 meeting. Finally, the report stated: -The LSST Project should prepare a plan by which LSST data will continue to be available after the survey itself ends. This is an unsolved problem in existing large surveys (e.g., SDSS), and the community will need access to LSST data for decades after 2032. Beth explained that the LSST operations operations plan will go through 2033, allowing one year to reduce the last year of data. The long-term curation of the LSST data is an important question, but one whose technical solution in 2033 couldn't be really guessed now (consider where data storage/database technologies stood 15 years ago!). This will have to be addressed in a future discussion/proposal with the funding agencies. ******LSST2016: The LSST SAC will meet face-to-face in the afternoon of Monday, August 15, during the LSST Project and Community Workshop (LSST2016) in Tucson (https://project.lsst.org/meetings/lsst2016/). We started a discussion of possible agenda items. They include: -The status of the LSST cadence development (in the context of the on-going development of the Cadence White Paper), and discussion of the mechanisms by which cadence decisions will be made. -On a related note, how decisions will be made about the Deep Drilling fields and other auxiliary programs. How are the Deep Drilling Fields currently implemented in the OpSim? -A presentation on the current status of the LSST Science User Interface, being developed by David Ciardi and his colleagues at IPAC. -Brainstorming the scientist FAQ on the LSST website; please see above. -An update on the status of the camera sensor procurements and the mixed focal plane scenarios. -A discussion of what the key advances in transient science are likely from LSST in a post-HSC, post-ZTF landscape. -Discussions with the science collaborations on various issues, including looking at data from current surveys reduced with the LSST software stack. Additional ideas are very welcome!