Versions Compared

Key

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

...

  • implement links between application (done preliminary version)

Data Quality Monitoring

Jira

Jira Issues
urlhttp://jira.slac.stanford.edu/secure/IssueNavigator.jspa?view=rss&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10443&fixfor=11233&reset=true&decorator=none&os_username=glast-jira-issue-browser&os_password=glast

Scope

This application will provide output histograms and data trends resulting from the Fast Monitoring, Digi and Recon processing. The driving process is the L1Proc; root files from each of these processing steps will be registered with the data catalog and picked up by the application in order to display quality histograms. Separate processes will load Digi and Recon tuple files to ingest them into a database for the data trending.

Status

  • It is currently possible to display histograms from Fast Monitoring, Digi and Recon.
  • We have a first implementation of the code to ingest trending data into general purpose database tables and managed to produce plots from the web application. The result of this effort was that we need to create new database tables specific to this application.
  • Alarm Handling
    • The Fast Monitoring process ouputs an xml file with a list of the alarms/warnings/errors detected on the produced monitoring histograms
    • This file is registered with the data catalog
    • A notification is added to the Logging application which points to the Data Quality Monitoring application
    • The xml file is ingested by the application producing summary and detailed information on the alarms/warnings/errors
  • Data Trending
    • Tables to ingest the trending data are available : some 50K quantities at a frequency between 10 seconds and 5 minutes
    • Several copies of the same tables are used to accumulate data at different frequencies
    • Code to ingest the data is available and used as part of the L1Proc.
    • Trending plots are produced from the database
  • Plot Description
    • Description can be added to each plot

To-Do List

  • Stress test the trending database
  • Alarm Handling
    • Ingest detailed information from xml file, like which bins produced an alarm etc.
    • Display alarm information on the plots, like warning/alarm limits or arrows on responsible bins
  • Data Trending
    • Given the volume of data a database table only approach might be insufficient. We might have to consider a hybrid solution that involves reading data straight from tuple files (less efficient that reading from a db)
    Improve the application's UI
  • User preferences
  • Improvements based on user's feedback

Jira

Jira Issues
urlhttp://jira.slac.stanford.edu/secure/IssueNavigator.jspa?view=rss&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10443&reset=true&decorator=none&os_username=glast-jira-issue-browser&os_password=glast

Source Monitoring Jira

Scope

Display ASP data products for a pool of sources.

Status

This is the second implementation of this application. We have developed a set of databases to keep a list of sources and to ingest data to be trended at different frequencies. The sources database can be loaded from xml files used by ASP. Scripts are available to ingest the data from the pipeline at the end of ASP processing.

This is still a preliminary version of the application and needs feedback to better define its scope and use.

To-Do List

  • Improve the application's UI
    • User preferences

Data Processing

Scope

This application should provide a quick and intuitive look at the status of data processing from the moment it is being Fast Copied through the various processing steps that lead to the final data products.

Status

A preliminary version of the application has been used during the October Test and it worked pretty well.

  • Downlink-RunId database tables have been created
    • with these tables it is possible to extract which run numbers are contained in each downlink
  • The progress mechanism has been defined as the number of completed sub tasks for a given process.
    • When new sub tasks are forked off the overall progress might go backwards

To-Do List

  • Remove duplication between data processing page and other apps
    • One possibility is to hide queries in functions

GCN/GRB Web front end

Scope

Tabular overview of most recent Noticies and possibility to browse GRB/Noticies.

Status

  • Databases have been designed.

...

The portal is the icing on the cake. It will be targeted and developed at the very end.

Scope

Provide a rich and highly customizable environment for viewing data from all the above (and below) applications.

Status

We have developed three portlets to prove that we can extract data from external applications. These portlets can provide tables (from Logging and Fast Copy) and pots (from TelemetryTrending).

To-Do List

Do the rest.

Cross Trending/Reports

Scope

This application should give users the possibility to fetch histograms and data trends from all the above applications and to create scatter plots, overlays or tables of data.

...

A user would write reports in the form of jsp pages with some special tags to embed plots, text, links, etc.
These pages will be registered with the applications.
The application would provide a tabulated lists of all the available reports and a way to generate them on some time period.

Status

A toy version is available for the cross trending part. The Reports are still in the discussion phase.

To-Do List

  • Write database tables to store report jsp pages
  • Define tags API to embed plots in jsp apges

...