Date

19 Aug 2014

Attendees

• Francisco, Kem, Steve, Lynne, Srini

Agenda

• LSST2014 – Comments and impressions

• Planning next steps
  • Review of 19 bullet point updates (also copied below)
  • Also attached slides on schedule and deliverables
• OpSim meeting focus
  • Development – coding, testing & validation (Wed)
  • Production  - cadence studies & MAF (Fri?)
  • Mid-sprint blockers, or end sprint debrief and new sprint begin (Wed)

Discussion

LSST2104

Steve reported that they are sending out survey for what was useful and repeatable for next time; the MAF reception was encouraging.

• Andy had invited people to submit ideas for metrics and Lynne said the approach is to encourage them to write their own and direct them if needed.  Work on MAF isn't really going to come to a stopping point as planned, so supporting community requests (Lynne will send out contact email lists) will need to be addressed as we see how many are made.
• Andy also invited people to submit requests for cadences and that we would support cadence changes - realistically we will be happy to put these requests into a queue, which will be made available on Confluence (similarly to the Data Access pages) but in a new format.   
• It is not clear yet who will be responsible for responses to requests for MAF help or Cadence input.  It was suggested that Steve be the OpSim face to the community but Steve said his role is under discussion.
• The next workshop might be around the time of the Simulator release (Summer 2015), but the priority now is to get the simulator to look like the scheduler, then continue the development of features, bug fixes, and documentation for a release.  A workshop could focus on teaching participants how to use the config files and then send them to an online facility to be run.

Scheduler/Simulator development

Priority through the end of the year is to change the way OpSim is implemented - not the models and functionality, but the way it is deployed and interconnected with the DDS to comply with scheduler interfaces.

• need essentially four interfaces: Scheduling/Simulation parameters, Telescope telemetry, Weather (currently clouds and seeing), and Downtime status. These will have to be on the DDS and then the Simulator will subscribe to them
• it's not clear exactly who will define the ICDs - Francisco and the new developer will clearly be involved.  Tighter coordination between T&S/OCS and SE/OpSim will be needed to optimally execute and create this set of tools.
• Kem notes that none of this will happen until the end of September after travel and OCS Review is complete. 
• Until then Francisco has a few loose ends to complete - coding constraints on the camera and fixed number of changes, fixes to sequences class, and first order lookahead  debugging.
• SRini will send out information on the DDS under consideration: PrismTech is the company, product is called "OpenSplice" 
• Is there a notion of an OCS workshop on the DDS? Francisco reports there have been sessions on how to connect and there may be an opportunity at a SLAC camera meeting planned for Nov.-
• It would be extremely useful to know if there is a current forum in T&S or OCS for the discussion of the scheduler/simulator development process.  Francisco will send out information he has on lists and how to subscribe. Tues at 1pm MST (860-9352#) is the Software Control meeting which addresses this from time to time. 
  
  

Cadence Studies

Reference Run:  

• The current best baseline run is ops1.1075 (on the Tier 1 confluence page), but feedback is needed from Zeljko to improve even further (e.g. even less NES coverage?).  No one knows when Zeljko will be back (maybe mid-Sep?) but Kem will send email.
• We would like to release v3.2 with this new Reference run (along with a few code fixes planned by Francisco) planned for after the OCS review.
• Srini would like to complete the implementation of palpy by this time.  Kem will test this branch with a simulation done with the master and one with the palpy branch to validate.  Srini thinks he can complete this in the sprint after the OCS review
• If palpy does not track planetary motions then look at pyephem for this - we will need to know where planets and bright stars are for scattered light models.

Next Steps

Detailed planning for the next 6 months will be developed to put in JIRA and higher level planning will be put in place for the 6 months after that.

Materials

Relevant planning slides from presentations by Francisco (7/15/2014) and Andy (8/15/2014) are here 

And an update to the Technical Review document Overview and Planning (Scope of Work) is itemized here and in email 8/19/2014:

I thought it would be useful to go through the tasks set out at the end of January 2014 for the Operations Simulator for the external review in light of the development plans that Andy laid out at LSST2014.

A brief summary, is that essentially all code development takes back seat to designing and implementing the V1 scheduler. Community outreach and science explorations will take place using available code.

Code Development—more or less put on hold until scheduler V1 delivered

1. rolling cadence
this has been developed and rolling cadence simulations are in the works

2. look ahead
the framework has been implemented but there is a bug(s), this task will be put off until the scheduler version 1 is delivered

3. verification of sky brightness model
this awaits deliver of the LSST-wide sky brightness model and use of all sky camera data

4. LSST sky brightness model
see above

5. improve camera/shutter model
awaiting final details of kinematic model from camera team, implementation lower priority than scheduler V1

6. implement marching army
probably implemented as part of sequencer in scheduler

7. investigate schedule optimizers for short-term blocks
probably a key part of delivering the scheduler version 2

8. analysis tools, metrics and methods development
MAF has done this and expect input from the community now that it has MAF

9. study dithering strategies
waiting for community input

10. focal plane geometry
long term goal, needed for optimization of dithering

11. dithering in OpSim
waiting for 9 and 10 to be complete

12. restart (warm start) capability
long term goal

13. implement co-added depth for weighting
long term goal

14. add a failed (and subsequently modified) or partially failed observation capability
long term goal

15. realistic transparency
awaits all sky camera data analysis, implementation is long term

16. capability to use spatial distribution of clouds
see 15, long term

17. capability to handle scripted cadences
scheduler sequencer should do this (see #6)

18. implement ToO interrupt modeler
long term, could depend on warm star #12

19. put scattered light model in opsin
probably part of scheduler V2, needs tracking of planets and knowledge of bright stars to be used (available in slalib—also Palpy?)

Maintenance, Validation and Cadence studies

1.create basis set of runs
many simulations done, refining details with Zeljko’s (and others) input—ongoing

2. verification and validations
well, we’ll do it

3. maintenance and support
this is open ended, but will be a lower priority than delivering the scheduler V1

4. cadence studies
this effort will be done simultaneously with scheduler development, not involving the developers, but primarily Kem and Cathy and should also be considered part of work with the Astronomical Community

5. early publication of benchmark OpSim simulations
I see this as part of #4, above

6. documentation
ongoing effort, need to complete by summer 2015 for opsim release

7. adhere to and maintain software standard and open source policy. unit testing in all phases of development
developers need to be nudged for unit testing, Palpy implementation needed to complete open source-ness

Communication with Astronomical Community

1. host workshops
1 down, 2015 needs to be planned

2. configuration file viewer and editor
a fine wish, Andy thinks SLAC might be able to help

3. opsim becomes open source
anyone can download it from stash now (but still requires slalib), need work on documentation for installing and running

Transition to Scheduler—declared by Project to be highest priority

detailed plan for this transition is needed. need APIs and ICDs—that is the next few months work

Editor’s note: I would think that designing and implementing the APIs and ICDs for the simulator/scheduler interfaces to the world, while critical, might not take all the time for the next year and many of the code development tasks will be able to be moved forward.