Bachelor’s Degree Project · experiments and non-LHC experiments. The Common Muon and Proton Appara-9. tusforStructureandSpectroscopy(COMPASS)experimentisoneofthenon-LHC ... ++11modethroughtheuseof-std=c++11

Czech Technical University in PragueFaculty of Nuclear Sciences and Physical

Engineering

Department of Software EngineeringCourse: Applied Software Engineering

User interface for control of logbook of COMPASSexperiment at CERN

Uživatelské rozhraní pro ovládání deníkuexperimentu COMPASS v CERN

Bachelor’s Degree Project

Author: Matouš JandekSupervisor: Ing. Martin BodlákYear: 2016

Statutory declaration

I hereby declare that I have elaborated this bachelor’s degree project independentlyand used no other aids that those cited. In each individual case, I have clearlyidentified the source of the passages that are taken word by word or paraphrasedfrom other works.

In Prague .................... ........................................Matouš Jandek

Acknowledgment

I would like to thank my supervisor, Ing. Martin Bodlák, for guiding and assistingme during the work on this bachelor’s degree project. I would also like to thankIng. Vladimír Jarý, Ph.D. for giving me an insight into the problematic whenever Ineeded. Finally, I would like to thank my family for supporting me in my effort.

Matouš Jandek

Název práce:Uživatelské rozhraní pro ovládání deníku experimentu COMPASS vCERNAutor: Matouš Jandek

Obor: Aplikace softwarového inženýrství

Druh práce: Bakalářská práce

Vedoucí práce: Ing. Martin BodlákMatematicko-fyzikální fakulta Univerzity Karlovy

Abstrakt: Tato bakalářská práce se soustředí na nahrazení počítačových programů,které slouží jako uživatelské rozhraní pro deník na experimentu COMPASS v CERN.Potřeba nahrazení starých programů vyvstala ze snahy o sjednocení technologiípoužívaných sofwarovým vybavením na experimentu. Aplikace vyvinuté jako součásttéto práce mají za cíl uspokojit tento požadavek při zachování veškeré funkcionality,a také poskytnout základ pro možné budoucí rozšíření této funkcionality. Práce dáleobsahuje seznámení s technologiemi použitými pro vývoj zmíněných aplikací, popisrelevantních součástí deníku, a také se zabývá popisem implementace vyvinutýchprogramů.

Klíčová slova: CERN, COMPASS, deník, počítačový program, GUI, databáze,C++, Qt, MySQL

Title:User interface for control of logbook of COMPASS experiment at CERN

Author: Matouš Jandek

Abstract: This bachelor’s degree project focuses on replacing the computer programsthat serve as a user interface of logbook of COMPASS experiment at CERN. Thenecessity to replace the old programs has arisen from the tendency to unify thetechnologies used by the software equipment at the experiment. The applicationsdeveloped as part of this degree project aim to satisfy this need while maintainingthe same functionality, and at the same time to provide a platform for a possibleenhancement of this functionality in the future. Additionally, the degree projectincludes an introduction to the technologies used to develop these applications,description of relevant parts of the logbook, and also deals with the implementationdetails of the programs.

Key words: CERN, COMPASS, logbook, computer program, GUI, database,C++, Qt, MySQL

Contents

Introduction 8

1 CERN & COMPASS experiment 9

1.1 CERN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 COMPASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 Data acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Used technologies 12

2.1 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.2 General description . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.3 Reasons for use of C++ . . . . . . . . . . . . . . . . . . . . . 13

2.1.4 Used Version . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


2.2.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3 Description of selected features . . . . . . . . . . . . . . . . . 15

2.2.4 Development Environment . . . . . . . . . . . . . . . . . . . . 17

2.2.5 Reasons for use of Qt . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.6 Used Version . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18


2.3.2 Reasons for use of MySQL . . . . . . . . . . . . . . . . . . . . 19

2.3.3 Used Version . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 ImageMagick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5



2.4.3 Reasons for use of ImageMagick . . . . . . . . . . . . . . . . . 20

2.4.4 Used Version . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 SCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20



2.5.3 Reasons for use of SCP . . . . . . . . . . . . . . . . . . . . . . 21

2.5.4 Used Version . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 COMPASS logbook 23

3.1 General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Description of selected components . . . . . . . . . . . . . . . . . . . 23

3.2.1 add_comment . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.2 run_manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.3 shift_manager . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.4 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Analysis of requirements 26

4.1 Shared non-functional requirements . . . . . . . . . . . . . . . . . . . 26

4.2 add_comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . 26

4.2.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . 27

4.3 run_manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . 29

4.3.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . 30

5 Implementation 32

5.1 Shared classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2 add_comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.1 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.2 Structure of the program . . . . . . . . . . . . . . . . . . . . . 33

5.2.3 Description of individual tasks . . . . . . . . . . . . . . . . . . 36

6

5.3 run_manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.3.1 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.3.2 Structure of the program . . . . . . . . . . . . . . . . . . . . . 39

5.3.3 Description of individual tasks . . . . . . . . . . . . . . . . . . 41

5.4 Integration with other applications . . . . . . . . . . . . . . . . . . . 44

Conclusion 45

Bibliography 46

Appendices 48

A Logbook database tables structure 48

B Installation instructions 55

B.1 Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

B.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

B.3 Public key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

B.4 Additional software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

C Content of the enclosed CD 57

7

Introduction

COMPASS, or Common Muon and Proton Apparatus for Structure and Spec-troscopy, is a high energy, fixed-target physics experiment located at CERN. One ofthe components of the supporting equipment at this experiment is a digital logbook,which is used to keep records about the operation of the experiment. The data inthe logbook are stored in a computer database, and can be accessed through aninterface provided by several computer programs.

The assignment of this bachelor’s degree project is to replace said interface withnew computer programs. These programs should be developed using the same tech-nologies as other software equipment used at the experiment and provide the samefunctionality as the programs that are set to be replaced. Furthermore, the pos-sibility of an upgrade in the future should be taken into consideration during theimplementation process.

This degree project focuses on the development of two programs called add_comment

and run_manager, which can manipulate different sets of information stored withinthe logbook system.

Chapter 1 gives an introduction to CERN and the COMPASS high-energy physicsexperiment.

Chapter 2 describes the technologies used for the development of the new graphicaluser interface programs. Programming languages and software frameworks directlyused to write the applications are presented, along with third party programs usedto implement some of the operations and a database management system that servesas a data storage.

Chapter 3 introduces the structure of the logbook of COMPASS experiment andprovides an overview of several components of this system, namely the databaseand its structure.

Chapter 4 discusses the requirements placed on the programs developed for thisdegree project. Both functional and non-functional requirements are analyzed.

Chapter 5 describes the implementation of both programs. It gives an overview ofthe layout of the graphical user interface, presents the structure of the programs andincludes a description of the performed task.

8

Chapter 1

CERN & COMPASS experiment

This chapter gives an introduction to CERN, and in particular the COMPASS ex-periment located at this research site.

1.1 CERN

CERN, the European Organization for Nuclear Research, was established in 1954.The name of this research organization is derived from French version of its name,which is “Conseil Européen pour la Recherche Nucléaire”. It is located on the Franco-Swiss border near Geneva. Currently, the group of participating countries consistsof 22 member states [1].

At the time of foundation, the aim was the study of structure of atoms. However,nowadays CERN’s main area of research is particle physics. Physicists and researchesare seeking answers on questions concerning the fundamental constituents of matterand the forces acting between them. The main instruments for this are particleaccelerators and detectors [1].

Particle accelerators, either circular or linear, have the task to speed up and henceincrease the energy of beams of particles, which are then set to collide with eachother or with stationary targets. The detectors gather information about particlesin order to identify them [1].

The most powerful accelerator at CERN is the Large Hadron Collider (LHC). Itwas launched in 2008 and its main part is a circular tunnel with a circumference of27 kilometers, in which two particle beams are accelerated to a speed close to thespeed of light before they collide [1].

1.2 COMPASS

Experiments currently performed at CERN can be divided into two groups – LHCexperiments and non-LHC experiments. The Common Muon and Proton Appara-

9

tus for Structure and Spectroscopy (COMPASS) experiment is one of the non-LHCexperiments. Currently, almost 220 physicists from 13 countries and 24 institutionswork in COMPASS [2].

The experiment was conditionally approved in 1997, the spectrometer was installedwithin years 1999–2000 and data acquisition started in summer 2002. The mea-surements on this experiment continue until now, with only few interruptions dueto planed shutdowns. The longest of these shut downs was the Long Shutdown 1(LS1) in CERN in years 2013-2015. COMPASS Data Acquisition (DAQ) system wasmodernized during this period [3].

Researches working on this experiment investigate the nucleon spin structure andthe spectroscopy of hadrons [4]. High energy muon and hadron beams are providedby Super Proton Synchrotron (SPS), the second-largest accelerator at CERN withcircumference of nearly 7 kilometers [1]. The apparatus was originally built for spinstructure studies with a muon beam, however it was successfully used with positiveand negative hadron beams [5]. For some measurements a solid ammonia polar-ized target inside a superconducting magnet can be used. Outgoing particles aredetected by two-stage spectrometer and particle identification is achieved by usinga Ring Imaging Cherenkov (RICH) counter and both hadron and electromagneticcalorimeters.

