Enterprise CRM Solution

1
Ease of Use Project Development Plan GBT e2e
Software Review August 30, 2004 Nicole Radziwill
(nradziwi_at_nrao.edu)
2
Goals

• To streamline the observing process
• Enabling capabilities such as automated dynamic
  scheduling and remote observing
• Make the GBT easier to use for both visiting
  observers and staff astronomers
• Reduce setup times significantly
• Reduce the reliance of visiting observers on
  scientific staff
• Includes the ability to
• define observations in advance of observing,
• the ability to execute those observations,
• improved monitor and status information during
  execution, and
• an improved real-time display

3
The Past

• Many disparate software applications, much
  duplication of code
• GBT Observe (GO), a GUI application written in
  glish
• Control Library for Engineers and Operators
  (CLEO), a Tcl/tk GUI
• Ygor, a distributed object-oriented telescope
  control system in C
• IARDS, an aips quick look real time data
  display
• DISH, the aips single dish data reduction
  environment
• Glens Spectrometer Tool
• Franks pulsar GUI and pulsar monitors
• In addition to being difficult to test
  functionality from end to end through all these
  systems, it was often difficult to determine
  which application should host a particular
  function. There was no clearly defined structure
  by which one would know where to develop a
  particular new requirements.
• Operational problems can also result! (Ex. An
  individuals application using up too many
  connections to devices, causing cascading errors
  that require extensive troubleshooting and
  operational support)

4
The Future

• Code is written once, used by multiple
  applications as necessary (example of this is
  calibration)
• Code is written to accommodate a discrete number
  of well-defined levels of abstraction
• Applications
• Application Components
• High-Level APIs
• Low-Level APIs
• Data Systems
• Distinct categories of usage
• Standard users interact with Applications and
  Application Components
• Expert users interact with High-Level APIs
• Programmers interact with Low-Level APIs

5
High-Level Architecture
GUIs
Application
Application Component
0..n
uses
HLAPIs
Expert User
Programmer
uses
uses
LLAPIs
Control System
Observed Data (in an EDF)
Real-Time Data (streaming)
6
Data Processing ()
ObsProject
ObsProposal
Obs Prep Tool
consists of
Proposal Submission Tool
Science Products
ObsUnitSet
Science products may be produced as part of the
pipeline or in an offline mode
Scheduling Block
Quick Look Display (GFM)
APIs
Execution Block
Quick Look Results
Goal for the Logical Structure of a GBT Observing
Project (software subsystem boundaries noted by
dashed boxes)
Scan
Calibration Results
Tel Cal Tool
Subscan
Data Capture
7
Project Description
Quick Look Data Display
GBT OT
SB Executor
Status Screen
uses
BUILD
Configuration API
EDIT
Observing API
Console Windows
RUN
Balancing API
MONITOR
Easy Access to Documentation, Help

• Scheduling Blocks
• Annotated Index of Observation
• Execution Log File

Integrated Desktop
Observation Management Database (e2e Project
Database)
Note that APIs are very telescope-specific, yet
are used to abstract the observation into terms
not specific to the telescope
8
Integrated Desktop
9
Development Phases

• Configuration 10/1/03 to 3/31/04 6 mo elapsed
• Observing 11/15/03 to 9/17/04 6 mo elapsed
• Scheduling Blocks 5/17/04 to 9/17/04 3 mo
  elapsed
• Full Functionality 2005
• Program Level Integration / Remote Observing
  2006
• (Items in 4 and 5 have been referred to as
  Advanced Ease of Use)

10
1. Configuration API

• Provides ability to simply configure hundreds of
  parameters on the telescope by specifying a small
  subset (lt15) of astronomical metakeywords
• Also provides the ability to directly set control
  system parameters, for expert users
• Also provides diagnostics, including the ability
  to check devices, the state of the IF path,
  frequencies and velocities of the LO1 and LO2,
  channels, switches, drivers modules in use
• Can be done through the Python command line
  interactively for testing purposes, or by
  preparing a script and executing the entire
  script (recommended for expert users)
