Date

 at 10:30am MST/PDT

Tucson Location:  LSST Conference Room

Videocom: IP 140.252.24.8 (Direct Dial)

Call 1-866-330-1200, Participant Number 860-9352#

Attendees

  • Lynne, Peter, Simon, Kem, Srini, Steve, Chuck, George, Cathy

Agenda

Scheduling Workshop (Kem)

  • target date is the week of Nov 17
  • considering others to invite
  • ACTION Srini has two suggestions from UA that have worked with LSST and will send to the email list

Developer Hire Update

  • negotiations are in progress
  • probably won't move to Tucson right away but can travel regularly
  • Kem suggested he travel to Chile for a week to work with Francisco to start getting up to speed on code

Development planning

  • ACTION Cathy will work with Kem to update the plan spreadsheet (which will define epics in JIRA) to take into account the latest developments

Design Review (week of Oct 1)

  • This is to be a Conceptual Design Review of documents presented by Francisco which will map out the steps needed to formulate a design in time for a Design Review in mid-Dec
  • ACTION Cathy will send out doodle poll to set up a time separate from Opsim meeting (preferred to be earlier in the morning for Europeans but later in the morning for those with kids)

MySQL v SQLite

  • We held an extended discussion about the various issues that are connected to this.
  • ACTION Srini will create a confluence page with a proposal for how to move forward, capturing these issues, especially ones Simon brought up
  • We will hold a follow-up discussion Oct 15 (we should make sure to notify other interested parties)
  • Issues that were brought up that should be considered in the final concept / design for the Simulator
    • The simulator design ideally should be database agnostic
    • The simulator design should mirror the scheduler which may NOT be database agnostic
    • Currently the Simulator runs using MySQL DB and gets better performance (~30 days with no lookahead)  than the branch with SQLite (SQLite is 20%  worse without lookahead than MySQL).  This may become an issue for when lookahead is ready (takes longer to produce and analyze runs) and if we do a very large number of runs to optimize groups of parameters this will be a factor.  There may be some more things that can be done to tune SQLite to improve performance.
    • Currently we can still use the SSTAR on the MySQL db until we have a workable replacement. But MAF can be configured to read the MySQL DB directly - this would restrict analysis to taking place on ops1 and ops2 (not on ones laptop)
    • SessionID's (single simulated surveys) contained in one file (.sql or .sqlite) are needed for distribution to the Sci Collabs, and for OpSim to work independently of ops1 and ops2 (freeing computing resources in some cases).  Tableau does not work with sqlite files so preserving single survey .sql is desired since it does not run on Linux.
    • There is an advantage in analysis/validation to be able to examine more than one run at a time - this is trivial in MySQL, but not obvious how to do this in SQLite.
    • A learning curve is necessary in being able to manipulate the SQLite files (very different than MySQL, although the actual "select *..." statements are the same)
    • The Simulator is currently not deterministic.
    • Too many "translation layers" or places where the foundation DB is converted to other forms is breeding ground for data errors and versioning issues as well as duplication of effort.  (right now we manually control the uniqueness of naming a simulated survey for example) - so creating individual files (sql and sqlite) as well as adding information to tables after the simulation has completed are potential problems and should be minimized.  We need to verify that currently, the schema in all these forms is identical; and ensure this going forward.  Maybe address with write protection to whichever DB the Simulator is using. (Adding Dithering patterns and sky are two examples)
    • Simplification is a core value
    • We want to facilitate moving away from using SSTAR to using MAF
    • The time to run MAF (any combination of drivers), and the tools which create these extra files, can be time consuming so the final implementation should optimize this

AAS Posters (Drafts for Friday Sims meeting)

  • Kem suggested that OpSim-UW consider putting together a poster that would summarize and explain MAF to the community - encouraging involvement
  • ACTION Lynne will consider this and talk to OpSim-UW

JIRA Status and Blockers

  • Kem - reviewing final change on transient fix (blocking commit)
  • Cathy - trying to install MAF on opsimcvs with little success (Lynne and Simon are available for questions)
  • Cathy - can't read tusken.astro.washington.edu:8888 from outside NOAO_ will diagnose
  • ACTION - Cathy will work with Kem to commit new default config files as well as new downtime file.

Review assignments from last Fri’s Development Plan

  • Kem currently has the reassigned JIRA item to review and blend the current requirements document and will work with Francisco as needed.
  • Cathy will be  
    • getting MAF to run on opsimcvs so it can be the point of distribution for results within OpSim and to the SciCollabs
    • working with the current features of MAF to define what functionality is needed to replace SSTAR Standard Report (for instance use of groups and subgroups)
    • working with Steve to gather the list of metrics that relate to meeting the SRD and formulate a way to view this within MAF



NOTES

These comments from the agenda are preserved here for followup / clarification at future meetings.

All
Write up the simulation framework codes into papers: papers will be based off the SPIE versions (ie expanded). This would provide a set of refereed papers for opsim, catsim, maf that people can cite.

Cathy
Finalize what functionality needs to be in MAF to replace SSTAR
Learn to write metrics and implement any required metrics for opsim in MAF
Implement new plots in MAF required for evaluation of Tier 1 runs

Francisco
Generate a breakdown of tasks for the refactoring of opsim to produce telemetry data and to modularize the scheduler component
Produce a design for the OCS/Opsim framework and submit for design review (including libraries, data structures, api and methodology for the communication)
Start the refactoring

Kem
LSE-190, Scheduler Requirements.
Scheduler experts workshop
Evaluate Tier 1 and rerun if necessary

Additional MAF dev: Anything more needs to be developed?
• Kem - tabular completeness data? Lynne - in summary stats
• do people will want access to the table? Peter - could provide link to data in tables
• can't do side by side plots currently (do it with tabs)
• Put link to data on the plotting page
• Another layer of grouping on page of opsim runs (have categories of the analysis: sstar/cadence etc)
• Srini - this is classified in the run log
• add sort by date (maf and opsim)
• all filters in one histogram (different colors per line)

How do we make this persist (opsim serves the data). Will it just be a big list
• question for opsim to discuss at future meetings
• You can create multiple tracking databases and browser plots using different ports