We have a released a set of v5.0 simulations, in response to early commissioning feedback.
In all v5.0 simulations (except the “two_snap” simulation), exposure times per visit are 1x30s in grizy and 1x38s in u. This is in accordance tests with single-snap visits from early commissioning with LSSTCam.
The default Deep Drilling Strategy has also been updated to the “ocean” strategy, where most sequences in the DDF are much shorter (a handful of exposures in two or three out of the ugrizy bands, alternating with the remaining bands within a night or two) but much more frequent; for each DDF, there is also a season (~year) where the sequences are much longer (over one hundred visits in each sequence) while remaining relatively frequent. The total number of visits per DDF is approximately the same as in previous simulations, but the visits are distributed over time quite differently.
The slewtime has been increased, attempting to incorporate some early indications from the TMA performance … we anticipate that this will change as we move further from commissioning into operations, but by incorporating a slower-than-previous baseline speed we hope to preserve a better match with average survey performance.
Slides describing the general changes with v5.0 were presented at the RCW.
baseline simulations - there is both a baseline_v5.0.0_10yrs and baseline_v5.0.1_10yrs, reflecting small software changes in rubin_scheduler, which should not statistically change the output simulation
baseline_production simulations - these should be very similar to the baseline, but are run with a configuration more like what we need to actually use for the summit. This is essentially a code reorganization, however there are some small additional changes such as adding azimuth constraints at the end of the night (consistent with summit performance requirements at present).
four-roll - rolling cadence but with four cycles of rolling instead of three, so no uniform seasons
two-snap - what if we did 2x15s visits … primarily for comparison to previous simulations
ddf_dither - this tests different sizes of dither offsets. These dithers are only changed between nights.
ddf_all_dither - this tests different sizes of dither offsets, including dithering within each night. Note that we almost certainly have to adopt this method (especially with the deep sequences), and we will almost certainly need at least a range of 0.2 degrees in dither sizes due to scattered light.
variations on the DDF ocean strategy -
ddf_acc (an accordion strategy added on top of the ocean shallow sequences)
ddf_acc_short ( accordion but making the shallow seasons shorter than in ddf_acc)
ddf_acc_early ( like the accordion strategy, but moving all of the deep seasons as early as possible - this strategy would acquire the bulk of the DDF visits within the first half of the LSST).
variations on template acquisition - production_templates_y1 is the most relevant here. This adds a template tier during y1, configured to attempt to match template requirements we saw during commissioning.
Thanks! I have a question about the baseline simulations. Just to be sure: the first year covers the sky uniformly and afterwards it follows a rolling cadence with a period of 3 years (1.5 yr per active region). Where can we find the exact definitions (coordinates) of active/inactive regions? We could infer them from the map, but it is better/easier to know what was actually used in the simulations.
There is a map here - Wide Fast Deep (WFD) — Observing Strategy
Are you looking for more exact information on the declination boundaries of each region? This varies a bit depending on RA.
Can you use the healpix map that would be returned by what @yoachim demonstrated above?
We very seldom take the healpix maps and turn them into the explicit dec values … so we could do that, but it will take us a little while due to other priorities.
If you’re interested in the time sampling of particular points on the sky, I would suggest looking into some of the other MAF tools and using one of the simulations to check the cadence at that point (see for example this tutorial notebook on examining visits at a single point).
While I am simply an avid astronomy fan, and haven’t tried what you’re doing with rs_download_data --dirs,
I know a lot about online collaboration and the github tool that Rubin leverages for both code and documentation.
Notice in the upper right-hand corner of the Data Download page, an Edit on GitHub link.
It takes you to this page:
where the original source text for the document is maintained.
If you go there, you’ll find a rather straightforward way to actually make the change yourself and propose it via a pull request to the Rubin folks. I dare say they would quickly incorporate the change, and you’d get credit forever as a contributor to the documentation.
I can give you more tips if that’s confusing. Or if you would prefer, I would be happy to do that myself, but I figure it would be rude to jump in and get credit for the update.
In general, I’m very impressed by and grateful to the Rubin community for using such excellent tools and making it easy for anyone to collaborate on the monumental project.
Hi @yoachim i try to run your notebook for the rolling boundary and i have a problem in the settings but i dont know how to fix it, the message error is