The setup has been successfully operated from 2002 onwards using a muon beam.Data with a hadron beam were collected in 2004 [4]. In 2006 the program continuedwith measurements with muon beam, and in 2008 and 2009, COMPASS hadronspectroscopy program with pion and proton beam was conducted. This was followedby spin structure function measurements with a polarized proton target in 2010 and2011 [2].

At present, the experiment has been modified for the Deeply Virtual Compton Scat-tering (DVCS) run with a liquid hydrogen target and a muon beam.

Figure 1.1: Artistic view of the layout of the spectrometer used in COMPASSexperiment [2]

10

1.3 Data acquisition

The COMPASS experiment generates approximately 1.5 GB of data per secondduring a 10 second spill. Such amount cannot be stored locally in the so called front-ends, the first layer of the COMPASS Data acquisition (DAQ) system. The data istherefore grouped together into subevents, which is done by CATCH, GeSiCA, andGandalf VME-standard-based concentrator modules [3].

The readout of these subevents and their assembly and buffering is then performedby two layers of field programmable gate array (FPGA) cards, which replaced theoriginal server-based event building and buffering system. The resulting full eventsare then processed by readout engine computers, stored at first on local hard disksand subsequently transferred to CASTOR, the central storage facility of CERN [3].

The new DAQ system enables configuration and control of hardware, monitors datataking, controls data flow and log information and monitors errors and messagesfrom system. This is ensured by six main processes: Master, Slave-control, Slave-readout, GUI, Message Logger and Message Browser. Master process is used forcommunication between GUI and Slave processes, Slave-control process controlsand monitors FPGA cards, Slave-readout monitors the readout process and GUImonitors the state of the entire DAQ. Message Logger is a console application whichreceives informative and error messages from other processes and Message Browserenables access to these messages [3].

11

Chapter 2

Used technologies

This chapter describes technologies that were used to develop the programs that arethe subject of this degree project.

The described technologies consist of the C++ programming language, Qt frame-work, MySQL database management system, ImageMagick software suite and SCPtransfer protocol.

2.1 C++

C++ is one of the most used programming languages in the world. According toTIOBE index, it was the third most popular language as of April 2016, with ratingof 5.918% [6].

2.1.1 History

In order to describe the development of C++, it is necessary to first mention the Cprogramming language. This Language was designed to incorporate two approachesthat are seemingly mutually exclusive—to provide a high-level language, and the ad-vantage of faster program development, while still maintaining a level of abstractionclose to the device’s hardware along with resulting performance benefits.

Chief motivation for the development of C++ was to create a language with sup-port for object-oriented programming and good performance of resulting programs.Its creator, Bjarne Stroustrup, has decided to base the new language on C becauseof the mentioned performance characteristics. The improvements over standard Cinclude implementation of classes, inheritance, inlining, default function argumentsand others. More features were added over time, such as virtual methods, func-tion overloading, passing function arguments by reference, single line comments andothers [7].

Nevertheless, for a long time, there was no official standard for C++. The main sourceof information, which functioned as the reference manual for C++, was Stroustrup’s

12

“The C++ Programming Language”, and later also “The Annotated C++ ReferenceManual” [7]. The first official C++ standard was published in 1998 by the C++ stan-dards committee under the name ISO/IEC 14882:1998, or more informally knownas C++98. The current C++ standard version is ISO/IEC 14882:2011 (C++11) [8].

2.1.2 General description

Good performance of programs was the chief motivation behind the creation of C++.One of the main principles in design of C++ is a so-called “principle of zero overhead”that dictates that a C++ code should never run slower due to unused features [8].Other performance benefits stem from using C as the basis of C++. C, despite beinga high-level language, generates very fast programs, namely because of the fact thatthe language’s level of abstraction is still very close to the hardware. One of thegoals of C++ always was to be as close to C as possible in this regard [9].

In practical use, C++ is in most cases compiled directly to machine’s native code.This generally results in further performance benefit for the resulting programs,when compared to interpreted programs.

C++ was also designed with support for various programming styles and techniquesin mind. The underlying philosophy also says that it should be as easy as possible tocombine several styles in C++. The most directly supported techniques include [9]:

• procedural programming

• data abstraction

• object-oriented programming

• generic programming

Maintaining 100 percent backwards compatibility with C was never the goal forC++ [9]. Despite that, nearly all C features and constructs are supported by C++. Itis however worth noting that some of the keywords have a different meaning in eachlanguage [10].

C++ traditionally supported only manifest typing. Therefore, each variable had tohave a predefined type at the time of compilation. However, as of C++11, it alsosupports inferred typing through the “auto” keyword.

C++ is a statically typed language. All variable types are thus checked at the compiletime, and any errors caused by a type mismatch result in unsuccessful compilation.

2.1.3 Reasons for use of C++

All programs that are the subject of this degree project were developed with theuse of Qt framework. As such, there were two programming languages availablefor selection—C++ and QML. Due to the nature of the requirements, using QMLas the primary language would likely still result in the need to implement partsof the code in C++. Furthermore, QML is a language primarily targeting mobile

13

platforms, which is not the case, as the applications will be used on a desktopplatform. Additionally, the developed programs also aim to use the same technologiesas other software equipment on the COMPASS experiment. Because of these reasons,C++ programming language was the only possible choice.

2.1.4 Used Version

All programs that are the subject of this degree project were compiled with 64 bitversion of GCC compiler, version number 4.8.5 20150623 (Red Hat 4.8.5-4). Thecompiler was set to operate in C++11 mode through the use of -std=c++11 flag.

2.2 Qt


Qt is a cross-platform framework based on the C++ programming language. It pro-vides a set of features, which most prominently target the development of platform-independent applications with graphical user interface (GUI). As C++ or its standardlibraries do not provide any possibility to create a GUI, this characteristic is verydesirable.

At this date, The development of Qt is governed by an organization called TheQt Project. It is a consensus based community of developers and other subjects.The main participant is a company now known as The Qt Company, which is theoriginal developer of the framework. One of the key principles of this establishmentis that anyone can propose a change to Qt source code. These proposed changes arethen reviewed by selected approvers. This decision making model has the advantageof allowing anyone to contribute to the project (thus making it possible to reactfaster to changes in the field of software development), while maintaining qualityand reliability of the framework.

Supported platforms include all Windows desktop versions beginning with WindowsXP, several Linux distributions, such as Ubuntu and RHEL based distributions,Apple OS X, mobile platforms like Windows Phone, iOS and Android, and variousembedded systems. Unofficially Qt works on even more operating system. This cat-egory consists mostly of Linux distributions that were not tested for compatibility,and thus no official support can be provided. Apart from that, with additional effortfrom the application developer, Qt will also work on systems like Windows versionsother than those previously mentioned, BSD distributions or Haiku [11].

Several of the extension features are handled by a preprocessor called MOC (Meta-Object Compiler). Before compilation, MOC parses the source code and produces aC++ compliant code, which is then processed by a regular compiler. As a result, thisframework can be used in conjunction with commonly-used compilers, like GCC,ICC, MSVC, Clang or others.

14

As stated before, the framework is mainly intended for development of GUI appli-cations, nevertheless, it is possible to develop non-GUI applications as well.

One of the main advantages of using the framework is that programs developed withQt can be deployed on any of the supported platforms with few to no changes tothe source code.

2.2.2 Modules

Qt framework is divided into building blocks called modules. Every module is alibrary targeting specific area, and contains necessary tools to work with it. Modulescan be sorted into two categories: Qt Essential Modules and Qt Add-On Modules.

Qt Essential Modules are supported on every platform, and thus, they are alwaysavailable to the programmer. They include convenience classes for easier data rep-resentation and manipulation, basic interfaces for communication with program re-sources, and facilities for creating GUI application.

Qt Add-On Modules provide the programmer with tools for more specific purposes.All of these modules individually specify their compatibility requirements, and someof them can be entirely platform-specific.

The following modules were used for the development of the programs that aredescribed in this degree project:

• Qt Core is a core module containing basic non-GUI classes. It is required byevery other module.

• Qt GUI contains graphical user interface classes, including components forusage of OpenGL API within the application. This module is used by everyother Qt class with capability for creating graphical user interface.

• Qt SQL is a module for communication with SQL databases. Several databasedrivers are included, for example drivers for MySQL, Microsoft SQL, Oracledatabase and others.

• Qt Widgets holds “Widget” classes for GUI application. Widgets consist ofvarious input and output elements such as buttons, labels, editable fields etc.

2.2.3 Description of selected features

Graphical user interface

There are many data structures, protocols and other computer technologies thatare easy to work with when using the Qt framework. One of them, however, couldbe considered the most prominent—GUI application development. Qt presents twopossible ways to create such programs.

The first is an approach using so-called widgets. Widgets are C++ classes that repre-sent input and output elements like text boxes or buttons. First possibility to create

