application report - jyväskylän yliopisto · monisiro project application report 0.4.0 public 2...

Monisiro Project

Severi JääskeläinenSamuel Kaiponen

Heta RekiläSinikka Siironen

Application Report

Version 0.4.0Public

June 12, 2018

University of Jyväskylä

Faculty of Information Technology

Approved by Date Signature Print Name

Project manager __.__.2018 Sinikka Siironen

Customer __.__.2018

Instructor __.__.2018 Jukka-Pekka Santanen

Monisiro Project Application Report 0.4.0 Public

Document information

Authors:• Severi Jääskeläinen (SJ) [email protected] 044 3617786

• Samuel Kaiponen (SK) [email protected] 044 2535221

• Heta Rekilä (HR) [email protected] 050 5944831

• Sinikka Siironen (SS) [email protected] 040 7159204

Document name: Monisiro Project, Application ReportPage count: 36File: monisiro-application-report-0.4.0.tex

Abstract: Monisiro Project continued the development of Potku, an applicationused to analyze data received from a recoil spectrometer. The application was ex-tended with MCERD, a Monte Carlo simulation software developed by Kai Arstila.MCERD can be used to simulate the measurements used in recoil spectrometry, tak-ing multiple and plural scattering into account. The document describes the back-ground, user interface and structure of the application. The used programming andtesting practices are presented. The realization of objectives is also discussed, andsome advice for future developers is given.Keywords: Application structure, background, future development, meeting therequirements, objectives, programming practices, Python, Qt, recoil spectrometer,testing, user interface.

i


Change history

Version Date Changes Authors

0.0.1 14.5.2018 The writing of the document was started. SK

0.0.2 18.5.2018 The document template was translated into En-glish.

SK

0.0.3 23.5.2018 First drafts of the Chapters Introduction, Terminol-ogy and Application Structure were written.

SK

0.0.4 24.5.2018 The Chapters User Interface of the Application andProgramming Practices were written.

SS

0.1.0 25.5.2018 Parts of the Chapters Application Structure, Test-ing Practices as well as Results and Realization ofObjectives were written. First draft of the Chap-ter Background and Goals was written.

SK

0.1.1 28.5.2018 Abstract and keywords were written. Part of theChapter Realization of Objectives was written.

SK

0.1.2 30.5.2018 Fixes across the document were made accordingto instructor Santanen’s feedback. The ChaptersApplication Structure, Programming Practices, Test-ing Practices and Results as well as Realization ofObjectives were improved. The summary waswritten.

SK

0.2.0 31.5.2018 The Chapter Guide for Future Developers was writ-ten. Pictures were added to the Chapter User In-terface of the Application.

SK & SS

0.2.1 2.6.2018 Pictures were added and modified in the Chap-ter User Interface of the Application.

SS

ii


Version Date Changes Authors

0.3.0 3.6.2018 Fixes across the document were made accordingto instructor Santanen’s feedback.

SK

0.4.0 12.6.2018 Fixes across the document were made accordingto instructor Santanen’s feedback. Energy spec-trum plotting place was corrected.

HR

iii


Project information

Project group:• Severi Jääskeläinen (SJ) [email protected] 044 3617786

• Samuel Kaiponen (SK) [email protected] 044 2535221

• Heta Rekilä (HR) [email protected] 050 5944831

• Sinikka Siironen (SS) [email protected] 040 7159204

Customers:• Kai Arstila [email protected] 040 8054749• Mikko Laitinen [email protected] 0400 994836• Timo Sajavaara [email protected] 040 8054114

Instructors:• Jonne Itkonen [email protected] 050 4432381• Jukka-Pekka Santanen [email protected] 050 5504666• Tero Tuovinen [email protected] 050 4413685

Contact information:• Email lists: [email protected],

[email protected]

• Email archives: http://korppi.jyu.fi/list-archive/monisiro,http://korppi.jyu.fi/list-archive/

monisiro_opetus

iv

http://korppi.jyu.fi/list-archive/monisiro

http://korppi.jyu.fi/list-archive/

monisiro_opetus


Contents

1 Introduction 1

2 Terminology 2

3 Background and Goals 4

4 User Interface of the Application 54.1 Main Window Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 54.2 Creating a Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64.3 Defining Request Settings . . . . . . . . . . . . . . . . . . . . . . . . . 74.4 Defining Detector Settings . . . . . . . . . . . . . . . . . . . . . . . . . 114.5 Creating a Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.6 Defining Simulation Specific Settings . . . . . . . . . . . . . . . . . . . 134.7 Defining the Target Composition . . . . . . . . . . . . . . . . . . . . . 134.8 Defining the Recoil Atom Distribution . . . . . . . . . . . . . . . . . . 154.9 Running the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 174.10 Generating Energy Spectra . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Application Structure 195.1 Python Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 General Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.3 File and Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.4 Integration of External C Components . . . . . . . . . . . . . . . . . . 21