• See Data.ConfigurationCases, Data.ConfigurationToo
  lUsage, Knowledge.ConfigKeywords on the Green
  Bank Wiki (http//wiki.gb.nrao.edu)
• Can be accessed in the following ways
• Directly, from the command line, for engineering
  and commissioning
• Via a Python script for expert users
• By other application components, such as the GBT
  OT

11
2. Observing API

• The Observing API, nicknamed Turtle, is modeled
  after the LOGO graphics builder utility of the
  same name
• The purpose of Turtle is to provide a series of
  building blocks that observers may utilize to
  create their own observation procedures these
  building blocks can then be used to create
  complex movements of the beam across the sky.
• Turtle also provides a pre-defined suite of
  commonly used scans created by on-site
  astronomers for observers, which in turn may also
  be used as building blocks to create even more
  complex beam movements.
• Amy Shelton will provide a complete description
  of the structure of the GBT Scheduling Block and
  how the new Observing Tool is to be used

12
3. Scheduling Blocks

• APIs are used in the execution of Scheduling
  Blocks
• Has identical entities/attributes as the ALMA
  Scheduling Block, with the possible exception of
  setup/configuration
• Although these will be eventually archived in XML
  with the observers calibrated data products,
  right now we simply aim to store them in plain
  text, and have chosen a format similar to the
  user preferences file
• Uses the Configuration API and Observing API to
  execute complete observations on the telescope
  Scheduling Block Executor (implemented within
  Turtle) controls the flow of information

SB EXECUTOR
Configuration API
Balancing API
Observing API
13
4. Full Functionality (2005)

• Release of SB-based observation management system
  delayed from 8/31/04 to 9/17/04 because of this
  review
• It will cover all GBT Standard Observing Modes
  except Radar, or observations with fast-moving
  near Earth objects (comets/satellites)
• Pulsar observing and some enhancements for spigot
  ease of use are scheduled as maintenance
  activities for Fall 2004
• Required capabilities to be developed include
• Support for generating ephemeris tables and
  observing fast-moving sources like comets and
  satellites
• Be able to use and define source catalogs
• A Balancing API to eliminate user dependence on
  CLEO, which requires expert level knowledge

14
5. Program Level Integration (2006)

• Work has focused on building SBs and executing
  them by populating a queue and letting those SBs
  execute first-in-first-out (FIFO), but we will
  still need solutions for
• Queue Management, which integrates constraints on
  the SBs (such as opacity) and puts the management
  of observation execution more in the hands of the
  operators
• Building the logical relationships between SBs to
  create ObsUnitSets that fulfill scientific intent
• Kicking off pipeline processing (this should be
  done at the Program level since the products of
  multiple SBs may be required to yield data
  products ex. maps)
• Low-Bandwidth Remote Observing Solution
• High-Bandwidth Remote Observing Solution
• We may already have the tools to implement both
  remote observing solutions, however, our
  constraints are specifications and science staff
  time

15
Development Plan
1 CONFIGURATION API
2 OBSERVING API
QUEUE MGMT
TEST
3 SBs
BALANCING API
SOURCE CATALOGS
CONSTRAINTS
INTEG W/PIPELINE
EPHEMERIS
COMPLETED BY END 2004
PHASE 4 TO BE SCHEDULED (2005)
PHASE 5 TO BE SCHEDULED (2006)
16
Relationship to ALMA and EVLA

• All development has been done with strong
  reliance on
• Design documentation from ALMA PDR (March 2003)
• ALMA SB Definitions (January 2004)
• NRAO e2e Archive Model (May 2004)
• NRAO e2e Observing Model (May 2004)
• NRAO e2e Project Model (May 2004)
• Basic functionality of ALMA OT has been
  replicated
• Less effort in prototype stage than customizing
  ALMA OT to use GBT APIs
• We didnt want things like perspectives and
  were concerned that we are not ready to support
  ACS in -Lite or -Lighter forms
• We could adopt the ALMA OT and Queue Management
  system in the future if this is desired in any
  case, staff astronomers and observers will be
  able to observe according to a common look and
  feel with ALMA upon completion of the testing
  period (end 2004)
• GBT could be useful to prototype and test ALMA
  concepts with users ALMA interest is critical

17
Risks

• No Project Scientist for Spectral Line Data
  Display no written specifications or singular
  point of responsibility yet for what should be
  contained in spectral line data display
• Although we do have the capability now to display
  waterfall diagrams, which has been mentioned as a
  desirable enhancement
• Once specified, development could be done in a
  reasonably short amount of time if approved by
  the GB Project Planning Committee
• Data display work has been driven by PTCS needs
  so far
• Adoption of SB-based system by staff astronomers.
  Writing down observation plans a priori in the
  form of SBs may require a shift in behavior for
  some staff.
• Adoption of OT (which does not look like former
  GO application!)
• User interfaces historically controversial lots
  of gray areas between needs and wants, and
  individual preferences
• Community buy-in to ALMA/e2e concepts and
  directions