15

a widget-based application is to create required widgets directly in the C++ code.Second approach is to design the GUI before compilation in a form of an XML file,called UI file or form. The form is then translated to C++ object file by a tool namedUIC (User Interface Compiler) [12] before compilation, and then processed by reg-ular C++ compiler in a usual manner. The programmer can naturally access andmodify individual elements in the form from C++ code. Basic resources for creatinga widget based application are included in the Qt Widgets module.

Second possibility, available since Qt 4.7 [12], is to use the Qt Quick framework.Qt Quick introduces a completely new programming language—QML. QML is adeclarative language, designed to implement the GUI of an application. User inputcan be handled by JavaScript, which is integrated into Qt Quick framework, or byC++ code. This approach is intended mainly to design software for mobile devices,but there is no limitation that would prohibit Qt Quick from being used to targetdesktop platforms. Basic resources for creating QML based application are includedin the Qt Quick module.

Signals & Slots mechanism

One of the most significant features of Qt is its Signals & Slots mechanism. Animportant part of object-oriented programming and GUI programming is the com-munication between individual objects. Signals & Slots mechanism aims at makingthis part of development process as easy as possible. When an event occurs, objectcan emit a signal to indicate such event. Other object can then detect this signaland perform relevant operations as a reaction.

As there is no basis for handling a mechanism such as Signals & Slots in pure C++,source code that takes advantage of this feature must first be processed by the MOCpreprocessor, which generates valid C++ code.

Both signals and slots are declared in the same way as regular functions are. Signals,however, must only be declared, and their implementation is handled by MOC.

There are no restrictions placed on to how many slots is a single signal connected, orhow many signals are connected to a slot. One of key principles in the Signals & Slotsmechanism is the fact that object participating in a signal-slot connection have noknowledge of each other. Objects emitting signals are not aware which slot, or evenif any slot receives the signal. In the same manner, a slot is not aware which objectemitted the received signal. This behavior was conceived to ensure that this featuredoes not contravene the possibility of creating independent software components [12].

The Signals & Slots mechanism is included in the the Qt Core module.

Containers

Qt also contains many classes useful for easier data representation. An example isthe “Tulip” container system, which is similar to C++ Standard Template Library.Tulip provides both sequential containers like QList, QLinkedList or QVector, and

16

associative containers like QMap [12], as well as new foreach keyword that enables toiterate over any container from Tulip collection.

The Tulip container collection is included in the the Qt Core module.

Rich text documents processing

Rich text documents in Qt are handled through the “Scribe” framework. The cen-tral structure in the framework is the QTextDocument class that represents singledocument, and contains information about both structure and contents.

Internally, the document is stored in a hierarchical structure. Key elements areQTextFrame, which holds a list of child elements (which can also be frames), andQTextBlock, representing a block of text. Each QTextDocument class contains a rootframe, which contains a sequence of other elements [12].

There are two ways to access the document content. One way is to directly ac-cess the elements in the documents hierarchy. Second way is to use a cursor-basedinterface [12], which behaves in a similar manner as a cursor visible to the user.

The Scribe framework is included in the the Qt Core module.

2.2.4 Development Environment

Because of the fact that all features provided by Qt framework are either imple-mented with the use of C++ standard compliant code, or they are translated intoC++ standard compliant code by one of the parsers used by Qt, projects using theframework can be developed in virtually any software environment with text editor,required Qt libraries and a C++ compiler (requirements on C++ standard complianceand the required standard version may vary depending on which Qt version is used).Integration with various IDEs is also possible.

Qt Project however offers their own IDE called Qt Creator. It provides the userwith common functionalities such as project management, code editor with codehighlighting and code completion, but also Qt specific features aimed at GUI devel-opment. An example of such tool is Qt Designer. It is a WYSIWYG editor of theapplications GUI for projects using Qt widgets.

Apart from the Qt Creator, Qt Project currently also provides an officially supportedplugin for Microsoft Visual Studio [12].

2.2.5 Reasons for use of Qt

One of the aspirations of the applications described in this degree project is to helpto unify the software equipment on the COMPASS experiment, where all recentlydeployed programs are written in C++ with the use of Qt framework. Selection ofQt as the development tool was therefore part of the assignment.

17

2.2.6 Used Version

All programs that are the subject of this degree project were created using Qtframework version 5.6.1-3 and Qt Creator version 3.5.1-3. All of the programs useQt Core, Qt GUI, Qt Widgets and Qt SQL modules.

2.3 MySQL


MySQL is a relational database management system. It is an open-source software,offered either under GPL or commercial license. As the name suggests, it is based onthe SQL programming language, which it uses to manage the data stored within thedatabase. However, like other common SQL-based database management systems(DBMS), MySQL does not fully conform to the SQL standard.

Most parts of MySQL are written in C and C++, but the SQL language parser isgenerated with Bison parser generator, and the lexical analyzer was hand written,as opposed to being generated by lexical analyzer generator [13] [14].

For each database table, MySQL gives the option to select which storage enginewill be used. Several storage engines are provided in basic MySQL distribution, anddue to the modular design of this part of MySQL, called Pluggable Storage EngineArchitecture [14], third party storage engines may be used as well. Storage enginesincluded in standard MySQL version 5.7 installation are [14]:

• InnoDB is currently the default storage engine. It is transactional, and there-fore complies with the ACID principle. It supports foreign keys to providemeans for maintaining data integrity.

• MyISAM used to be the default storage engine before MySQL version 5.5.In many situations, however, it can perform operation faster than the InnoDBstorage engine [15].

• MEMORY stores the data in memory. As a result, tables using this storageengine can benefit from higher transfer rates and therefore better performance,but the data is at a risk of being lost in case of system shutdown or crash.

• CSV engine stores table data in comma-separated values (csv) format.

• ARCHIVE is intended to store data while reducing the storage requirements.Data is compressed using zlib compression. However, it only allows a singleindex in the form of auto-increment column, and does not support DELETE andUPDATE commands.

• BLACKHOLE storage engine will accept data, but without saving them.Database queries attempting to read data will always return empty result.This storage engine can be used for testing, or in some scenarios where datais being copied to database on a different host.

18

• MERGE combines several existing MyISAM tables into a new one. The tablesused in creation must have the same structure.

• FEDERATED serves as a link to data stored in a different database. Anyqueries to such table are send to the remote database to be executed. No datais stored locally.

• EXAMPLE aims to provide guidelines to developers creating new storageengine. It does not perform any operations on its own.

MySQL itself does not have graphical user interface, and the user can use only theprovided command line interface to give input to the DBMS by using statementswritten in SQL language. However, there are many applications that provide graph-ical front end to the database.

2.3.2 Reasons for use of MySQL

Functionality of all developed programs depends on manipulation with data storedin database, and they are required to use existing database tables running on MySQLDBMS. Programs must therefore use MySQL statements to meet the requirements.

2.3.3 Used Version

Logbook database on COMPASS experiment runs on MySQL DBMS version 5.5.During development, testing database was stored using the MariaDB DBMS1 inversion 5.5.47-1. Furthermore, two front end applications were used to manage thedata in the database: MySQL workbench, which is the official GUI environment forMySQL DBMS, and phpMyAdmin, which is a web-browser- application written inPHP.

2.4 ImageMagick


ImageMagick is a collection of command line tools used to create, edit, compose, orconvert bitmap images [17].

The suite provides tools to perform many kinds of operations, for example vari-ous forms transformation, addition of visual elements to existing images, formatconversion. Over 200 image formats are supported.

ImageMagick suite also places emphasis on good performance, and programs fromthe collection usually utilize as many computational threads as possible to achievethis goal [17].

1MariaDB is a project fork of the MySQL DBMS. In practical applications, MariaDB can beused as a one-to-one replacement of MySQL DBMS of the same version [16].

19


import

The import command creates an image created by capturing the screen, or part ofthe screen, of an X server.

In its basic form, the syntax is very simple. The example below lets the user selecta part of screen to be captured, and saves the result in a jpg format:

import image.jpg

However, many options are available to modify the output. User can for exampleperform basic editing tasks on the created image, choose an interlacing scheme ormodify the quality of the image. This following example shows how the importcommand is used by the developed applications. This command captures part of thescreen and adds an interlacing scheme:

import -interlace line gif:- > image.gif

2.4.3 Reasons for use of ImageMagick

add_comment application is required to have the ability to take screenshots of se-lected part of desktop. Since ImageMagick suite is used by the applications cur-rently deployed in COMPASS experiment, it was already proven to be reliable andthe interface is familiar to the potential users. Furthermore, it is still maintainedand improved. Therefore, there was no reason to search for alternative solutions.

2.4.4 Used Version

All programs that are the subject of this degree project were tested with ImageMag-ick version 6.7.8.9-15.

2.5 SCP


Secure Copy Protocol, or SCP, is a protocol designed to transfer files between twocomputers connected to a network. The file transfer is executed through a SecureShell (SSH) protocol connection. In consequence, the transferred data is encrypted.