6 Programming Practices 226.1 Formatting, Naming and Commenting Practices . . . . . . . . . . . . 226.2 Source Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.3 Grouping Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.4 Development Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 Testing Practices and Results 267.1 Unit and Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . 267.2 Regression Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267.3 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.4 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.5 Feedback from the customer and the instructors . . . . . . . . . . . . 28

v


8 Realization of Objectives 298.1 Realization of Requirements . . . . . . . . . . . . . . . . . . . . . . . . 298.2 Unsatisfactory Solutions in the Implementation . . . . . . . . . . . . . 308.3 Challenges During the Implementation . . . . . . . . . . . . . . . . . 31

9 Guide for Future Developers 329.1 Essential Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329.2 Improvements on Existing Features . . . . . . . . . . . . . . . . . . . 32

10 Summary 34

11 References 35

vi


1 Introduction

Monisiro is a software project carried out in the Faculty of Information Technol-ogy at the University of Jyväskylä. The project continued the development of ananalysis application called Potku for the Department of Physics at the Universityof Jyväskylä. Potku was developed in 2013 as a software project of the same name.The application is used in accelerator based materials physics. The results of thesemeasurements can be analyzed using the graphical user interface of the application.

Monisiro project further developed the application by extending it with MCERD, aMonte Carlo simulation software developed by Kai Arstila. Using MCERD one cansimulate the measurements used in accelerator based materials physics. Multipleand plural scattering complicates interpreting the results of measurement analysis.With the help of the simulation, it is possible to take multiple and plural scatteringinto account in the measurement by comparing these two.

Documents were written during the project to describe the developed software andthe project. The purpose of this document is to report the resulting software appli-cation, as well as the realization of plans and requirements set for the application.The complete list of the requirements set for the application can be found in the re-quirements specification [1]. The realization of the goals and practices of the projectare described in the project report [2]. The class documentation can be found in [3].Documents related to testing include the system testing plan [4], the system testingreports [5], the regression testing plan [6] and the regression testing reports [7]. ThePotku Project Application Report [8] was used as a basis for the structure of thisdocument.

In Chapter 2 the essential terminology used in the document is defined. Chapter 3describes the background and goals of the project and the application. The user in-terface of the application is described in Chapter 4. In Chapter 5 the structure of theapplication is described. The used programming practices are presented in Chap-ter 6. In Chapter 7 the used testing practices and results of the testing sessions arereported. Chapter 8 focuses on the realization of objectives set for the application.Chapter 9 contains tips for future developers of the application.

1(36)


2 Terminology

The chapter explains the essential target domain and development tool terminologyused in the document.

The target domain terminology used in the document is as follows:

Element is a species of atoms having the same number of pro-tons in their atomic nuclei.

Energy spectrum describes the measured or simulated energies of theatoms of an element.

get_espe is a program that is used to generate energy spectrumdata from the result file of MCERD.

Detector is a device that can be used to observe particles.

Ion is an electrically charged atom whose total number ofelectrons is not equal to its total number of protons.

Layer is a part of a sample that consists of one or more ele-ments.

Accelerator based materials physics studies materials using ion beams.

MCERD is a program that is used to simulate recoil spectro-meter measurements using the Monte Carlo method.

Multiple and plural scattering is a phenomenon where an ion collides withthe atoms of a sample material multiple times, chang-ing direction and losing energy.

Monte Carlo simulation is a method based on repeated random samplings. Itcan be used to simulate the multiple and plural scat-tering of recoiling atoms.

Sample is a thin film composed of layers. It is often grown onsilicon.

Potku is an analysis application for ion beam measure-ments.

2(36)


Report is a document assembled from the results of analysesand simulations done in Potku.

Recoil atom is an atom that has ejected i.e. recoiled from a sample.

Recoil atom distribution describes the amounts of elements in a sample as afunction of depth.

Recoil spectrometry is a method for examining thin films. An ion beamis directed to a sample where recoiled atoms are ob-served using a detector.

Depth profile describes the amounts of elements in a sample as afunction of depth.

The development tool terminology used in the document is as follows:

C is a programming language that MCERD is written in.

Doxygen is a tool that is used to generate class documentation.

Git is a distributed version control system that is used to managesource code and documents.

GitHub is a web-based hosting service for version control using Git.

Matplotlib is a Python library that is used to plot 2D figures.

NumPy is a Python library for using multi-dimensional arrays and matri-ces.

PyCharm is an IDE for Python.

PyQt is a graphical user interface library for Python that was used toimplement the graphical user interface of Potku.

SciPy is a Python library that is used for scientific computing and techni-cal computing.

3(36)


3 Background and Goals

The Department of Physics at the University of Jyväskylä houses an accelerator lab-oratory, where four accelerators can be used for research. The Accelerator basedmaterials physics research group uses the Pelletron accelerator to reseach the com-position of materials. An ion beam is accelerated in the accelerator and it collideswith the material sample, ejecting particles from it. The ejected particles can bedetected with a recoil spectrometer. The time-of-flight and energy of the particles isanalyzed to find out the composition of the material sample. A visual explanation ofthe measurement process and the equipment can be found in the final presentationof the project [9].

