Transiting Exoplanet Survey Satellite December 8, 2014 TESS Kickoff

Agenda  Previous reviews and meetings  Plan for CDR  Confluence “TESS Data Archive” site 2

Reviews and Ground System Meetings  History  Mission SRR – February 12-13, 2014  Archive Peer Review – June 18, 2014 One RFA to close by next Peer Review (Feb. 12, 2015)  Mission PDR – September 9-12, 2014 One MAST related RFA assigned to Project  SOC Hop – November 3-5, 2014 ICD discussion – still on-going  Upcoming  Archive Peer Review – February 12, NASA/Ames  Mission CDR – April or May, Orbital Sciences in Dulles, VA 3

4 Name: Susan Thompson Title: SPOC/MAST Interface: This interface needs additional work before the PDR (for example, XML file content and list of delivered products). Action (or recommendation): The MAST should start development now for the TCE delivery they are expecting for this mission. They need to work with the TSO and the SPOC to find a meaningful way of presenting that data for public consumption, for example, how to allow community scientists access to all the transit information in the xml file and how to document all the data in the xml file. It was not clear that MAST understood all the file types that were going to be delivered from the SPOC, nor all the data files that should be archived for permanent storage, even if they were not processed by the SPOC. A full list of these, along with the agreed upon formats, should be made now to ensure that all the information flows to the archive in a useful format before the end of mission. It would also be useful to identify who is responsible for writing documentation for any of these products. Supporting Rationale (or issue) if any: The TCE xml file is a new delivery between the SPOC and the MAST for TESS. The MAST did not receive the xml file for Kepler and more work will need to be done to fully optimize this data product for use by the community. Archive Peer Review RFA

5 Name: Michael Davis (SwRI) Title: Handling of Post-Observatory Data Products Action (or recommendation): All post-ground observation data products collected by co-Is should be delivered to MAST, whether the observations are funded directly by the TESS project or not. Currently, only co-Is directly funded by the TESS project are obligated to deliver data products to MAST. Supporting Rationale (or issue) if any: The final mission science results from the follow-up ground observations. 36% of the targets identified by TESS for further observation are due to be observed by collaborators/co-Is that are not directly funded by the TESS project. Only co-Is funded by TESS are contractually obligated to deliver their results to MAST. While it is unlikely that a non- funded co-I would hold data back from MAST, there should be some mechanism in place to prevent data non-delivery. If someone wants the title of co-I and the prestige and additional visibility in the community that brings, they should be obligated to deliver project data to the archive. PDR RFA

Tasks for Peer Review/CDR 1. Complete the TESS Archive architecture  Decide on the data receipt work flow  Select data storage options 2. Develop the archive catalog schema using the ground segment ICDs  This should be similar to the Kepler archive catalog schema with TESS updates. 3. Prototype the data retrieval interface using the ground segment ICDs  This should also be similar to the Kepler interface with TESS updates. 4. Prototype the user interface for the data products that MAST does not hold for Kepler  Threshold Crossing Events  Data Validation Reports  TESS Objects of Interest lists  Follow-up Observation data 6

TESS Archive architecture  We will use a simple Condor/OWL pipeline for data receipt and archive ingest.  DPAS would be responsible for running the TESS pipeline.  Pipeline software development on the Condor/OWL pipeline is not necessary for CDR.  Data will be written to the online cache, skipping DADS and Safestore. Without Safestore ITSD back-ups will be necessary.  Data ingest will include CAOM.  It would be cost effective to buy into the ESX VM hardware used by other missions (HST, Kepler, MAST, and JWST). Permission to use the hardware needs to be obtained.  Resources: Scott Fleming and Shui-Ay Tseng because of their experience with Kepler ingest to CAOM. Brian McLean should also be consulted on the CAOM. 7

Archive Catalog Schema  This should be similar to the Kepler archive catalog schema with TESS updates.  Use TESS Data Products Specification  NASA/Ames Author  Resource: Shui-Au Tseng 8

Data Retrieval Interface  Use the MAST portal only.  Prototype should be similar to the Kepler interface with TESS updates.  Test data from TESS would be useful, but Kepler data could be renamed.  Resources: Randy Thompson and Karen Levay 9

Archive User Interface  Prototype the user interface for the data products that MAST does not hold for Kepler: Threshold Crossing Events, Data Validation Reports, TESS Objects of Interest lists, and Follow-up Observation data.  MAST mirrors NExSci data products for Kepler.  Kepler NExSci data products are being converted from PDF to FITS format data so metadata can be ingested for searching.  TESS versions of data products must be searchable.  Resources: Scott Fleming and Dorothy Fraquelli 10

Follow-up Data  Guidelines for observers to submit follow-up data to MAST should follow the guidelines set by MAST for contributed high level science data products.  Submission rate and volume?  Notes from 12/8/14 meeting:  Automate follow-up data ingest with Condor/OWL pipeline  Determine the type of follow-up data: Spectra can be easily handled Catalogs and other different products may require more effort  Daryl to get a list of follow-up data participants 11