attending:
Agenda: Michael, Cathy, Darko, Chris, George, ajc, Kem, Scott, Peter, Brittany, Simon, Zeljko
- scheduler workshop (ajc)
- Papers in place? Kem will post summary and list this week.
- Please do not edit the agenda/schedule below further - use Scheduler workshop agenda instead.
- Start with 1/2 day of presentations on what LSST and OpSim are (walkthrough next wednesday)
- Overview of LSST and OpSim (Connolly/Kem). ajc will send Kem slides
- need to explain the difference between what we schedule and what other telescopes schedule
- Presentation on science requirements (what is in the SRD; what challenges are we facing) (Zeljko)
- What is the Scheduler currently doing? What are our plans (Francisco)
- Overview of MAF (Lynne )
- 2nd day: discussions on the following four questions based on external people's past experiences
- (small groups or plenary sessions? Andy, Kem, Lynne, and Michael think we should have plenary sessions.)
- We will turn the questions into a slide per question
- Discussion about scheduling algorithms
- Describe the greedy algorithm in one slide
- What other optimization approaches are available
- Are greedy approaches sub optimal (when should we be looking beyond greedy)
- How much human tweaking is used (are their automated schedulers)
- Describe our thoughts for lookahead in one slide
- What other approaches are possible and how do we make it deterministic
- How far in advance can we predict the LSST position
- Experiences in short term (tactical) and long term (strategic) scheduling
- One scheduler model or a hierarchy
- Update strategic model in the day (do we care on timescales less than a lunation)
- How do we define which heuristics are good
- trial and error, best practices
- How do we preserve temporal uniformity
- What do we mean by this (one slide) and why we care
- How do we represent spatially varying sky (e.g. twilight, cloud etc) and not just search for sucker holes
- Why are filter changes important (slide on number of changes per hour, one change in 20 mins and its impact)
- how can we minimize the filter changes
- Grammar (do we need a better grammar to describe proposals?)
- Explain the difference between what we schedule and what other telescopes schedule
- What are the types of time constraints we have in the science proposals (or engineering) - one slide
- are we missing any particular science case(s) and how rich is our grammar
- How should we describe the time dependent events or proposals - one slide
- Can we change the action if we fail to meet one of the objectives with an observation
- Input telemetry
- Slide on what telemetry info we have (including the cloud camera and observatory model). Slide from the overview of opsim
- What are we missing - do we need DM feedback or can we
- Have people successfully employed predictive models (e.g. predict the weather 3 hrs from now)
- Slide on what models we plan to have in place (e.g. sky and twilight model)
- Do other observatories use this real time information?
- How do they represent the data
- How might we visualize the outputs and determine if something is going wrong
- Development of metrics
- We need to take care that we focus less on the sociology and more on the mathematics of optimization and metrics
- What are our current metrics designed to address (types of science cases) - one slide
- How do we turn a metric into a benefit function to trade-off with the cost function?
- How do we fold a metric back into a schedule and then into a proposal
- We have multiple groups working with many different metrics
- How do we manage different groups (are metrics for other systems all in-house)
- Are there mechanisms to combine metrics to reduce the number of distinct metrics or is this all ad hoc
- Probably naive to think we will have a single cost function but many cost functions that we will optimize
- Optimization of a single cost function: Is that realistic or not?
- how do we account for data that is good for some proposals and bad for others
- Room under Iain - power strips
- Record the talks and discussions
- hacks we should work on
- release MAF before the workshop
- Monday morning presentations
- How to we go from pointings to images (end-to-end simulation): (Scott)
- Presentation on the OCS so that the group understands how it fits in (Paul Lotz?) George to ask
- Define everything that will be removed from gitolite
- Monday afternoon
- Release Tier 1 runs (MAF, and data) in a web page etc(Cathy, Lynne)
- Work to be done on MAF to understand transients in the context of rolling cadences.
- Design work (Kem, Zeljko, Peter, Rahul)
- Need rotTelPos and rotSkyPos back in the OpSim output (Simon, Michael, Francisco)
- filter control parameters (francisco Michael)
- Put alert stream in Git and JIRA (Darko, ajc)
- Put bright stars into the catalog database (ajc, Simon)
- Ask Yusra where the refactoring of the DB stands
- Tuesday morning
- implement pex_config in a user-friendly way. (Scott, Michael, Kem)
- filter control parameters (francisco)
- Build a Science Analysis driver. (Lynne, Zeljko, Cathy)
- Remove SStar and replace with first look analysis, SRD-level analysis, then wider science analysis.
- Goal to have first look in place, and have the design of the rest completed
- Reconcile fact that OpSim pointings are for only one filter while catalogs simulate photometry for all filters (Scott, Simon, ajc, Rahul)
- Tuesday afternoon
- Need to get DDS to work. (Michael, Dave Mills)
- Review opsim design (michael, ajc, francisco)
- Demonstrate progress on sky brightness (Peter, Zeljko)
- Figure out use cases for something that makes run-to-run comparisons automatically. (Cathy, Lynne)
- add UCDs to database (darko, simon)
- Ask Yusra where the refactoring of the DB stands
All hack suggestions
- Kem (+1 for George): Michael and Francisco should work on filter control parameters.
- Kem: We need to understand how to optimize rolling cadences. (+1 cathy)
- Kem (+1 for George, +1 Cathy, +1 Scott): Work needs to be done on MAF to understand transients in the context of rolling cadences. Need to optimize a MAF transient metric.
- Lynne: Should this be in another driver (not SStar)? Build a Science Analysis driver
- Kem: implement pex_config in a user-friendly way. (+1 cathy, +1 Michael, +1 Scott)
- Kem: pull out cloud and seeing tables. Have them talk over DDS to Opsim.
- Lynne: Build a Science Analysis driver. Remove SStar and replace with first look analysis, SRD-level analysis, then wider science analysis.
- Need to talk to Kem and Cathy about what a first look analysis would need.
- +1 from Peter, 1 ajc, +1 Cathy, +1 Michael, +1 Scott
- George: Consolidate SRD metrics and must meet limits for those metrics, preferably before the Scheduler Workshop
- Lynne: Build in a benefit function (i.e. prioritize low airmass feels or look through filters with the lowest sky brightness).
- possibly should wait until after Scheduling workshop (+1 PY-maybe this is just getting a more in-depth look at the Opsim cost function–do we have any tools to visualize the cost function?)
- Lynne: figure out use cases for something that makes run-to-run comparisons automatically. (+1 Cathy, +1 PY)
- Peter: demonstrate progress on sky brightness calculator. (+1 ajc)
- Peter: make sure we can combine multiple outputs into a single display. (does this refer to the movies? -Cathy. This is related to breaking up the SSTAR config file, I want to be sure that we can dump the results from different configs into the same output directory without problems. -PY)
- Peter: need rotTelPos and rotSkyPos back in the OpSim output.
- Scott: reconcile fact that OpSim pointings are for only one filter while catalogs simulate photometry for all filters.
- A part of this is having a discussion about what we want the catalogs to be used for. They are currently very specialized to act as PhoSim input catalogs. That may not be the most generally useful application. (+1 ajc)
- Darko: Put alert stream in Git and JIRA (+1 ajc, +1 Michael, +1 PY)
- Darko: add UCDs to database.
- Darko: get interface to PhoSim or GalSim to generate simulated cut-out that comes with alert stream.
- Michael (+1 for George, +1 ajc, +1 Michael): need to get DDS to work. (Work with Dave Mills)
- Michael: continue to review OpSim design.
Michael: go from generating catalogs using photons to generating an image. ( George: Isn't this the same as the training session on "pointings to images"?)- Francisco: emphasize the boundaries of all of the components of the simulation code.
- Cathy (+1 for George +1 Cathy): need standard pipeline to perform and analyze and compare OpSim runs
- Chuck: both sky brightness and seeing feeds into simulations (using Peter's model) could be implemented
- areas we should have training sessions on
- Michael (+1 for George): how to we go from pointings to images (end-to-end simulation): (Scott?)
- Scott: Would this be more useful as a presentation, rather than a hack (since code to do this already exists; it's just not transparent how to use it)?
- Yes I think this would be a presentation and go opsim pointing to phosim and opsim pointing to galsim and then DM if we have time
- Presentation on the OCS so that the group understands how it fits in (Francisco?)
We will then go back to a couple of items we ran out of time
- feedback from DESC (Scott)
- lots of code duplication going on (working groups doing what we have already done with OpSim/CatSim)
- Simon: maybe have something like the Cadence Workshop for OpSim/CatSim at either DESC or All Hands so that people know the code is out there and what it an do
- Chris: Not everyone understands what all the pieces of code do and how they fit together.
- What do all the pieces of the stack do? Which pieces can stand alone? What are all the different kinds of output that you can get without running the full OpSim->CatSim->MAF pipeline
- Rahul: Make functionality as stand-alone as possible so that people can only grab the pieces of software they want a la carte.
- Document EUPS so that people know how to install only what they want
- Look into further breaking up dependencies (can we get DM to separate out the things we need so we don't, for example, install all of afw when we just want cameraGeom)
- Develop more working examples so that people can see at a granular level what they can do using just part of the code (and how to get just that part of the code).
- Renaming the Scheduler:
- Andy: "Whenever we discuss the scheduler, people are unsure whether we mean the OCS or the brain that makes the decisions."
- Analogous to DM confusion between "sources" and "objects."
- Kem: OCS group is adamant that "the thing in the blue box in the diagram" should be called the Scheduler.
- OCS is all the plumbing around the Scheduler.
- Chuck: our definitions are pretty set in stone. We need to be more consistent in how we use terminology. Should we develop a glossary of terms?
- new opsim machine