A limiting factor in the accuracy of these measurements is multiple and plural scat-tering. Usually the route of the accelerated ion in the material sample is approxi-mated with straight lines, but in truth the ion collides with the atoms of the materialmultiple times, losing energy and changing direction. This scattering cannot be rep-resented analytically. However, using Monte Carlo based simulation, multiple andplural scattering can be taken into account.

Potku is an application used for the analysis of recoil spectrometry measurements.The Monisiro Project continued its development. Kai Arstila, a representative of thecustomer, has developed a Monte Carlo based simulation program used in simulat-ing recoil spectrometry measurements. The program is called MCERD (Monte CarloElastic Recoil Detection), and the Monisiro Project integrated it into Potku. MCERDis a command line program written in C. A graphical user interface has been devel-oped for MCERD, but it doesn’t meet all the needs of the customer. Integrating theprogram into Potku creates an application that can be used both for the analysis andthe simulation of recoil spectrometry measurements. The results of the analysis andthe simulation can be compared, which helps in planning future measurements andincreases their accuracy and reliability.

4(36)


4 User Interface of the Application

The user interface of Potku has been developed using PyQt GUI libraries and Mat-plotlib plotting libraries. In the project the concept of "project" in the applicationwas renamed to "request". This required changes both in the overall user interfaceand the application structure. In Section 4.1 the main window structure of Potku isintroduced, while the rest of the sections will introduce with more detail the newand changed functionalities added to Potku in this project.

4.1 Main Window Structure

