1 / 11

A framework for offline verification of Beam instrumentation systems

A framework for offline verification of Beam instrumentation systems. Analysis, & future direction. Motivation. BI systems need regular checks to confirm their beam readiness Detecting deterioration in performance and identifying physical problems / anomalies

danae
Télécharger la présentation

A framework for offline verification of Beam instrumentation systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A framework for offline verification of Beam instrumentation systems Analysis, & future direction

  2. Motivation • BI systems need regular checks to confirm their beam readiness • Detecting deterioration in performance and identifying physical problems / anomalies • Existing checks deployed in LHC sequencer tasks are generally comprehensive but… • Scope limited to LHC – No injector chain systems • Operator-centric tests aren’t directly accessible to hardware / software experts • As of 2013, several ad-hoc solutions emerged • Code-sharing / duplication in Java based applications • Manual data extraction and analysis using Timber • Many Python scripts from the BL section • etc…

  3. Problems With Current Python Scripts • Often, developers writing analysis code will ultimately leave CERN • Need to ensure the code is easy to maintain after they leave! • APIs would enforce standards to facilitate this long-term maintenance. • Also, choice of development language is an issue… • Python not officially supported in BE and not common in BI SW • In reality Python is used in many places and works • But some maintenance is needed from BI SW to add the additional libraries used by BL for example • When moving O/S (i.e. SLC5->SLC6), customization of bdidev1 needed • Code is not easily shared from BI SW Expert apps as these are always in Java or C++ • Moving to Java as analysis language also has issues • Learning curve steeper for equipment specialists • Heavier than a scripting language

  4. Current Environment Online Data flow Linux Front End S NFS Files Oracle matplotlib Detectors Extracted with system() call to java app Scripts.py Expert GUIs PyROOT • Problems • Clumsy data extraction • Little code re-use • PDF creation very verbose • PNG creation very verbose • Report distribution by email not always suitable • No direct access to historical reports SciPy PDF report Text report + images pdflatex Email specified users * Offline analysis (Python scripts as cron tasks)

  5. Language Neutral API Proposal Data Source APIs DataAPIs Source Interfaces Binary ReportingAPIs ReportTransport DataContainers ReportRenderers XML Report Data Title Row(s) X Data or XY Data Title Index Type (time, scalar, etc.) Colour …. Dictionary eMail PDF DataRenderers Table • Report Text • Content • Title • Type (HTML or Plain) • …. HTTP HTML Graph SourceFactories Text Oracle NFS File

  6. Database Alternative Results viewed on standard CERN data visualisation tools CERN Accelerator Data Services LSA Settings Database Accelerator Logging Service Results of analysis stored back in database Data sources Post Mortem System Generated PL/SQL or Oracle Enterprise R code Triggered by accelerator events or preset times Domain Specific Language (DSL) scripts

  7. Analysis Currently Operational • Java • Analysis is generally embedded within an Expert GUI • In some cases, for the BLM modulation tests for example, the code is re-used in a sequencer task • No pure analysis scripts exist outside the expert GUIs and sequencer • Python • Analysis is on a script-by-script basis • Some code sharing • 43 .py files. Many probably not used any more

  8. Example Java Analysis Code performing analysis shared with an LHC sequencer task Expert GUIs written in Java produce visual analysis of BLM connectivity checks

  9. Example Python Analysis PDF Report on BLM threshold changes Image of surface building temperatures and ‘nominal’ range in green Image of BLM CRC errors vs temperature

  10. Proposed API Implementation Products

  11. Next Steps… • Awaiting direction from database team for future of the DSL proposal • A large portion of the BLM analysis could be transferred to this solution • DSL scripts would be executed on the database, therefore they would be much more performant • Machine event triggered script execution as well as time based execution very interesting • Post-mortems, XPOC, etc • For the other analysis, need to decide on future language • Java or Python or both • A full implementation of the API should be made • Further investigations into new ideas such as web-site report distribution need to be made • Historical analysis retrieval etc • Discussions are currently ongoing as to who will carry out the implementation of the APIs and also timescales etc…

More Related