Announcing rubin_sim

Hi simulations and survey strategists!

We announced this at the PCW, and it’s been available for a little while, but here is a more ‘formal’(?) announcement of our switch from lsst_sims software to rubin_sim!

The rubin_sim package replaces the lsst_sims packages. We have dropped support for the lsst_sims packages (ie. sims_maf, sims_featureScheduler, sims_photUtils, sims_utils, sims_catalogs), and are now deploying almost all of the same functionality in rubin_sim, a single python package which is independent of the LSST DM software stack (i.e. you do not need to use eups to set up the software, and you don’t need to install all of the DM requirements).

There were a range of reasons for this move, but the end result we feel is that rubin_sim is easier for us to maintain and easier for you to install and use.

The code and installation instructions can be found here: https://github.com/lsst/rubin_sim

Much of what you’ll find in rubin_sim is what you will have been familiar with before:
sims_maf has become rubin_sim.maf
sims_photUtils has become rubin_sim.photUtils
sims_utils has become rubin_sim.utils
sims_skybrightness has become rubin_sim.skybrightness
sims_skybrightness pre has become rubin_sim.skybrightness_pre
sims_featureScheduler has become rubin_sim.scheduler

The APIs within each package are generally the same as they were previously. Modifying imports in your code from import lsst.sims.maf.slicers as slicers to import rubin_sim.maf.slicers as slicers (and so on) should let the remainder of your code work without additional needs for modification.

A few things are different. We have dropped support for sims_catalogs and sims_catUtils, and there are no corresponding rubin_sim packages. (this is because DESC were already moving away from use of these packages and we - as the Survey Strategy Team - are not scoped for their support). We have also changed how we are evaluating if a given point on the sky falls into the camera focal plane - we now have an LsstCameraFootprint class which uses an approximation of the LSST focal plane map, instead of the full mapping accessed through lsst.afw.cameraGeom – this allows us to drop the requirements on the remainder of the LSST DM stack, so that rubin_sim can be installed independently.

Another difference is in how to download the data files required to use rubin_sim: these are now downloaded with the rs_download_data script, which you run after installing rubin_sim. The download location can be any directory you choose; the version of the downloaded data files is appropriate for the running version of rubin_sim.

We still welcome metrics submitted to MAF; these should now be submitted to rubin_sim – there is a rubin_sim/maf/mafContrib directory which would be a great place to write metrics for a PR.
We also welcome PRs for other areas within rubin_sim!

This is great!

I will probably still use NOIRLab Astro Data Lab because I don’t want to download all the sims! Will that be supported still, or rather, do we still start the Jupyter notebook the same way to load the LSST information?

Related question: is rubin_sim being pushed to NOIRLab’s Astro Data Lab and the LSST Sciserver environment? Or do the people that run those environments need to pull and install rubin_sims? People who have been using lsst_sims on those platforms are going to need access to rubin_sims on those platforms.

Thanks!!

cc @gtrichards and @knutago

I have asked NOIRLab about updating to rubin_sim. Thank you for reminding me to ask about sciserver too.
The project doesn’t run either of these directly, so we can’t update them or push to those environment – they will have to be updated by the groups running them, but hopefully it will be an easy update.

One thing to note regarding the simulations: in the next month we will be releasing the v2.0 simulations, which will be a smaller set than the 1.5-1.7.1 simulations. We expect that the v2.0 set will be what most people will use for evaluations going forward, although if there are specific questions that only are addressed in the 1.x families, please let us know … we’re narrowing down the survey strategy options, so not looking to add a large number of simulations, but if there is something critical to evaluate on the new footprint, etc., we can do that.
Please see the SCOC draft report for a list of the types of survey strategy options under consideration for v2.0 - https://pstn-053.lsst.io