SCP implementations (which will be also called “programs” in this section for pur-pose of simplification) can work in three modes. Two basic ones are “source” modeand “sink” mode. In source mode, the program sends a locally stored file to a re-mote host, while in sink mode, the program receives a file sent by another host.

20

These modes, however, are normally not explicitly stated by the user and commonSCP implementations usually start in the appropriate one automatically. If the thirdmode, called “remote-to-remote”, is invoked, the program opens an SSH connectionto another host and orders it to start an SCP session with a third host. It should benoted that this mode will not work with password or keyboard-interactive authen-tication, as this would require to reveal the password to the host that is instructedto open an SCP session [18].

When a non-remote-to-remote SCP session starts, the program opens an SSH con-nection to the destination host. After a successful authentication, it instructs theremote host to execute the SCP command as well. After that, the data exchangewill begin. SCP programs communicate in a form of text messages that contain in-formation about the type of the file to be transferred and binary data that representthe transferred file [18].

There is no file size limitation stated in the protocol specification. The only restric-tions are imposed by specifics of individual SCP implementations and any techno-logical limits of the two host devices using the protocol (namely a maximum file sizedefined by the hosts file system) [18].


Public-key cryptography

Public-key cryptography is a form of asymmetrical encoding, which enables twodevices to communicate securely by using a matched pair of keys: one public key,which is used to encrypt the message before transmitting it, and one private key,which is then used on the second device to decrypt the message after receiving it.

The advantage of this scheme is the fact that the public key can be freely shared,because it can be used only for encryption, and cannot be used to decrypt thecommunication. As a result, it makes it easier to safely setup an encrypted one-waycommunication.

SCP protocol supports the use of public-key cryptography. When using this protocolin conjunction with a public key, another advantage is that if one host already knowsthe public key of target host, they can achieve a secured transfer of files without theneed for authentication.

2.5.3 Reasons for use of SCP

add_comment provides the option to capture parts of the screen as images, which mustbe subsequently uploaded to a remote server. As was required by the assignment,all such files are transferred through the use of SCP protocol.

21

2.5.4 Used Version

The testing of the developed programs was done on a system, where the SCP im-plementation was provided by the OpenSSH software suite in version 6.6.1p1-25.However, any SCP implementation that supports the same command syntax forcopying files to remote host as the scp command from OpenSSH should work aswell 2.

2The required command syntax is scp file remotehost:directory, where file is the pathto the file intended to be copied, remotehost is the address of the remote host, and directoryis the path, where the file should be stored on the remote host

22

Chapter 3

COMPASS logbook

3.1 General description

Logbook of the COMPASS experiment is a system consisting of several softwarecomponents, which are used to store various operational data related to the exper-iment and data acquisition. These data include records of individual experimentalruns and shifts overseeing the experiment and also a message subsystem, which canbe used by participants of the experiment to submit comments that can then beviewed by other participants.

3.2 Description of selected components

3.2.1 add_comment

Part of the logbook of the COMPASS experiment is an online message board thatallows the participants of the experiment to post messages, which can be viewed bythe rest of the team in a web-browser-based application. Messages in this systemare rich text messages and can consist of text and/or images.

add_comment is a desktop application that allows the user to create and subsequentlysend such messages. It also provides necessary interface to capture parts of the screenand embed resulting images into the message.

3.2.2 run_manager

run_manager is a desktop program that serves as a viewing and editing applicationfor records containing information about individual runs. It enables to select a run,after which the user can view information like problems on detectors or summary ofthe run, and also edit and subsequently save the changes into the system.

23

3.2.3 shift_manager

Another part of the logbook database interface is shift_manager, a program than isused to work with records about shifts. It can load shift information from database,then modify it and save the changes. Additionally, it can create a new shift record andinsert it into the database. Comments, which are part of each shift data, can containimages in the same manner as messages created with add_comment. Furthermore, itallows the user to associate other types of documents with the message and uploadthem to logbook servers.

3.2.4 Database

Central part of the logbook is a database that stores the data, which are usuallycreated and accessed by GUI applications. The database is powered by a MySQLserver. This section describes several of the database tables held in the logbookdatabase, which are essential to the operation of programs that were developed aspart of this degree project. Relations between these tables are depicted in EERdiagram in Figure 3.1.

Tables depicted in Figure 3.1 and their purpose is described individually in thissection. Their detailed structure is described in Appendix A.

• cfg_directories: This table serves as a list of configurations managing thestorage of the data needed to operate the logbook. These configurations consistof default storage directory settings for different types of files. The list ofdirectories is stored in table ‘tb_directories‘.

• seq_comment: This table has only one column and one row, which stores theidentification number of the last inserted row in the table tb_comment. Thisarrangement is necessary because the ID must be available prior to insert-ing new row into tb_comment. By utilizing this table and MySQL functionLAST_INSERT_ID, it is possible to reserve new ID for future use.

• seq_pict: This table serves the same purpose as table seq_comment, but itstores the ID of the last inserted row in table tb_pict.

• tb_commdomains: This table stores the list of available domains. A domain canbe characterized as a subsystem of the experiment. Examples of such subsys-tem are DAQ (data acquisition), trigger or individual detectors.

• tb_comment: This table stores information about comment messages that arepart of the COMPASS logbook. All data that can be inserted into the message,with the exception of images, are stored in this table.

• tb_directories: This table holds a list of all available directories used to storefiles needed to operate the logbook.

• tb_errordetcode: This table serves as a list of possible errors that may occuron the detectors at the experiment.

24

Figure 3.1: EER diagram describing relations between selected tables from logbookdatabase.

• tb_pbtype: This table serves as a list of possible problems that may occur atthe experiment during experimental runs.

• tb_pict: This table contains records of all image files used by logbook com-ponents. It most prominently serves as a lookup table for image files’ storagepath and name.

• tb_run: This table stores records about individual experimental runs.

• tb_runtype: This table stores a list of all possible types of runs, and their basicdescription.

• tb_shift: This table stores records about individual shifts overseeing the ex-periment.

25

Chapter 4

Analysis of requirements

4.1 Shared non-functional requirements

This section describes non-functional requirements that are placed on all of thedescribed programs.

Operating System

All programs target a platform running on Scientific Linux CERN operating system,version 6.1. Scientific Linux CERN is a rebuild of Scientific Linux, which in turn isa rebuild of the Read Hat Enterprise Linux [19].

Use of existing databases

All applications are required to use existing database infrastructure to store andretrieve necessary data. Data must be loaded from and saved to a database storedin a MySQL database management system. Database structure is described in sec-tion 3.2.4 and the structure of individual tables in Appendix A. Requirements on howindividual programs access the data in this database are described in correspondingsections.

4.2 add_comment

For basic description of this program’s functionality, see section 3.2.1.

4.2.1 Functional requirements

Several requirements are placed on the contents of the messages. This programmust provide necessary facilities to allow the user to input all of the possible pieces

26

of information.

Each message is required to contain following pieces of information:

• Authors name

• Domain:Domain specifies, to which subsystem the message applies. Examplesof such subsystem are DAQ, Trigger or individual detectors.

• Subject of the message

• Contents of the message: Each message can contain text and any numberof images. Images are embedded directly into the text at a given position.

Furthermore, the user can optionally denote any message already stored in the sys-tem to indicate a reference to it. Messages are identified by their unique identificationnumber.

The application must also provide an interface that allows the insertion of a capturedpart of the screen directly into the text as an image. The user must be able to eitherselect the desired part of the screen through the use of a dragging gesture, or clickingthe title bar to capture only the desired window. Resulting image is placed in themessage at the current location of the text cursor.

After all necessary pieces of information are filled in, the user must be able to submitthe message to be stored in the system.

4.2.2 Non-functional requirements

Operating system

See section 4.1.


See section 4.1.

GUI layout

Graphical user interface of the newly developed version of add_comment is requiredto have the same layout as the version of the program that is currently being usedat COMPASS experiment. Figure 4.1 depicts the layout of that version.

List of domains

The list of domains, as shown in Figure 4.1, is created during program initializationby reading relevant data from database. The list is populated by entries from thecolumn ‘domainid‘ in table ‘tb_commdomains‘.

27

Figure 4.1: currently used version of add_comment program

Author: Editable text field for the author’s name.Comment: Editable text area for the contents of the message. In-

serted images are also displayed here at their positionwithin the text.

Domain: Non-editable drop-down menu that contains a list ofall available domains.

Grab Window: Button that starts the process of capturing part ofthe screen and inserting it into the text as an image.

Quit: Button that terminates the program.Ref to comment #: Editable text field for the identification number of the

referenced message.Subject: Editable text field for the subject of the message.Submit this comment: Button that submits the entire message and stores it

in the system, provided that all fields contain validinput.

Storage of textual data

Textual data consist of all message data with the exception of the images embeddedin the text, which are stored separately (see next part of this section for descriptionof image storage). The position in text of each individual image is marked by insert-ing the following HTML tag: <img src=’show_pict.php?pictid=images_id’/> intothe message text at proper position, where images_id is the image’s identificationnumber.

