Survey Simulations v2.1 (April 2022)

The v2.1 simulations include a focused dive into Deep Drilling Field scheduling, with a series of different options in ddf scheduling options, as well as refinements on the galactic plane coverage, options regarding ensuring ‘good seeing’ images in different bandpasses, and a variety of other smaller investigations. These simulations are intended to be considered in concert with the v2.0 simulations (announced here).

The v2.0 and v2.1 simulations are described in more detail in the SummaryInfo_v2.1 notebook, but a brief description of the questions addressed include:

  • varying the extent of rolling cadence
  • varying the intra-night cadence (triplets or pairs, what kind of separation between visits)
  • varying the coverage of the Northern Ecliptic Spur region
  • varying the coverage of the galactic plane (non-bulge) region, as well as the footprint of coverage within the galactic plane
  • varying the exposure time in u band and the number of bluer (u and/or g) band visits (relating to filter balance)
  • varying the exposure time
  • varying the number of ‘good seeing’ images required in various bands in each year. Note that v2.1 adds ‘good seeing’ images in r and i bands each year by default (baseline_v2.1_10yrs).
  • investigating the effect of suppressing repeat visits within each night, beyond the original pair (we found that about 10% of nights have more than a single pair of visits in the baseline)
  • varying the amount of time spent in Deep Drilling Fields, as well as their cadence. Notably, the v2.1 runs introduce a new method of planning DDF visits that pre-schedules the visits to take the best advantage of the lunar cycle … in a variety of versions, explored in the various ddf families.
  • microsurveys, where additional small special projects are added to the simulation in v2.0:
    • Extending the WFD to cover the Virgo cluster – note that this was so low-impact to the remainder of the survey and such a slight modification to the WFD region, that it was added to the baseline in v2.1 (baseline_v2.1_10yrs).
    • ToOs for GW optical counterparts - these ToO observations are intended to show the general impact of ToOs, however the plan for coverage is still evolving.
    • Twilight NEO discovery visits - these will need another round of simulations, to conform with constraints on the camera shutter rate.
    • Short (1-5 second) exposures over the sky
    • Coordinated observing of the Roman microlensing bulge field
    • Limited coverage of a northern stripe not otherwise observed, up to Dec=+30
    • High cadence visits to the SMC

The v2.0 and v2.1 simulations include 265 runs.

The MAF analysis of these simulations is available at
In general, the MAF analysis outputs are split into subsets to aid in finding particular ‘kinds’ of metric outputs:

  • the “Science” category (‘mafComment = Science’) contains primarily metrics that are higher-level science-focused; many of these are the metrics contributed by the community
  • the “SSO” category contains metrics focused on solar system science; these would be in the Science category, except that we generate them separately so they get their own separate page
  • the “DDF” category is only available for some of the runs, but contains metrics focused on DDF visits; these are particularly useful for the DDF family simulations
  • the “Metadata” category contains metric outputs that describe primarily basic details about the observations and how they were taken - things like the airmass distribution, coadded depths, intra-night visit gaps, etc.
    The summary statistics computed for each of these metrics is shown with the metrics, but also collected into a big CSV file which can be found here - summary_2022_04_28.csv
    The CSV file can be used, optionally together with the runs_v2.1.json file and the metric_sets.json to investigate the families of simulations - see this example tutorial or this demo (and others in this same repo) to see how to use these files with some tools from MAF to investigate the outputs of these runs.

The opsim outputs can be downloaded at
or Index of /sim-data/sims_featureScheduler_runs2.0
Index of /~lynnej/opsim_downloads/fbs_2.1
or Index of /sim-data/sims_featureScheduler_runs2.1

Thanks for this summary. Are some of the Solar System metrics still running? I was getting this when plotting the new Euclid DDF simulation?

We didn’t run the solar system metrics for every DDF simulation. There are so many of them and we didn’t expect significant variations in solar system metrics when the overall amount of DDF time was held constant.
I thought they were run for the euclid_moved simulation though, so I’ll double check on that.