In Potku there were four distinct components in the main window (see Figure 4.1,namely menus and top toolbar, workspace, left sidebar and right sidebar. In theproject the following additions were made to these components:

1. In menus and top toolbar items for creating a new simulation were added.2. Workspace contains a graphic tool for entering simulation parameters and

simulated energy spectra when a simulation is open.3. Left sidebar’s Request Manager (formerly Project Manager) was modified with

adding sample and simulation items to it in addition to the existing measure-ment item.

4. Right sidebar contains a button for simulation specific settings and simulationcontrols when a simulation is open.

Within these components are several tools. The new tools added or tools modifiedin the project are the following:

A. Global Settings were modified by removing settings for default request location,efficiency file location and option for saving energy spectrum output.

B. Request Settings (formerly Project Settings) was modified to contain simulationsettings. Also the grouping of settings was changed.

C. Request Manager (formerly Project Manager) was modified to contain sampleand simulation items in addition to existing measurement items.

D. Simulation Specific Settings contains simulation specific detector and measure-ment settings.

E. Simulation Controls contain controls for running a simulation.

5(36)


Figure 4.1: Main Window of Potku.

4.2 Creating a Request

In the dialog the term "Project" was renamed to "Request". Also the option for usingdefault request location was removed since it was removed also from General Set-tings. The suggested request directory is the Potku default request directory. Thenew dialog is pictured in Figure 4.2.

Figure 4.2: A dialog for creating a new request.

6(36)


4.3 Defining Request Settings

User can define values for settings on request level (formerly Project Settings). Re-quest Settings dialog has four tabs that contain settings related to measurements,simulations, detector and depth profile (see Figures 4.3–4.5 and Section 4.4). Thetext fields used for numerical values were changed to spin box components that ac-cept only numerical values in specified format and range, thus eliminating the needto validate input data.

7(36)


Figure 4.3: A tab for measurement related settings.

8(36)


Figure 4.4: A tab for simulation related settings.

9(36)


Figure 4.5: A tab for depth profile related settings.

10(36)


4.4 Defining Detector Settings

Detector structure is specified in a graphic manner (see Figure 4.6) in its dedicatedtab. The buttons represent detector’s foils. The distances are displayed with labelsand timing foils with check boxes. Efficiency files used in the request and detectorcalibration settings are located in separate tabs (see Figures 4.7 and 4.8).

Figure 4.6: A tab for detector related settings and structure.

11(36)


Figure 4.7: A tab for efficiency files.

Figure 4.8: A tab for calibration settings.

4.5 Creating a Simulation

When a user has created or opened a request, they can create a new simulation fromthe info window located in the workspace view (see Section 4.1), from the menu orfrom the top toolbar. The dialog in Figure 4.9 asks for a name for the simulation.User also has to choose a sample to which the simulation is related to or create anew sample (see Figure 4.10).

12(36)


Figure 4.9: A dialog for creating a new simulation.

Figure 4.10: A dialog for creating a new sample.

4.6 Defining Simulation Specific Settings

From the right sidebar user can choose to change settings specific to the openedsimulation. These setting dialogs are identical to Request Settings (see Section 4.3).

4.7 Defining the Target Composition

When a simulation is opened, a view for defining the target composition is dis-played in the workspace (see Figure 4.11). A user can specify the composition of thetarget graphically. The user can add layers to the target and they are then drawnin the graph. Different layers are separated with a border and they are drawn indifferent shades of gray. The user can save the composition with Save all button andexport all elements in layers to Recoil Atom Distribution view with Export elementsbutton.

13(36)


The following tools are found in the Target Composition view:

A. Home returns the view to the original zoom level and position.B. Back and Forward move the zoom level and position of the view to the previous

or next one used, respectively.C. Pan/Zoom has two modes: pan and zoom. When this tool is activated, the view

can be panned vith the left mouse button and zoomed with the right mousebutton.

D. Zoom to rectangle zooms the view to a rectangle defined by dragging with amouse button. Left mouse button zooms in, right mouse button zooms out.

E. Subplot configuration can be used to define the margins of the graph.F. Add layer opens a dialog for specifying a new layer.

Figure 4.11: A view for defining the target composition.

14(36)


4.8 Defining the Recoil Atom Distribution

A user can modify the recoil atom distribution for each element in the target compo-sition. The elements are shown in the list on the right of the view (see Figure 4.12).The graph shows the element’s distribution that the user can modify by adding andremoving points and dragging them in the graph. The user can save the distribu-tions with the Save All button.

The following tools are found in the Recoil Atom Distribution view:

G. The name and reference density of the selected element are displayed here.The button opens a dialog for editing them and the description of the element.

H. Unlock full edit enters full edit mode. The mode has to be entered in order tochange all the simulation parameters after running a simulation. When themode is entered, all the previous results of the simulation are deleted, becausethey no longer correspond to the settings.

I. Plot spectrum opens a dialog where calculated spectrum data files can be cho-sen for plotting.

J. These buttons are the same as in Target Composition view (See Section 4.7).K. X and Y coordinates of the currently selected point are displayed and can be

edited.L. Remove point removes the currently selected point(s).

M. Add element opens a dialog for adding a new element.N. Remove element removes the selected element.O. Element simulation settings opens the simulation settings of the selected ele-

ment.

15(36)


Figure 4.12: A view for defining the recoil atom distribution.

16(36)


4.9 Running the Simulation

For each element in the recoil atom distribution there is a simulation controls viewin the right sidebar (see Figure 4.13). The simulation controls include buttons forstarting and stopping the simulation and a spin box component to choose the num-ber of processes used in the simulation. The state of the simulation is also displayedas a text label.

Figure 4.13: A view for simulation controls.

17(36)


4.10 Generating Energy Spectra

With the Plot Spectra button in Recoil Atom Distribution view (see Section 4.8) the usercan open a dialog for choosing calculated energy spectrum data files to be plottedin Energy Spectrum view (see Figure 4.14).

Figure 4.14: View for displaying energy spectra.

18(36)


5 Application Structure

Potku is a workstation application. The application uses Python standard libraries,the GUI libraries of PyQt, the plotting libraries of Matplotlib, and the mathematicallibraries of NumPy and SciPy. The chapter describes the different components in thePotku application that were added in the project and their relations to each other.

In this project the external C components MCERD and get_espe were integrated intoPotku. The description of the components that weren’t used in the parts developedin the project can be found in the Potku Project Application Report [8].

5.1 Python Libraries

Potku uses the following Python libraries:

Matplotlib is a library for plotting different histograms. In the project, the li-brary was used in the tools for defining the layers of the target anddetector, the tool for defining the recoil atom distribution and forthe plotting of energy spectra.

Numpy and Scipy mathematical libraries are used for some mathematicaloperations in Potku, but not in the parts developed in the project.

PyQT is a Python binding for the GUI library Qt. The entire Potku GUIincluding the parts developed in the project was developed withPyQt, except for histograms, which were plotted with Matplotliband placed inside Qt widgets.

Python standard libraries are the standard libraries that come with a Pythoninstallation. The libraries that were introduced to Potku in theproject include json, time and tempfile. json is used to man-age setting files. The current time is fetched with time and used asthe modification time of settings. tempfile is used to determinethe directory that the system uses for temporary files. The MCERDinput files are generated in this directory.

19(36)


5.2 General Structure

The structure of the application after the project is roughly presented in Figure 5.1.The structure is documented with more detail in the Potku class documentation [3].

GUI Python Interpreter

Interfaces

Selection

Global settings

Project

Project settings

Settings

Recoil atom distribution

Target layer description

Simulation utilities

Result fileInput files

Sample

Measurement

Settings

Element losses

Energy spectrum

Depth profile

ToF calibration

Measurement utilities

Cut file

Energy spectrum

MC Simulation

tof_list carbon_stopping

mcerd

erd_depth

get_espe

External programs

Figure 5.1: The structure of Potku.

20(36)


5.3 File and Data Formats

Before the project Potku used to store its settings in ini files. In the project the filestructure was changed so that each group of related settings is saved in its ownJSON file. The files have the following extensions:

measurement stores settings related to the measurement.

detector stores settings related to the detector.

mcsimu stores settings related to the simulation.

target stores settings related to the target.

rec stores settings related to the recoil atom distribution.

profile stores settings related to the depth profiles, energy spectra andcomposition changes.

The content of the files is described in more detail in [10].

5.4 Integration of External C Components

The following external C programs provided by the customer were integrated intoPotku in the project:

MCERD is a program that is used to simulate recoil spectrometer measure-ments using the Monte Carlo method.

get_espe is a program that generates energy spectrum data from a result file ofMCERD. The data is then plotted in Potku.

MCERD uses strict formats for its input files. When a simulation is started, Potkuretrieves the necessary information from its setting files and generates the tempo-rary MCERD input files. MCERD is then called from Potku, pointing to the inputfiles. MCERD writes its results to output files, the most important of which is the filewith the extension erd. It includes information about the ions that hit the detector.

get_espe receives its parameters as command line arguments. These arguments areretrieved from Potku setting files. The arguments also include the path to the erdresult file and the recoil input file of MCERD. The output file of get_espe includesthe data that is used to plot the energy spectrum in Potku.

21(36)


6 Programming Practices

Programming began with upgrading Python and libraries to the newest versionsoon after the project team had been introduced to the Potku software. In the processthe project group became familiar with the existing code which helped in movingtowards implementing new functionality.

The source code was reviewed twice by the project’s technical advisor Jonne Itko-nen, who shared his notices and advice about the source code. Most of his ad-vice was taken into account, including using methods and functions more often andmaking use of objects. The existing source code was modified quite heavily in orderto make it more object-oriented and to help further develop the application.

In addition to the knowledge of the technical advisor Itkonen, Internet resourceswere used in solving programming problems, including the official Python 3.6 doc-umentation [11].

6.1 Formatting, Naming and Commenting Practices

In writing the code, the conventions of Python language defined in Style Guide forPython Code [12] were used. The names of the variables were written entirely low-ercase with underscores symbolising spaces. The names of the methods followedthe same naming convention. An exception to these conventions were the vari-ables automatically generated by PyQt, since PyQt follows the CamelCase style. Allclasses were named with CamelCase as well. The names of the variables and objectswere kept as self-explanatory as possible. The project group changed the namingof the files from CamelCase to lowercase with underscores to conform to the styleguide.

Each Python module contains specific commentary on each function or method,and possibly line or block to help understand the purpose of the code. The functionor method specific commentaries include the purpose of the function or method,explanation of the arguments it takes, and explanation of what it returns. The linewidth of Python files was kept at 80 characters.

All the variable names, function names, class names and comments were writtenin English. Every Python file starts with license and copyright information. The

22(36)


project group added their names to the copyright amongst the previous develop-ers. The creation and modification dates were not touched since the informationcan be found through version control. In every modified file the authors field wasappended with the names of the group members.

6.2 Source Code Example

The following source code example is taken from file get_espe.py. It demon-strates the naming, commenting and formatting practices followed.

"""Created on 27.4.2018Updated on 2.5.2018"""

__author__ = "Severi Jääskeläinen \n Samuel Kaiponen \n" \"Heta Rekilä \n Sinikka Siironen"__version__ = "2.0"

import osimport platformimport subprocess

from modules.element import Element

class GetEspe:"""Class for handling calling the external program get_espe to generateenergy spectra coordinates."""__slots__ = "__recoil_file", "__settings", "__beam", "__detector", \

"__target", "__channel_width", "__reference_density", \"__fluence", "__params", "output_file", "__timeres", \"__density", "__solid", "__erd_file", "__output_file"

def __init__(self, settings):"""Initializes the GetEspe class.Args:

settings: All settings that get_espe needs in one dictionary."""

23(36)


self.__beam = settings["beam"]self.__detector = settings["detector"]self.__target = settings["target"]self.__channel_width = settings["ch"]self.__fluence = settings["fluence"] # from Run objectself.__timeres = settings["timeres"]self.__density = settings["reference_density"] * 1e16self.__solid = settings["solid"]self.__recoil_file = settings["recoil_file"]self.__erd_file = settings["erd_file"]self.__output_file = settings["spectrum_file"]

toflen = self.__detector.foils[self.__detector.tof_foils[1]].distancetoflen -= self.__detector.foils[self.__detector.tof_foils[0]].distancetoflen_in_meters = toflen / 1000

self.__params = "-beam " + str(self.__beam.ion.isotope) + \self.__beam.ion.symbol \+ " -energy " + str(self.__beam.energy) \+ " -theta " + str(self.__detector.detector_theta) \+ " -tangle " + str(self.__target.target_theta) \+ " -timeres " + str(self.__timeres) \+ " -toflen " + str(toflen_in_meters) \+ " -solid " + str(self.__solid) \+ " -dose " + str(self.__fluence) \+ " -avemass" \+ " -density " + str(self.__density) \+ " -dist " + self.__recoil_file \+ " -ch " + str(self.__channel_width) \

self.run_get_espe()

def run_get_espe(self):command = ("type " if platform.system() == "Windows" else "cat ") \

+ self.__erd_file + "| " \+ os.path.join("external", "Potku-bin", "get_espe"

+ (".exe " if platform.system() == "Windows"else "_linux "if platform.system() == "Linux"else "_mac ")) \

+ self.__params + " > " + self.__output_file

subprocess.call(command, shell=True)

24(36)


6.3 Grouping Practices

Grouping conventions of Python modules wasn’t changed much from the existingconventions. The project added separate folders for simulation and measurementrelated modules inside the dialog directory. Inside the widgets directory widgetswere divided into simulation related, measurement related and matplotlib widgetdirectories.

6.4 Development Platform

For programming the Python source code, the project team used PyCharm IDE.Compiling of external C source codes was done with GCC. Source code is encodedin UTF-8.

For development, the project group had two Windows workstations and two Linuxworkstations. A laptop with macOS was used to perform system testing. Versioncontrol was handled with Git version control system and was stored in GitHub host-ing service. Doxygen tool was used to generate class documentation from the sourcecode.

25(36)


7 Testing Practices and Results

The chapter describes the realization of testing practices planned in the project planand the results of testing. The tests revealed flaws in naming and removing objects.Some application crashes as well as problems with external C components werealso discovered. The customer and the instructors gave feedback on the application,concentrating on its usability and functionalities. The project should have includedmore testing, but there wasn’t enough time and implementation was prioritizedover testing.

7.1 Unit and Integration Testing

Unit testing was planned to be conducted for the parts of the application that per-form calculations. However, no unit tests were written. Most parts of the applica-tion that were developed in the project didn’t perform any calculations. The calcu-lations were mostly done by external C programs. Instead of automatic unit tests,the project team members tested new code manually and informally by trying it inpractice.

After a team member programmed a new module, he/she conducted informal in-tegration testing by verifying in practice that the application works with the newmodule. When the team member found that the module introduced no new errors,they pushed the changes into the remote Potku repository.

7.2 Regression Testing

Two regression testing sessions for each operating system (Windows, Linux andmacOS) [7] were conducted during the project. The regression testing targeted thefeatures of Potku that existed before the project.

The first test sessions revealed problems with creating energy spectra and the de-fault save location of requests.

The second test sessions indicated that the application doesn’t yet check for du-plicate names or names with illegal characters when naming measurements. It alsodoesn’t ask the user for confirmation when they want to remove a measurement. On

26(36)


Linux, the application crashed when importing an evnt file. Some graphs weren’tcalculated correctly because of faulty input data for external C components.

7.3 System Testing

Two system testing sessions for each operating system (Windows, Linux andmacOS) were conducted during the project. The system testing targeted the featuresof Potku that were added or significantly changed during the project.

The first test sessions showed that MCERD stops printing its simulation progress at99%. This doesn’t necessarily mean that it didn’t finish the simulation. A crash alsohappened on Linux when changing the name and reference density of a element.

The second test sessions revealed that the same naming and removing problems asin the regression tests apply for requests, samples and simulations as well. Defaultdetector settings were also used when running a simulation with simulation specificsettings.

The system tests weren’t very comprehensive. More test cases are required to ensurethat the application works as intended.

7.4 Usability Testing

Originally it was intended that there would be a usability test plan, based on whichtest sessions would be conducted. The realized usability testing was less formal.

Once the application started to have new features, it was demonstrated in projectmeetings which were held every week or two weeks. The representatives of thecustomer and the instructors gave their feedback on the new implementations andmodifications. This feedback included comments on usability, which the projectteam took into account.

Because the application was stored in a public GitHub repository, the instructorsand representatives of the customer could download and test it on their own. Easy-to-use executable binaries of the application were also made by the project teamin the latter part of the project. These tests were one valuable source of usabilityfeedback.

27(36)


The project also included a usability day, where usability expert Johanna Silven-noinen commented on the usability of the application.

7.5 Feedback from the customer and the instructors

The most important feedback on the application were the following:

• The style of the icons created by the project team should be consistent with theones provided by Matplotlib.

• The Recoil Atom Distribution view should be scaled to the width of the targetautomatically.

• The layout of the graphs should be tighter, i.e. have smaller margins.• Some setting dialogs force the user to do too much scrolling.• When a window in the workspace is maximized, the minimize and close but-

tons move to the upper right corner of the Potku window. The buttons arethen quite difficult to find.

• An element should be selected by default when the Recoil Atom Distributionview is opened.

• The recoil atom distribution should be initialized with values calculated fromtarget composition.

• Each element in the recoil atom distribution has an entry both in the RecoilAtom Distribution view and the simulation controls view. Combining theseviews should be considered.

More feedback can be found in the memo of the usability day [13] and in the Moni-siro email archive http://korppi.jyu.fi/list-archive/monisiro).

28(36)

http://korppi.jyu.fi/list-archive/monisiro


8 Realization of Objectives

The chapter describes how the requirements set for the application were met. Imple-mentation solutions that the project team considered unsatisfactory and challengesthat arose during the implementation are also discussed.

8.1 Realization of Requirements

187 requirements were specified in the Monisiro Requirements Specification [1].Each requirement was assigned a priority based on its importance to the customer.The possible priorities were mandatory (marked as 1), important (2), possible (3), idea(4) and will not be implemented (5).

Of the total 189 requirements, 75 were implemented. Of the 82 requirements withpriority 1, 63 were implemented. Of the 60 requirements with priority 2, 12 wereimplemented. None of the 39 requirements with priority 3, 5 requirements withpriority 4, or 3 requirements with priority 5 were implemented.

The requirements were grouped based on the functionality they were related to. Inthe rest of the section the realization of these functionalities is described.

The user can enter default values for parameters. Each measurement or simulationcan use these default values or specific values, which can also be entered by theuser. The parameters are saved to files, but the user cannot save them to any file oftheir choosing or load them from a file. When an existing simulation or measure-ment is opened, its parameters are read from file, but any generated spectra are notremembered.

The user can add layers to the target and the detector foils, but the layers cannot beedited, moved or removed.

The user can add, move and remove points in the recoil atom distribution. Numer-ical values for the coordinates of a point can also be entered. Changes in the graphcannot be undone or redone.

The user can start and stop a simulation. The state of the simulation is shown, butit is based on pressing the start and stop buttons and doesn’t check the state ofMCERD.

29(36)


The application calculates the energy spectrum when a simulation has beenstopped. The user can do the calculation again for selected recoil element and selectother calculated energy spectra to be plotted with it. The user cannot change the binwidth of the plot.

The folder and file structure of Potku was revamped. Now request folders includesample folders, which include measurement and simulation folders. Samples, mea-surements and simulations have a running number inside each request. The RequestManager can be used to rename and remove measurements and simulations.

Command line usage was intended to be implemented already in the Potku project,but the Monisiro project didn’t have time for it either. A report tool was also plannedfor the project but wasn’t implemented.

Easy to use installation files for each operating system were created. Because of this,installation instructions were deemed unnecessary.

8.2 Unsatisfactory Solutions in the Implementation

Some solutions in the application are unsatisfactory, mostly due to time constraints.Fixing them should be considered in future development.

The user interface of the application has some flaws. The user isn’t generally askedfor confirmation when they remove something, e.g. a simulation. This is bad prac-tice if the removal cannot be easily undone. Some of the setting dialogs require toomuch scrolling to view all their information. In Recoil Atom Distribution view, theonly way to add points is to Ctrl-click on a line between points. There should alsobe a button in the toolbar for this purpose.

The application crashes quite often. This can be attributed to inadequate errorchecking. There are many places in the source code where exceptions should becaught and handled, but they aren’t. Most values entered in setting dialogs aren’tchecked for correctness.

Calling the external C programs is implemented to the best of the project team’sability, but it may not be an ideal solution. Some problems with permissions orsystem policies may arise. Ideally the functionalities of the C programs would beavailable in a library that could be directly used in Python source code.

30(36)


The classes Beam and Layer have no methods. They just store some attributes.Refactoring their functionality should be considered.

There is a usability problem with the representation of the detector structure as theview has to be scrolled horizontally. The detector usually has up to four foils anduser can’t view them all at once. However, the dialog is resizable to allow the userto view more content simultaneously. Also the choice of separating efficiency filelist and fields to input calibration settings into tabs is hiding information from user.These groups of settings could have been displayed in the main tab.

8.3 Challenges During the Implementation

The biggest challenges during the development were related to MCERD andget_espe and their integration into Potku. The project team didn’t have much expe-rience with C, and it took some time to compile the program for Windows. MCERDuses large static memory allocations, which caused some problems with stack size.Some file paths are hardcoded in MCERD and get_espe, and they had to be changedwhen integrating the programs into Potku.

Another challenge was the structure revamp of the existing settings, files and fold-ers of Potku. The settings were grouped differently and the format of the settingfiles was changed. The folder structure was also nearly completely revised. Thesechanges required a lot of modifications to the existing source code. Because theproject team had only superficial knowledge of the existing functionalities of Potku,understanding the source code and making the modifications took considerabletime.

31(36)


9 Guide for Future Developers

Potku will enter further development immediately after the project. The chapterdescribes the major bugs that still exist in the application, and gives tips on whichexisting features could be improved. A complete list of functionalities, both imple-mented and non-implemented, can be found in the Requirements Specification [1].

9.1 Essential Bugs

The structure revamp of Potku was such a big undertaking that it was barely fin-ished in the project. It is not certain that all the settings work as they should on themeasurement side of Potku. Some of the existing C programs didn’t work with theinput data from a measurement after the revamp.

The bugs described in the Potku Project Application Report [8] haven’t been fixed.

The customer provided a list of existing bugs in Potku, which can be found in Ap-pendix A of the Requirements Specification [1].

9.2 Improvements on Existing Features

The application should give more support for the user in their workflow, i.e. suggestwhat to do next. The user interface developed in the project is not very intuitive.For example, the purpose of the Save all button is unclear. Some guidance shouldbe given for the user about it or the whole functionality should be rethought andredone. The same applies for the Full edit button and the adding of new pointsin the Recoil Atom Distribution view. Various other small improvements could bemade across the user interface, e.g. having a different icon for measurements andsimulations in the Request Manager.

Currently he dialog for displaying energy spectra has an option for bin width, but itisn’t used because the spectra have already been generated. The spectra should begenerated only after the bin width can be changed for plotting.

Not every setting is checked for validity. For most numerical values, a PyQt com-ponent called spinbox is used. It only allows numbers as input. However, this

32(36)


restriction is not always enough. Some values that could be input wouldn’t makeany physical sense.

The corresponding section in the Potku Project Application Report [8] has improve-ment suggestions that are still valid except for the compiled versions of the externalC programs, which are now included.

33(36)


10 Summary

Monisiro Project continued the development of Potku, an application used to ana-lyze data received from a recoil spectrometer. The application was extended withMCERD, a Monte Carlo simulation software. The most important requirementsrelated to running simulations and generating energy spectra were implemented.Many planned functionalities were agreed with the customer to be developed afterthe project. In its current state the application has issues with usability. Validitychecks are also missing across the application.

The project added both traditional setting dialogs and interactive graphical tools toPotku for entering simulation parameters. These parameters are given to MCERD,which runs the simulation. An energy spectrum is then generated from results ofthe simulation and plotted in Potku.

The libraries used for development in the project include the PyQt GUI library, theMatplotlib plotting library and various Python standard libraries. Most calculationsare done in external C components provided by the customer.

Superficial regression, usability and system testing was conducted during theproject. The source code was reviewed twice by the technical instructor of theproject. The application enters further development immediately after the project.

34(36)


11 References

[1] Severi Jääskeläinen, Samuel Kaiponen, Heta Rekilä and Sinikka Siironen, ”Mo-nisiro Project, Requirements Specification”, University of Jyväskylä, Faculty ofInformation Technology, 2018.

[2] Severi Jääskeläinen, Samuel Kaiponen, Heta Rekilä and Sinikka Siironen,”Monisiro-projekti, Projektiraportti”, University of Jyväskylä, Faculty of Infor-mation Technology, 2018.

[3] Severi Jääskeläinen, Samuel Kaiponen, Heta Rekilä and Sinikka Siironen, ”Mo-nisiro Project, Class Documentation”, University of Jyväskylä, Faculty of Infor-mation Technology, 2018.

[4] Severi Jääskeläinen, Samuel Kaiponen, Heta Rekilä and Sinikka Siironen, ”Mo-nisiro Project, System Testing Plan”, University of Jyväskylä, Faculty of Infor-mation Technology, 2018.

[5] Severi Jääskeläinen, Samuel Kaiponen, Heta Rekilä and Sinikka Siironen, ”Mo-nisiro Project, System Testing Reports 1–6”, University of Jyväskylä, Faculty ofInformation Technology, 2018.

[6] Severi Jääskeläinen, Samuel Kaiponen, Heta Rekilä and Sinikka Siironen, ”Mo-nisiro Project, Regression Testing Plan”, University of Jyväskylä, Faculty of In-formation Technology, 2018.

[7] Severi Jääskeläinen, Samuel Kaiponen, Heta Rekilä and Sinikka Siironen, ”Mo-nisiro Project, Regression Testing Reports 1–6”, University of Jyväskylä, Facultyof Information Technology, 2018.

[8] Jarkko Aalto, Timo Konu, Samuli Kärkkäinen, Samuli Rahkonen and Miika Rau-nio, ”Potku project, Application Report.” University of Jyväskylä, Departmentof Mathematical Information Technology, 29.5.2013.

[9] Severi Jääskeläinen, Samuel Kaiponen, Heta Rekilä and Sinikka Siironen,”Monisiro-projekti, Loppuesittely”, University of Jyväskylä, Faculty of Informa-tion Technology, 2018.

[10] Kai Arstila, ”Parametrit-KA-2018-05-08.xlsx”, University of Jyväskylä, Depart-ment of Physics, 2018.

35(36)


[11] Python Software Foundation, ”Python 3.3.1 Documentation”. http://docs.python.org/3/. Cited 28.5.2018.

[12] Guido Van Rossum, Barry Warsaw ja Nick Coghlan, ”PEP 8 – StyleGuide for Python Code.” Python.org. https://www.python.org/dev/

peps/pep-0008/. Cited 28.5.2018.

[13] Severi Jääskeläinen, Samuel Kaiponen, Heta Rekilä and Sinikka Siironen,”Monisiro-projekti, Käytettävyyspäivän muistio”, University of Jyväskylä, Fac-ulty of Information Technology, 2018.

36(36)

http://docs.python.org/3/

http://docs.python.org/3/

https://www.python.org/dev/peps/pep-0008/

https://www.python.org/dev/peps/pep-0008/