Each message also stores an identification number of the current shift. This iden-tification number is retrieved from the column ‘shiftid‘ in table ‘tb_shift‘. Thecurrent shift is the one that has the highest identification number.

All textual data of any submitted message must be stored in the form of a databaseentry in the table ‘tb_comment‘.

28

Storage of image files

Images inserted into the message are stored separately from the rest of the data.

When storing an image file, the program must first determine the location of theimage repository. This is done by reading the logbook directory configuration storedin table ‘cfg_directories‘. The relevant information is stored in the row whosecolumn ‘name‘ holds the value ‘pictfiles‘.

After loading the configuration data from the database, image files are transferredto the target host and directory through the use of SCP protocol. The applicationuses the SCP protocol under the assumption that local implementation of SCP hasthe public key of the targeted host at its disposal, and thus there is no need toprovide any authentication details.

If the transfer of the files is successful, it is necessary to update the information intable ‘tb_pict‘. The table contains a list of image resources used in the logbooksystem.

4.3 run_manager

For basic description of this program’s functionality, see section 3.2.2.

4.3.1 Functional requirements

User must be able to select the run to be viewed and/or edited by providing theprogram with the runs identification number. Furthermore, they can select previousor next run in relation to the currently selected run.

After selecting the run, the program must display key pieces of information aboutit. These consists of:

• Comments: This is a message describing the run and providing additionalinformation.

• Errors on detectors: User can mark detectors that exhibited problems.

• General problems: User can mark general problems that occurred duringthe run. Such problems may be for example problems with the particle beamor data acquisition system.

• Run type: Each run has an associated run type that specifies its purpose.

• Title: Title contains brief description of the run.

Furthermore, the user can at this point edit each entry, and save the result into thesystem.

29

4.3.2 Non-functional requirements

Operating system

See section 4.1.


See section 4.1.

GUI layout

Graphical user interface of the newly developed version of run_manager is requiredto have the same layout as the version of the program that is currently being usedat COMPASS experiment. Figure 4.2 depicts the layout of that version.

list of run types

The “Run type” list, as shown in Figure 4.2, is created during program initializationby reading relevant data from database. The list is populated by entries from thecolumn ‘keyword‘ in table ‘tb_runtype‘.

Problems list

The “Problem list”, as shown in Figure 4.2, is created during program initializationby reading relevant data from database. The list is populated by entries from thecolumn ‘keyword‘ in table ‘tb_pbtype‘.

List of errors on detectors

The “Errors on detectors” list, as shown in Figure 4.2, is created during programinitialization by reading relevant data from database. The list is populated by entriesfrom the column ‘detname‘ in table ‘tb_errordetcodes‘.

Storage of saved data

When the user chooses to save changes to the loaded data, it is necessary to updatethe corresponding row in the table ‘tb_run‘.

30

Figure 4.2: currently used version of run_manager program

Comments: Editable text area, where the user can view or add anyadditional information relevant to the selected run.

Errors on detectors: Group of checkboxes that is used to view and edit a listof errors that occurred on the detectors during the run.

Problem List: Group of checkboxes that is used to view and edit a listof general problems that transpired during the run.

Run Type: Non-editable drop-down menu, that allows the user toview and modify the type of the selected run.

Quit: Button that terminates the program.Save these infos: Button that saves any user-made changes into the sys-

tem, provided that all fields contain valid input.Select a run: Button that brings up a run-selection dialog. Run is se-

lected based on its identification number.Select next run: Button that selects the following run.Select previous run: Button that selects the preceding run.Title: Editable text field for the run’s title.

31

Chapter 5

Implementation

5.1 Shared classes

Since the programs often perform same operations, it was advantageous to firstimplement abstract classes, which can provide methods intended to be utilized bytheir subclasses. These methods include both public and protected methods.

LbCore

LbCore is an abstract class that serves as parent class for AcCore in add_comment andRmCore in run_manager, which act as the central classes in their respective programs.

Both subclasses store data retrieved from database in same format, and manipulatethem in the same manner. This shared functionality is implemented in LbCore. Thisclass does not, however, implement any public methods.

LbMySqlConnection

add_comment and run_manager rely on database communication and since many ofthe performed tasks are identical, they are provided by this parent class. It holds aninstance of class QSqlDatabase, which represents a connection to the database, andexecutes some of the database queries. Most prominently, it implements all methodsnecessary to upload files to the COMPASS logbook server. Like LbCore, this class isabstract and it is intended to be used by subclassing it.

5.2 add_comment

add_comment is a desktop application with graphical user interface (GUI) that iswritten in C++ language. The implementation uses Qt framework to implementboth the GUI and the back end.

32

5.2.1 GUI

The interface has only one window, which provides all necessary functions. Further-more, user can be informed about the status of the program by pop up messageboxes.

GUI layout was unchanged from the previously used implementation of the program.This was one of the requirements placed on the application. It is however an entirelyseparate implementation and internally, it has no parts in common with the oldversion of the program. The interface of the new program is depicted in Figure 5.1.

Figure 5.1: new version of add_comment

The interface was implemented using the “Widgets” approach provided by the QtWidgets module. It was created by using the “form” XML file, which was in turncreated by using the Qt Designer included in Qt Creator IDE.

All visual elements are represented by matching widget classes: labels “Author:”,“Domain:”, “Ref to comment #”, “Subject:” and “Comment:” by QLabel, buttons“Grab a window”, “Submit this comment” and “Quit” by QPushButton, all singleline text fields by QLineEdit, Editable text area for the body of the comment byQTextEdit and the domain selection combo box by QComboBox. The elements arearranged into lines by using the layout class QHBoxLayout. Information pop up boxesare implemented using QMessageBox class.

5.2.2 Structure of the program

The structure of add_comment is centered around the AcCore class, which directsthe communication between front end and other back end classes. AcMainWindow isresponsible for the user interface, AcMySqlConnection for database communication,LbWindowGrabber handles screen capture. Comment submit is implemented by classesAcCommentSender and LbFileUploader.

All classes use exceptions to signalize errors or invalid user input. Exceptions thrownduring program initialization are handled from main() function. Other exceptionsare caught and processed in class AcMainWindow.

33

General structure of this application is depicted in class diagram in Figure 5.2.

Figure 5.2: class diagram of add_comment

AcMainWindow

User interface is implemented in class AcMainWindow. Its main purpose is to processsignals sent by buttons which are emitted upon clicking them. It holds an instanceof AcCore class, and signals emitted by buttons are usually followed by a call to acorresponding method in AcCore class. It also holds an instance of the pre-generatedclass that contains the GUI elements.

34

AcCore

The central class in the application is AcCore, which facilitates communication andinteroperability between other classes. It provides an interface of public methods,which allow the front end represented by class AcMainWindow to perform necessaryoperations without any knowledge of actual structure of classes that implement theseoperations.

Apart from this, it stores instances of class AcMySqlConnection for database commu-nication, and LbWindowGrabber, which is used to capture parts of the screen.

Furthermore, it stores a hash table, which is used to translate the value selected bythe user in the domain selection combo box to an integer value that represents thedomain in the database. The Hash table is implemented by QHash class.

AcCore is a subclass of LbCore.

AcMySqlConnection

AcMySqlConnection class is responsible for all communication between the programand a database server, which holds the tables containing the data necessary for theoperation of this application. It implements methods that perform specific databasequeries and return the results where necessary.

This class is a subclass of the abstract class LbMySqlConnection.

LbWindowGrabber

Class LbWindowGrabber executes the screen capture functionality. It does so by callingan external program import, which is from the ImageMagick collection. The imageoutput is then processed by programs from Netpbm collection to ensure its validity,after which it is saved to the disk. All of these external programs are called frominstances of class QProcess.

AcCommentSender

The class AcCommentSender is used to submit the comment and all related data. Itfirst processes the user input by checking its validity and converting it into dataformats required by the database. After this task is finished, it calls appropriatemethods from classes AcMySqlConnection and LbFileUploader, which execute thedatabase query and upload the image files to a remote host respectively.

LbFileUploader

LbFileUploader class is responsible for transfer of image files to remote host. This isaccomplished by using scp command that is called through the class QProcess. After

35

uploading the file, the class also calls corresponding method from LbMySqlConnection

class to insert new row, which holds the information about the uploaded image file,into the database.

5.2.3 Description of individual tasks

add_comment’s functionality can be characterized by three major tasks, which aredescribed below.

Initialization

Figure 5.3: Activity diagram of initialization of add_comment

After starting add_comment, the first task is the initialization of an instance of classAcMainWindow. This class then creates an instance of AcCore.

AcCore in turn creates instances of classes AcMySqlConnection and LbWindowGrabber.These classes attempt to open a database connection and create a directory onthe hard disk to store images respectively. AcCore then uses AcMySqlConnection toretrieve the list of comment domains from database.

This is followed by setting up the GUI, and filling in domain list entries into the“domain” combo box back in class AcMainWindow.

If any problems occur during this process, such as inability to open a connection todatabase, the application will display an error message and end.

The initialization process is displayed in the diagram in Figure 5.3.