Thanks for clarifying @ljones . That makes sense. When there’s a final version of the v2.0-v2.1 csv file will it be zenodo-ed so there’s a permanent copy that can be cited in cadence papers for theAAS journals LSST cadence focus issue?

Also it would be helpful if the summary jupyter notebooks for 1.5/1.7, and 2.0/2.1 could also be given zenodo DOI links. I was sitting in an online workshop of reproducible science and it was pointed out that this is a good idea since it means that folks can accurately cite the notebooks and it lives on if the repo with the notebook ever changed or was removed. See Guidance for AGU Authors - Jupyter Notebooks | Zenodo

This would help myself and hopefully others writing additional papers can cite the notebooks which have been so helpful and they would be preserved for time.

I also have a similar question about the opsim/rubin_sim output databases. Is the permanent storage for these at the NOIRLab Astro Data Lab?

Meg, these are great questions.
We have no control over the data storage at NOIRlab, although we hope they will continue to provide these databases as part of the copute facilities. We also can’t control exactly where NCSA hosts the output databases, although it is relatively stable and I think is where I’d say it’s most likely to continue to be so (where you can download the outputs from Index of /sim-data). The UW links to download the databases at Index of /~lynnej/opsim_downloads are dependent on the continued existence of the “epyc” machine. Thanks for making me think a little more about this, though – I suspect the only place we can guarantee permanent storage is in the LSST Docushare, so I will see if I can upload copies there.

We can add zenodo links for the various summary info notebooks (I think this is what you mean?) but we did not build these outputs with the idea of them being permanent references and so some of the links contained in the notebooks do change (primarily - what we host on is the current set of simulations under consideration, and we put the previous set on The DNS is not permanent: if astro-lsst-01 (our machine at UW hosting these resources) were to fail, I don’t think we’d be guaranteed to have a new host with the same name.
I’d prefer to wait until we’ve gone through a round of consultation with the community on the current set of notebooks and summary CSV files … there are things we don’t notice being incorrect or missing until looking more closely with the community, for example. But yes, it’s a good idea to add a zenodo version of those outputs.

Hi Lynne.

Thanks for considering my requests.

We can add zenodo links for the various summary info notebooks (I think this is what you mean?) but we did not build these outputs with the idea of them being permanent references and so some of the links contained in the notebooks do change (primarily - what we host on is the current set of simulations under consideration, and we put the previous set on

Yes. That’s what I meant. With the summary notebooks, they might not work any more because links to the data files might not work, but at least the reader could see what content was in the notebook in 5 -10 years if it is in Zenodo. I don’t think you have to promise they run, but that at least someone can open the notebook and read through the descriptions of the simulations and look at the plots. My concern is for some reason that github repo is removed, those notebooks are lost in the long term, and the community is all using them to understand what each simulation is. Also if we’re all using this as a reference, we should cite a permanent version of it.

The problem of continually waiting is that if I write a paper and submit it in July then I have to cite a github url. With Zenodo you can update versions so all that information of revisions is tracked.

Which DOI should I use in citations?

You should normally always use the DOI for the specific version of your record in citations. This is to ensure that other researchers can access the exact research artefact you used for reproducibility. By default, Zenodo uses the specific version to generate citations.

You can use the Concept DOI representing all versions in citations when it is desirable to cite an evolving research artifact, without being specific about the version.

See Zenodo’s discussion of versioning.

I get the v2.0/v2.1 simulations summary notebook is still evolving a bit. What about starting with the v1.5/v1.6/v1.7 summary notebook?

Hi Lynne, I assumed that updating my rubin_sim and then running ‘rs_download_data --force’ would get the new baseline_v2.1 files, but this is not the case, the uploaded data version is always sim_baseline_nov_2021.tgz. What is the simplest way of updating everything in my rubin_sim_data? Thanks!

Actually, I don’t think this is incorrect. It looks like baseline_v2.1_10yrs.db hasn’t been added to the sim_baseline data download yet, so I will go and do that now! Thanks for the heads up.