Please do NOT post ITAR-restricted content on this site.

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

March 19, 2013 SITL workshop, Boulder CO:

Team members are welcome to correct errors or add additional information by using the "edit this page" function under the "edit" function above.

More than 50 members of the MMS management, spacecraft, instrument teams attended.

...

  • Three parts to the software: data handling, data display, and trigger management.  SITL computer will need to be able to locally cache the processed data. <-- important to note
  • The demonstration by ..... was thorough and smooth.  Tom Moore inquired about another style of display.  The answer is that any combination of data can be defined and the PI will determined whether support exists for inclusion as a standard plot type.  Otherwise, individuals would need to create their own plot type for inclusion into the system.  It should be possible for folks to make custom solutions quite easily if familiar with TDAS.  Although we don't want this GUI to become terribly cluttered, max of 10 "pull downs". 
  • See the picture of Tai's office to envision the ideal SITL scientist's office.  Theoretically, the SITL scientist should be able to perform their function with a single MacBook Air while on travel.
  • There was a question as to when we would be ready to beta-test this system. The answer is that there is still some development to do and testing with some "real" data, like calibration data.  Currently working with THEMIS data. 
  • Folks will need to get TDAS working on their systems and to start working with it.  There was a suggestion to prepare a beta-test plan with schedule.  There was another suggestion to use Cluster data for beta testing.  Others felt that the THEMIS data is better prepared for testing the display software and Cluster is best suited for trigger testing.  Again, a beta-test plan is needed to work out who can do what and when.  What can be used for initial training?

Russ Panneton presented information on the Burst Selection Cycle.  He gave details on the data interfaces with the SOC and the later command interface along with a picture of the SITL "sequence of events". 

  • An important reminder is the fact that the SITL scientist can look back in time to previous downloads as well as current downloads to monitor what has been captured and ensure that the priorities in the buffer remain as desired.  
  • How FOM and other parameters will be adjusted with time needs planning.
  • Russ pointed out that there will need to be a process for the SITL understand when full data has been received from the set of spacecraft.  Data is processed continually regardless, the SITL function needs a method to know when the data is ready for SITL work.   There is a plan to download the burst metadata twice to ensure we have it.  There would be eight processing cycles then, two per s/c which could happen in any order.  There is a suggestion that something/somewhere automatically emails the SITL function that it is time to "pull" the data and then also needs the schedule of deadlines for the "push" of changes to the download priorities.  The nominal schedule would be known in advance and will be made available, confirmation emails/texts then need to be disseminated.  Also need a process for folks to know who has SITL authority at any given time. 
  • Good discussion ensured on how the SITL function would proceed in real time.  All agreed more thought and documentation was needed on these ideas.
  • Russ presented information on the database structure, which will include full information on what transpired along the processing cycle and with time. "I capture footprints of everything we do", and apparently including "who" did it.  Bob made a point that we want to capture information on the "basis of decision" for the SITL scientist decisions.  If SITL changes some parameters we will want a "comment string" in the data structure to capture this.  It will be possible to compare the results of the automated selection system and the SITL selections.  How can we make this comparison automatically appear?  Either on the SITL display or as a regular report of some kind elsewhere?  Method of access is not yet clear at this point for these files or what other diagnostic information may be needed.  Bob noted a few files or pieces of information that may be needed on the SITL side.
  • Russ presented a list of "things that needs to be done", see the chart in the presentation for a clearer view of this list captured here... this list was from a previous meeting and may not be completely up to date.  All should look through and ensure their actions items have been completed or are on track to be completed.
    • Documentation --SITL Data Products Guide --SDC-SITL ICD
    • SITL Data --Develop, test, maintain software for SITL data production --Create sample SITL products for developing and testing display capabilities, interfaces, data retrieval software, etc.
    • SITL Data Access --Develop, test, and maintain interfaces that allow access to SITL data at the SDC --Develop, test, and maintain software on SITL side to interact with the data access interfaces (including local cache management)
    • Buffer Selections --Develop, test, and maintain interfaces that allow submissions to the SDC --Develop, test, and maintain software to enable SITL users to create buffer selection structures

Last item on the Agenda:

Actions:  Bob noted that there are plenty of details to be worked; some details to the interface diagrams may need updating.  Lots of fine tuning to do but things appear to be coming together. 

items to review/do in the future:

  • HPCA processing of data for SITL function
  • Representation of SITL Tools portion of the SOC-SITL graphic needs updating
  • Communicate the routine CDQ selection algorithms
  • How to accommodate the changes that FPI command mode can have on its trigger terms.  No free running on changing mode without accommodating through the system.  Identify areas this type of thing can occur and write down a process to accommodate.  The IS ops lead has a thought on this process.
  • Write down SITL staffing plan, request other suggestions (Phan?), circulate, refine, take to SWG.
  • Beta testing of SITL system ... need to get the TDAS downloaded, etc.  prepare for the next in-person SWG meeting.  Prepare a beta test plan.
  • Straw poll of folks willing to serve as SITL scientist.
  • Review CDF implementation and what metadata will be included to make sure all files are useful to the SITL, and other, functions.  Non-standard CDFs are considered to be non-helpful.
  • How to notify the SITL that the data is ready for download and when their deadline is for turnaround.  Maybe text message?  Process for how SITL scientist authority is known.
  • Review notes above to see what else needs to be captured in this list ...
  • SITL commissioning plan, starting very simple, adding needed complexity as time goes on.


Items for future SWG telecons:

  • Review SITL workshop notes - enter corrections/expansion
  • Flowchart for Phase D/E Science Communications:  updates? agreement?
  • SDAOWG telecon schedule, nominal agendas, POCs 
  • presentation of draft SITL beta test plan: updates? agreement?