Screen capture

When the users opts to capture part of the screen, the control is given to the pro-gram import, which is designed to perform such task. The binary output from thisprogram is then in sequence passed to programs giftopnm and pamtogif from theNetpbm collection. This is done to ensure the validity of the output from import.Resulting image is stored in a directory created during program initialization. Class

36

Figure 5.4: Activity diagram of screen capture in add_comment

AcMainWindow is then given information about the file, which it uses to display thefile in the comment window in the GUI.

The screen capture process is displayed in the diagram in Figure 5.4.

Comment submit

Figure 5.5: Activity diagram of comment submit in add_comment

Before the programs attempts to submit the comment, it performs validation ofthe user input. Author’s name, subject and body of the message cannot be empty,domain name different from the default one must be selected and comment referencetext field must either contain valid comment number, or be empty or contain 0 to

37

mark no comment reference.

After that, the application attempts to submit the comment. To achieve this, anew comment identification number must first be obtained from the database. Thisnumber is reserved for the duration of the database connection by utilizing the table‘seq_comment‘ and MySQL function LAST_INSERT_ID. add_comment then transfers allimage files to a remote host, the network address of which is obtained from tablecfg_directories. The process of transferring a single file consists of reserving apicture identification number using table ‘seq_pict‘ and the same process as whenobtaining comment ID. The image file is then copied to the remote host by callingscp command through the class QProcess1. The application then inserts new row intotable ‘tb_pict‘. After all image files were successfully transferred, the textual dataof the comment are inserted into table ‘tb_comment‘. If any of the actions describedin this paragraph fail, the user is informed and may attempt to submit the commentagain. Otherwise, user is informed about successful submit of the message, and allGUI elements are cleared.

The comment submit process is displayed in the diagram in Figure 5.5.

5.3 run_manager

5.3.1 GUI

User interface of run_manager consists of one window, which is supplemented by popup dialog, which can be used by the user to select new run by its identificationnumber, and pop up messages boxes that are used to inform the user about statusof the application. The interface of the new program is depicted in Figure 5.6.

It is implemented using several widget classes from Qt Widgets module. Most ofits elements were generated by User Interface Compiler from a form file createdin the Qt designer tool in Qt Creator IDE. The remaining elements are createddynamically during program’s initialization. Furthermore, visual properties of someof the elements are modified with the use of CSS language.

GUI elements are represented by the following widget classes: The label displayingrun information, which is located at the top of the window, and “Run type” and“title” labels are implmented by the QLabel class, run type selection combo box byQComboBox class, “Select run”, “Select previous run”, “Select next run”, “Save theseinfos” and “Quit” buttons by QPushButton class, text field “title” by QLineEdit class,editable text area for the comment by QTextEdit class and “Problems” and “Errorson detectors” check boxes by QCheckBox class. Elements are arranged to form thedesired layout by classes QHBoxLayout, QVBoxLayout, QGroupBox and QScrollArea.

Information pop up boxes are implemented with the use of QMessageBox class. Addi-tionally, the class QInputDialog is used to provide run selection input dialog to theuser.

1For requirements placed on the implementation of scp command see section 2.5.4

38

Figure 5.6: new version of run_manager

5.3.2 Structure of the program

Structure of run_manager is very similar to the structure of add_comment. RmCore

is the central class, RmMainWindow represents the user interface, RmMySqlConnectionprovides database connection, RmRunDataSender processes the user input before up-dating database records. RmRunData is a class that is used to store run data retrievedfrom database and pass it to the user interface.

Same as in add_comment, all classes use exceptions to signalize errors or invalid userinput, which are handled either in main() function, or RmMainWindow.

General structure of this application is depicted in class diagram in Figure 5.7.

RmMainWindow

User interface is implemented in class RmMainWindow. It performs many similar taskas class AcMainWindow in add_comment. The GUI in run_manager, however, is morecomplex, as it is required to create some of its elements dynamically based on inputfrom the database, which is obtained during initialization. This task is handled byRmMainWindow.

These dynamic elements are the checkboxes in Problems list and Errors on detectorslist. Internally, they are grouped into logical units by means of QButtonGroup class.This allows for easier control of valid states of these check box groups by utilizingthe Signals & Slots mechanism, and also provides an interface for easier retrieval ofdata from them.

39

Figure 5.7: class diagram of run_manager

This class also holds a Hash table represented by QHash class, which is filled duringinitialization. It is used to translates run type identification numbers into combo boxindexes during run selection process and subsequent presentation of the relevant rundata to the user.

Similarly to AcMainWindow, RmMainWindow stores an instance of RmCore class. It alsoholds an instance of the pre-generated class that contains the GUI elements.

RmCore

RmCore class has the same purpose as class AcCore in add_comment. It thus handlesrequests from RmMainWindow by calling appropriate methods from other back endclasses.

Additionally, it stores a hash table that is used to translate run type names intonumerical values, which are used to store the run type setting in the database. Thistable is implemented by QHash class.

40

RmCore also stores lists of problems and errors on detectors. These are used to pop-ulate the check box groups in the GUI. Both lists are stored in the form of QListclass.

Like AcCore, RmCore is also a subclass of LbCore to utilize some of the protectedmethods implemented there.

RmMySqlConnection

In the same manner as class AcMySqlConnection from add_comment, this class is asubclass of LbMySqlConnection. It is used to perform database queries required byother classes, both to retrieve and save data.

RmRunData

RmRunData represents data about a single run. In the context of this program, it isalways created by RmMySqlConnection class after selecting run data from database,and subsequently passed to RmMainWindow. This class then displays the data to theuser in relevant elements of the GUI of this application.

The data are stored as unsigned integers of various length, and as instances ofclasses QString, QDateTime, which are used to store date and time information, andQBitArray, which are used to store information about reported problems and errorsdisplayed by check box groups in the GUI.

RmRunDataSender

This class is used to update given table row in the database if the user chose tosave the edited information. It performs conversion tasks to transform the data intoformat suitable for database query, and then calls appropriate method from classRmMySqlConnection to execute the database query.

5.3.3 Description of individual tasks

This section describes the three most important tasks performed by run_manager.

Initialization

First step after the start of run_manager is the initialization of an instance of classRmMainWindow. After that, an instance of RmCore is created, which in turn creates aninstance of RmMySqlConnection.

This class is used to retrieve data about available run types, list of possible runproblems, and a list of possible errors on detectors. Using this data, RmMainWindow

41

Figure 5.8: Activity diagram of initialization of run_manager

finishes the setup of the GUI by created the required dynamic elements, and insertingentries into the run type combo box.

If all these task were successful, the program is now ready to be used. Otherwise,the user is informed about the failed setup through a pop up message box and theprogram ends.

The initialization process is displayed in the diagram in Figure 5.8.

Run selection

Figure 5.9

Run selection process can be divided into three cases:

• selection of run based on a run identification number provided by the user

• selection of previous run

• selection of next run

If the user selects a run by its ID, first, a check is made to determine if it differs fromthe current run number. The next task, common to all three cases, is an executionof a database query, which differs in the WHERE condition in each of the mentionedthree cases.

If the database query was successful, it is determined whether database returned anyresults. If not, the run selection process either ends if it was initialized by requestingprevious or next run, or the user is asked to provide a different run number, becauseempty query result indicates invalid run ID. If run data was successfully obtained,it is then displayed on the GUI.

42

Figure 5.9: Activity diagram of run selection in run_manager

The run selection process is displayed in the diagram in Figure 5.9.

Run information update

Figure 5.10

Figure 5.10: Activity diagram of run selection in run_manager

If the user selects to update the data about currently selected run with the changesthey made, the run data is passed to the class RmRunDataSender.

This class first processes the data. Along with several data type conversions, thisincludes the task of creating an integer number that stores the bit mask representingthe options selected in the check box groups containing the list of run problems andthe list of detector errors respectively. It is also necessary to match a run type IDto the value selected in the run type combo box.

After that, a MySQL UPDATE query is executed.

The run data update process is displayed in the diagram in Figure 5.10.

43

5.4 Integration with other applications

The user interface of both programs, which also directly or indirectly holds the mod-ules that contain the application logic, is implemented as a subclass of QMainWindow,and therefore is an indirect descendant of QWidget class. This fact yields an advan-tage, which lies in the fact, that embedding any QWidget or QWidget-derived classinto a GUI of another Qt Widget based application is a simple process.

As a result, both add_comment and run_manager can be potentially integrated intoanother Qt application with only a minimal effort.

44

Conclusion

This Bachelor’s degree project was focused on developing new GUI applications thatwill serve as a user interface for the logbook database of the COMPASS experimentat CERN.

Two applications were created as a result of this project. add_comment is used tocreate rich text comment messages and submit them to logbook servers. run_managerfunctions as an interface that loads run data from logbook database, and allows theuser to edit the retrieved information and store the changes. Both were written inthe C++ programming language and use Qt software framework to implement theGUI and other parts of the programs. As a result, they meet the requirement ofutilizing only technologies that are already being used on COMPASS experiment.

