Rigorous Data Processing and Automatic Documentation of Srf Cold Tests∗
Total Page:16
File Type:pdf, Size:1020Kb
18th International Conference on RF Superconductivity SRF2017, Lanzhou, China JACoW Publishing ISBN: 978-3-95450-191-5 doi:10.18429/JACoW-SRF2017-TUPB069 RIGOROUS DATA PROCESSING AND AUTOMATIC DOCUMENTATION OF SRF COLD TESTS∗ K. G. Hernández-Chahín1y, S. Aull, N. Stapley, P. Fernandez Lopez, N. Schwerg CERN, Geneva, Switzerland 1also at DCI-UG, Guanajuato, Mexico Abstract • Although it is instructive and recommended for any beginner in the field of SRF to implement their own Performance curves for SRF cavities are derived from set of analysis functions, for routine operation a single primary quantities which are processed by software. Com- reviewed and protected set is needed. monly, the mathematical implementation of this analysis is • In general the implementation of mathematical expres- hidden in software such as Excel or LabVIEW, making it sions in any programming language (graphical or text) difficult to verify or to trace, while text-based programming is cumbersome or unpleasant to read. like Python and MATLAB require some programming skills for review and use. As part of an initiative to consolidate In order to overcome these problems the cold-test software and standardise SRF data analysis tools, we present a Python system should meet the following requirements: program converting a module containing the collection of • Single point of function definition • Built-in documentation all commonly used functions into a LATEX(PDF) document carrying all features of the implementation and allowing for • Version control a review by SRF experts, not programmers. The resulting • Nesting and re-use of the core implementation document is the reference for non-experts, beginners and test • Simple and reliable review process stand operators. The module is imported in any subsequent • Automatic tests and sanity checks processing and analysis steps like the symbolic analysis of In this paper we present an approach consisting of two the measurement uncertainties or the study of sensitivities. core components: 1) a central python implementation As an additional layer of protection the functions can be fur- (srf_functions) of all analysis functions as e.g. provided ther wrapped including assertions, type and sanity checks. in Padamsee’s book [8] and 2) an automatic documentation This process maximises function reuse, reduces the risk of tool (dokator) converting the functions and especially the human errors and guarantees automatically validated and underlying code into a type-set representation for review by documented cold test results. SRF experts and practitioners and not programmers. INTRODUCTION SRF_FUNCTIONS 2017). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI. During cold tests of SRF cavities a great number of differ- Figure 1 shows the approach with the central element © ent signals are measured and automatically recorded. The the srf_functions. This module or library contains all acquisition and storage is done by test programs often written mathematical expressions used for the evaluation of the mea- in LabVIEW [1,2] or INSPECTOR [3]. From these primary surements and used in the construction of more complex quantities we derive figures of merit such as the unloaded analysis routines. These functions are used for all compu- quality factor Q0 and the accelerating gradient Eacc. The first tations from the data taken with the measurement software processing and derivation of these quantities is done immedi- (INSPECTOR or LabVIEW) during the cold test to the post ately using the data acquisition software, where the routines processing of the final results. for the calculations are implemented using the programing language provided by the software manufacture. The final Single Point of Function Definition analysis of the data is conducted during the post-processing We base our approach on one single Python [6,7] module, using Excel [4], MATLAB [5] or Python [6, 7] where the srf_functions, which contains the implementation of all analysis routines are custom libraries of the user. computations. We chose Python due to its wide spread Over the last year we came across the following problems use, flexibility and various freely available packages. The and pitfalls of this approach: implementation is kept to a minimum of complexity while • In LabVIEW and Excel the implementation of the anal- placing the effort in clean definitions and documentation. ysis function is somehow hidden from the operator and difficult to verify by the user. Un-typed Function Definition • The functions have to be implemented twice, once for the test software and once for post-processing hence In the core module we define all functions un-typed. This doubling the effort for maintenance. means that the implementation does not rely on any specific features as long as the used objects support standard math ∗ Work supported by the Beam Project (CONACYT, Mexico). operation such as + - * / ** with the latter being the y [email protected] power operator in Python. Special symbols or functions like SRF Technology R&D TUPB069 Content from this work may be used under the terms of the CC BY 3.0 licence ( Cavity 543 18th International Conference on RF Superconductivity SRF2017, Lanzhou, China JACoW Publishing ISBN: 978-3-95450-191-5 doi:10.18429/JACoW-SRF2017-TUPB069 Cross- & Sanity-Checks • Examples illustrating the function use, common results Assertions Version and providing a layer of tests. Control SRF Functions Furthermore variable names may use LATEX notation such as underscores for subscripts. Notice that the approach is similar to common documen- tation tools such as Epydoc [12] and also bases on features Measurement Measurement of reStructuredText [13]. An example of the built-in Data Software documentation is shown in Fig. 2 highlighted in red. Display Version Control The srf_function module and its documentation are included in a version control system such as EDMS [14] or Post Processing GitLab [15] in order to keep track of all changes and mak- ing the current version available to the team. Back-tracing Report problems and evaluating improvements is aided by the open source of the Python module and text-based comparison of different versions of the code. Figure 1: Flowchart of the measurement data from the anal- ysis tools towards the final report with the central definition Automated Testing of all functions in the SRF-function module. Software engineering encourages the use of various test- ing techniques as part of a software quality assurance testing strategy to maintain the required level of reliability, reduce π can be defined in the preamble of the module and may be the risk of failure during operation, and provide confidence overwritten on import. that code changes will not have any adverse affects [16]. This approach allows to use the functions with any kind When testing, different types of defect are found at each of Python objects supporting the aforementioned operators level of abstraction, and the lowest level, code (unit) tests, which is true for numbers as well as symbols as provided by are often implemented to ensure correctness for individual the sympy package [9, 10]. functions as a minimum testing requirement. For the construction of more complicated or coupled ex- For this Python provides docstring which serves as both pressions the functions can be called and re-wrapped into simple examples of the use of the function in the documenta- higher order systems. This, e.g., allows to automatically tion, and for function verification upon module import using derive the expressions for the loaded Q and accelerating doctest [17]. Doctest’s power rests in its simplicity [18, p gradient based only on primary quantities: 157], but for larger more robust test scenarios unittest is 2017). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI. © preferred. 2 2πPt f k 3 Q0 6 Pf −Pr −Pt 7 = 6 q 7 (1) Pt k Sanity Checks Eacc ¹P ;P ;P ; f;k;κ º 6 7 f r t E 6 κE 7 4 5 Extending on the possibility to import and re-use the core Built-In Documentation definitions the functions can be wrapped by a facade layer [19] to include typing and sanity checks. This ranges from A very useful Python feature are docstrings [11]. A doc- enforcing certain data types, including assertions [20] for string is the first statement in a function or class declaration certain inputs such as power reading shall be greater than a providing the user with the documentation. This can be certain minimum or zero, as well as proper error handling used to include all information necessary to understand the to prevent the process from crashing. function call signature, the physics behind the computation as well as give reference to text books such as [8]. LabView Import Maintaining the following conventions the docstring can LabVIEW is often used for cavity testing. Hence it is be made human and computer readable allowing for auto- advantageous to use the same math functions for the post- matic processing and display. The documentation consists processing and for the actual cavity tests. There are several of the following blocks: general solutions for including Python functions in Lab- • Description of the greater context of the function (op- VIEW, each with its own advantages in terms of ease, and tional). performance. We describe three, just to demonstrate the • Definition of the parameters with their symbol, name possibilities and provide an idea of the benefits of each. and unit. One of the simplest solutions is to use LabVIEW ’s built- • Description of the return value(s) with name, symbol in ability (System Exec VI) to execute a Python script and unit. containing the math functions [21]). A new instance of the • Optional notes for function use. Python script is executed every time, meaning this solution • References used in the description and/or notes.