Candidate Reference Run, minion_1016

A new candidate Reference Run, minion_1016, is being proposed to the LSST Change Control Board as a replacement for the current Reference Run, opsim3.61. An announcement will be issued here when it is approved.

The purpose of this post is to clarify some of the terminology that is used to describe simulated surveys generated by the Operations Simulator (OpSim).

  • A “Reference Run” or “Reference Simulated Survey” is a specific simulated survey generated by a specific set of configuration files with a specific version of the OpSim code.
  • A “Candidate Reference Run” is a specific simulated survey that is being (or will be) proposed to the CCB for approval as the new Reference Run.
  • The collection of configuration files which completely specifies the cadence for each science goal (proposal) in the Reference Run is referred to as the “Baseline Cadence”, or “Baseline Observing Strategy.” Very often a set of simulations consisting of variations in the parameters of the Baseline Cadence is generated to explore a particular science objective.

There are two types of proposals (observing modes) used by OpSim and they are employed in three different ways in the Baseline Cadence. The two types are area distribution (WL) and time dependent (WLTSS).

  1. Area distribution (weakLensConf or WL) observing modes consider how many field/filter combinations are requested versus how many have been accumulated.

    • The GalacticPlaneProp.conf and the SouthCelestialPole.conf proposals collect field/filter combinations with no regard for timing or cadence, simply the number of visits to a field in a particular filter.
  2. Time dependent (WLpropConf or WLTSS) observing modes can have complex cadence requirements in addition to field/filter observations requirements.

    • The WFD.conf (WLTSS type; Wide-Fast-Deep, formerly known as Universal.conf) proposal is the primary way the WFD observing program has been simulated. The WLtype = True statement makes the proposal collect field/filter visits in tuples set with NumGroupedVisits = n, where for minion_1016 this is 2 for a pair (with the separation set by the window parameters), but otherwise does not consider cadence. It currently cannot use look ahead. The NorthEclipticSpur.conf proposal (covering the “north ecliptic spur”) is similarly designed.
    • The DDcosmology1.conf (“deep drilling”) proposal is of the WLTSS type but has a more complex temporal implementation. This proposal collects sequences of observations in 5 selected fields for cosmological studies. There are two sets of sequences since the science requests all 6 filters and only 5 are mounted at any time. Once the sequence begins it is not interrupted.

More details of about the parameters in the configuration files may be found at http://ops2.lsst.org/docs/current/configuration.html

A new Operations Simulator (OpSim) Reference Simulated Survey, minion_1016 has been approved and placed under change control. A Reference Simulated Survey (or Reference Run) is a technical designation and is a demonstration of the primary capabilities of the OpSim v3.3.5 codebase. Many more features and enhancements have been added to the OpSim code (currently at version 3.3.8), and will be detailed in an upcoming paper. The Reference Run, minion_1016, is a replacement for opsim3.61. Preliminary analysis (linked from the LSST Website ) shows there are no major problems with its performance, but there are known issues which will be addressed in future releases. The OpSim (Opsim3) code is being rewritten into the Simulated Observatory Control System (Opsim4 or SOCS) for use during LSST Operations. The first major release which will reproduce the current capabilities (and include a few important enhancements) is scheduled for later this year. A release schedule and instructions on how to install and run the code are linked from the Simulations pages on the LSST website. The strategy and algorithms which will guide the survey during Operations are still under investigation. A white paper is being written by the community outlining various science cases and the impacts that observing strategy (“cadence”) will have on them, quantified using the Metric Analysis Framework. Check out the Observing Strategy github repository for more information on how to get involved.