add_comment and run_manager have been developed and successfully tested in a vir-tual environment, and both programs have achieved full functionality defined by therequirements in these conditions.

The next step will be the deployment of the applications to the computer envi-ronment on the COMPASS experiment. This task, however, is not expected to beconducted during the next few months, in order to avoid situation where a newsoftware is being deployed in parallel with active experimental runs.

Possible follow-up work, that would continue the process of logbook interface replace-ment, could consist of developing a new version of shift_manager. The developmentprocess of such program would benefit from the work that was done for this degreeproject, as several modules that are necessary for operation of shift_manager, suchas database connection, are already implemented in classes used by add_comment andrun_manager.

45

Bibliography

[1] CERN. url: http://home.cern/ (visited on July 24, 2016).

[2] COMPASS. url: https://wwwcompass.cern.ch/ (visited on July 24, 2016).

[3] M. Bodlak et al. “Development of new data acquisition system for COMPASSexperiment”. In: Nucl. Part. Phys. Proc. 273-275 (2016), pp. 976–981.

[4] P. Abbon et al. “The COMPASS experiment at CERN”. In: Nucl. Instrum.Meth. A577 (2007), pp. 455–518.

[5] P. Abbon et al. “The COMPASS Setup for Physics with Hadron Beams”. In:Nucl. Instrum. Meth. A779 (2015), pp. 69–115.

[6] TIOBE. url: http://www.tiobe.com (visited on April 30, 2016).

[7] cplusplus.com. url: http://www.cplusplus.com (visited on May 1, 2016).

[8] C++ Standards Committee. url: http://www.open-std.org/jtc1/sc22/wg21 (visited on May 1, 2016).

[9] Bjarne Stroustrup. The C++ Programming Language. 4th edition. Boston, MA,USA: Addison-Wesley Longman Publishing Co., Inc., 2013. isbn: 978-0-321-56384-2.

[10] Miroslav Virius. Programování v C++. Prague, Czech Republic: ČVUT, 2014.isbn: 978-80-01-05470-3.

[11] Qt Wiki. Qt. url: http://wiki.qt.io (visited on May 2, 2016).

[12] Qt Documentation. Qt. url: http://doc.qt.io (visited on July 4, 2016).

[13] Charles Bell. Expert MySQL. 2nd edition. Apress Media LLC, 2013. isbn:978-1-4302-4659-6.

[14] MySQL Documentation. url: https : / / dev . mysql . com / doc (visited onJuly 6, 2016).

[15] Mike Peters. MySQL Storage Engines. Software Projects. January 20, 2008.url: http://www.softwareprojects.com/resources/programming/t-mysql-storage-engines-1470.html (visited on July 12, 2016).

[16] MariaDB. url: https://mariadb.org/ (visited on July 6, 2016).

[17] ImageMagick. url: http : / / www . imagemagick . org / script / index . php(visited on May 11, 2016).

[18] Jan Pechanec. How the SCP protocol works. Oracle. July 9, 2007. url: http://blogs.oracle.com/janp/entry/how_the_scp_protocol_works (visitedon May 11, 2016).

46

http://home.cern/

https://wwwcompass.cern.ch/

http://www.tiobe.com

http://www.cplusplus.com

http://www.open-std.org/jtc1/sc22/wg21

http://www.open-std.org/jtc1/sc22/wg21

http://wiki.qt.io

http://doc.qt.io

https://dev.mysql.com/doc

http://www.softwareprojects.com/resources/programming/t-mysql-storage-engines-1470.html

http://www.softwareprojects.com/resources/programming/t-mysql-storage-engines-1470.html

https://mariadb.org/

http://www.imagemagick.org/script/index.php

http://blogs.oracle.com/janp/entry/how_the_scp_protocol_works

http://blogs.oracle.com/janp/entry/how_the_scp_protocol_works

[19] Linux @ CERN. August 11, 2015. url: http://linux.web.cern.ch/linux/scientific6/ (visited on July 14, 2016).

47

http://linux.web.cern.ch/linux/scientific6/

http://linux.web.cern.ch/linux/scientific6/

Appendix A

Logbook database tables structure

cfg_directories

Structure of this table can be described by the following SQL statements:

CREATE TABLE ‘cfg_directories‘ (

‘name‘ varchar(255) NOT NULL DEFAULT ’’,

‘path‘ varchar(255) NOT NULL DEFAULT ’’,

‘dirid‘ smallint(6) NOT NULL DEFAULT ’0’

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

ALTER TABLE ‘cfg_directories‘

ADD PRIMARY KEY (‘name‘);

Description of the columns:

‘name‘ name of the directory configuration‘path‘ directory path, including the hostname‘dirid‘ directory’s identification number corresponding to the number in col-

umn ‘dirid‘ in table ‘tb_directories‘

seq_comment


CREATE TABLE ‘seq_comment‘ (

‘id‘ int(11) NOT NULL DEFAULT ’0’

) ENGINE=MyISAM DEFAULT CHARSET=latin1


‘id‘ ‘commnb‘ value of the last inserted row in table ‘tb_comment‘ (table hasonly one row at all times)

48

seq_pict


CREATE TABLE ‘seq_pict‘ (

‘id‘ int(11) NOT NULL DEFAULT ’0’

) ENGINE=MyISAM DEFAULT CHARSET=latin1


‘id‘ ‘pictid‘ value of the last inserted row in table ‘tb_pict‘ (table has onlyone row at all times)

tb_commdomains


CREATE TABLE IF NOT EXISTS ‘tb_commdomains‘ (

‘domainid‘ int(11) NOT NULL DEFAULT ’0’,

‘domain‘ varchar(255) NOT NULL DEFAULT ’’


ALTER TABLE ‘tb_commdomains‘

ADD PRIMARY KEY (‘domainid‘),

ADD UNIQUE KEY ‘domain‘ (‘domain‘);


‘domainid‘ domain’s identification number‘domain‘ name of the domain

tb_comment


CREATE TABLE IF NOT EXISTS ‘tb_comment‘ (

‘commnb‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘time‘ datetime NOT NULL DEFAULT ’2001-01-01 00:00:00’,

‘author‘ varchar(200) NOT NULL DEFAULT ’’,

‘domainid‘ int(11) NOT NULL DEFAULT ’0’,

‘shiftid‘ int(11) NOT NULL DEFAULT ’0’,

‘commref‘ int(11) NOT NULL DEFAULT ’0’,

‘title‘ varchar(255) NOT NULL DEFAULT ’’,

‘entry‘ longtext


ALTER TABLE ‘tb_comment‘

ADD PRIMARY KEY (‘commnb‘),

ADD KEY ‘time‘ (‘time‘),

ADD KEY ‘shiftid‘ (‘shiftid‘),

ADD KEY ‘domainid‘ (‘domainid‘),

49

ADD KEY ‘author‘ (‘author‘),

ADD KEY ‘title‘ (‘title‘),

ADD KEY ‘commref‘ (‘commref‘);


‘commnb‘ comment’s identification number‘time‘ comment’s submit time‘author‘ author of the comment‘domainid‘ domain’s identification number corresponding to the number in col-

umn ‘domainid‘ in table ‘tb_commdomains‘

‘shiftid‘ the identification number of the current shift corresponding to thenumber in column ‘shiftid‘ in table ‘tb_shift‘

‘commref‘ the id of the comment that is referenced, corresponding to the num-ber in column ‘commnb‘ in this table

‘title‘ subject of the message‘entry‘ body of the message

tb_directories


CREATE TABLE ‘tb_directories‘ (

‘dirID‘ int(11) unsigned NOT NULL AUTO_INCREMENT,

‘ID‘ smallint(6) NOT NULL DEFAULT ’0’,

‘workstation‘ varchar(50) NOT NULL DEFAULT ’pccoeb03’,

‘Directory‘ varchar(255) NOT NULL DEFAULT ’’,

‘key‘ varchar(20) NOT NULL DEFAULT ’KEY_NEEDED’

) ENGINE=MyISAM;

ALTER TABLE ‘tb_comment‘

ADD PRIMARY KEY (‘dirID‘),

ADD KEY ‘ID‘ (‘ID‘),

ADD KEY ‘key‘ (‘key‘),

ADD KEY ‘Directory‘ (‘Directory‘),

ADD KEY ‘workstation‘ (‘workstation‘);


‘dirID‘ directory’s identification number‘ID‘ ID, which used to denote the purpose of the directory‘workstation‘ network name of the workstation that holds the directory‘Directory‘ absolute path of the directory within the workstation’s file system‘key‘ further details about the directory

tb_errordetcode


50

CREATE TABLE IF NOT EXISTS ‘tb_errordetcode‘ (

‘detcodeid‘ smallint(3) unsigned NOT NULL DEFAULT ’0’,

‘detname‘ varchar(255) NOT NULL DEFAULT ’’,

‘detdesc‘ varchar(255) NOT NULL DEFAULT ’’


ALTER TABLE ‘tb_errordetcode‘

ADD PRIMARY KEY (‘detcodeid‘),

ADD UNIQUE KEY ‘detname‘ (‘detname‘);


‘detcodeid‘ detector error’s identification number‘detname‘ name of the detector error‘detdesc‘ description of the error

tb_pbtype


CREATE TABLE IF NOT EXISTS ‘tb_pbtype‘ (

‘pbtypeid‘ smallint(3) unsigned NOT NULL DEFAULT ’0’,

‘keyword‘ varchar(255) NOT NULL DEFAULT ’’,

‘description‘ varchar(255) NOT NULL DEFAULT ’’


ALTER TABLE ‘tb_pbtype‘

ADD PRIMARY KEY (‘pbtypeid‘),

ADD UNIQUE KEY ‘keyword‘ (‘keyword‘);


‘pbtypeid‘ problem’s identification number‘keyword‘ name of the problem‘description‘ description of the problem

tb_pict


CREATE TABLE IF NOT EXISTS ‘tb_pict‘ (

‘pictid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘time‘ datetime NOT NULL DEFAULT ’2001-01-01 00:00:00’,

‘title‘ varchar(255) NOT NULL DEFAULT ’""’,

‘dirid‘ smallint(6) NOT NULL DEFAULT ’0’,

‘filename‘ varchar(255) NOT NULL DEFAULT ’""’


ALTER TABLE ‘tb_pict‘

ADD PRIMARY KEY (‘pictid‘);


51

‘pictid‘ picture’s identification number‘time‘ time of upload‘title‘ name of the picture‘dirid‘ directory containing the file‘filename‘ name of the stored file

tb_run

Structure of this table can be described by the following SQL statements:CREATE TABLE IF NOT EXISTS ‘tb_run‘ (

‘runnb‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘starttime‘ datetime NOT NULL DEFAULT ’2001-01-01 00:00:00’,

‘stoptime‘ datetime DEFAULT NULL,

‘nbspill‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘nbevt‘ float unsigned NOT NULL DEFAULT ’0’,

‘actROBid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘actEBid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘recordingfg‘ enum(’-1’,’0’,’1’) NOT NULL DEFAULT ’-1’,

‘shiftid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘spsfileid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘bparamid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘bvalueid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘triggerid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘runtypeid‘ smallint(5) unsigned NOT NULL DEFAULT ’0’,

‘targetid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘filterid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

‘pbtypewd‘ bigint(17) unsigned NOT NULL DEFAULT ’0’,

‘errdetwd‘ bigint(17) unsigned NOT NULL DEFAULT ’0’,

‘title‘ varchar(255) NOT NULL DEFAULT ’’,

‘comments‘ longtext,

‘daq_dt‘ decimal(5,4) DEFAULT NULL,

‘veto_dt‘ decimal(5,4) DEFAULT NULL


ALTER TABLE ‘tb_run‘

ADD PRIMARY KEY (‘runnb‘),

ADD UNIQUE KEY ‘startstop‘ (‘starttime‘,‘stoptime‘),

ADD KEY ‘shiftid‘ (‘shiftid‘),

ADD KEY ‘runtypeid‘ (‘runtypeid‘),

ADD KEY ‘actROBid‘ (‘actROBid‘),

ADD KEY ‘triggerid‘ (‘triggerid‘),

ADD KEY ‘targetid‘ (‘targetid‘),

ADD KEY ‘title‘ (‘title‘),

ADD KEY ‘stoptime‘ (‘stoptime‘),

ADD KEY ‘actEBid‘ (‘actEBid‘),

ADD KEY ‘pbtypewd‘ (‘pbtypewd‘),

ADD KEY ‘errdetwd‘ (‘errdetwd‘),

ADD KEY ‘filterid‘ (‘filterid‘);

52


‘runnb‘ run’s identification number‘starttime‘ date and time of the run’s start‘stoptime‘ date and time of the run’s end‘runtypeid‘ identification number of the run’s run type‘pbtypewd‘ bit mask containing the information about run problems‘errdetwd‘ bit mask containing the information about detector problems which

may have occured during the run‘title‘ name of the run‘comments‘ additional information about the run

Remaining columns describe the status of the experiment, as well as the status ofindividual components at the start of the run. They are not used by any of thedeveloped programs.

tb_runtype


CREATE TABLE IF NOT EXISTS ‘tb_runtype‘ (

‘runtypeid‘ smallint(5) unsigned NOT NULL DEFAULT ’0’,

‘keyword‘ varchar(255) NOT NULL DEFAULT ’’,

‘description‘ varchar(255) NOT NULL DEFAULT ’’,

‘ord_show‘ smallint(5) unsigned NOT NULL DEFAULT ’0’,

‘fg_physics‘ enum(’0’,’1’) NOT NULL DEFAULT ’0’


ALTER TABLE ‘tb_runtype‘

ADD PRIMARY KEY (‘runtypeid‘),

ADD UNIQUE KEY ‘keyword‘ (‘keyword‘),

ADD KEY ‘ord_show‘ (‘ord_show‘),

ADD KEY ‘fg_physics‘ (‘fg_physics‘);


‘runtypeid‘ run type’s identification number‘keyword‘ name of the run type‘description‘ description of the run type‘ord_show‘ position in a preferred order of rows‘fg_physics‘ marks, whether the run is intended for acquisition of scientific

data

tb_shift

Structure of this table can be described by the following SQL statements:CREATE TABLE IF NOT EXISTS ‘tb_shift‘ (

‘shiftid‘ int(11) unsigned NOT NULL DEFAULT ’0’,

53

‘starttime‘ datetime NOT NULL DEFAULT ’2001-01-01 00:00:00’,

‘member1‘ varchar(200) NOT NULL DEFAULT ’’,

‘member2‘ varchar(200) DEFAULT ’’,

‘member3‘ varchar(200) DEFAULT ’’,

‘membertgt‘ varchar(200) DEFAULT NULL,

‘summary‘ longtext


ALTER TABLE ‘tb_shift‘

ADD PRIMARY KEY (‘shiftid‘),

ADD UNIQUE KEY ‘starttime‘ (‘starttime‘);


‘shiftid‘ shift’s identification number‘starttime‘ the date and time of the start of the shift‘member1‘ name of the first member of the shift‘member2‘ name of the second member of the shift‘member3‘ name of the third member of the shift‘membertgt‘ name of the member overseeing the target‘summary‘ additional information relevant to the shift

54

Appendix B

Installation instructions

This appendix is meant to serve as a guide for compiling the software from thesource code provided on the enclosed CD and subsequently deploying it. Since theprograms target platform running on the Scientific Linux CERN operating system,this guide presumes that the testing environment is also running on a RHEL basedLinux distribution with a desktop environment, and that the YUM package manageris available.

B.1 Compilation

Both programs were developed using the Qt Creator IDE, and it is recommendedto use the same software to compile it.

Qt Creator can be installed by using the following command:

yum install qt-creator

It is also necessary to install all required Qt modules. Some of them, however, weremost likely installed during the installation of Qt Creator.

yum install qt5-qtbase-devel qt5-qtbase-gui qt5-qtbase-mysql

The easiest way to open the source code of one of the programs in Qt Creator isto open the included project file (extension .pro) of that program. This way, it isonly required to configure compiler and Qt version, which is usually done just byselecting one of the presets stored in the Qt Creator.

Before compilation, it is necessary to change the database connection configuration,because it is hardcoded into the program. This is done by making adequate changesto lines 9–12 in file accore.cpp for add_comment and line 7–10 in file rmcore.cpp forrun_manager.

55

B.2 Database

The enclosed CD contains a database dump file in sql format, which can be used toquickly setup a test database on a MySQL server. The tables in the test databasecontain only a limited amount of data rows, but they have the same structure astheir counterparts in the logbook database on COMPASS experiment.

add_comment reads the path stored in table ‘cfg_directories‘ to determine the imagestorage location. After submitting a comment, images will copied to this folder byusing scp command. It is therefore necessary to modify this table by changing thevalue of column ‘path‘ in the row that holds the value ’pictfiles’ in column ‘name‘.It is possible to test file transfer by copying the files to a directory on localhost.

For testing purposes, it is not required to modify the table ‘tb_directories‘.

It should also be noted, that the path stored in table ‘cfg_directories‘ must exist,because scp command is unable to create it automatically.

B.3 Public key

add_comment does not provide the option to enter authentication details before tryingto copy the image files to the remote host. It is therefore necessary to setup a publickey:

ssh-keygen

ssh-copy-id user@hostname

File transfer can be successfully tested by copying the files to a directory on localhost,in which case the second command is:

ssh-copy-id localhost

B.4 Additional software

add_comment requires several third party programs to function properly.

yum install ImageMagick netpbm openssh

56

Appendix C

Content of the enclosed CD

• The electronic version of this document

• Source code for program add_comment

• Source code for program run_manager

• Test database based on the COMPASS logbook database

57

Documents

Bachelor’s Degree Project · experiments and non-LHC experiments. The Common Muon and Proton Appara-9. tusforStructureandSpectroscopy(COMPASS)experimentisoneofthenon-LHC ... ++11modethroughtheuseof-std=c++11