Master's Thesis in Engineering Physics

Data acquisition system for optical frequency comb

spectroscopy

Author

Ragnar Seton

Supervisor

Amir Khodabakhsh

Examiners

Aleksandra Foltynowicz-Matyba

Ove Axner

2017-09-05

"The di�erence between theory and practice is that in theory, there is nodi�erence between theory and practice."

-Richard Moore

Abbreviations and acronyms

API Application Programming InterfaceASCII American Standard Code for Information Interchange

(text format)BS Beam SplitterCoW Copy on WriteCUDA Compute Uni�ed Device Architecture (NVIDIAs parallel

programming framework)DAC Data Acquisition CardDAQS Data Acquisition SystemFFT Fast Fourier TransformFIFO First In, First OutFLOPS Floating-Point Operations Per SecondFTS Fourier Transform SpectrometerFWHM Full Width Half MaximumGUI Graphical User InterfaceGUIDE Graphical User Interface Development Environment (part

of MATLAB)HAWKS HITRAN Atmospheric WorkstationHITRAN High Resolution Transmission databaseHLA High Level AssemblyHTML Hyper Text Markup LanguageHWHM Half-Width Half-MaximumI/O Input/OutputIPC Inter Process CommunicationIVI Interchangeable Virtual InstrumentJIT Just-In-Time (compilation)JVM Java Virtual MachineJDBC Java Database ConnectivityMI Michelson InterferometerNI National Instruments corporationNICE Noise Immune Cavity EnhancedNIR Near Infrared (commonly used for wavelength spectra)ODBC Open Database ConnectivityOFCS Optical Frequency Comb SpectroscopyOOP Object Oriented ProgrammingOPD Optical Path Di�erencePCI Peripheral Component InterconnectPHP PHP: Hypertext Preprocessor (recursive backronym)RF Radio FrequencySLOC Source Lines Of CodeUX User Experience

i

Abstract

The Optical Frequency Comb Spectroscopy (OFCS) Group at the Department of Physicsat Umeå University develops new techniques for extremely high sensitivity trace gasdetection, non invasive temperature measurements, and other applications of OFCS.Their setup used primarily for trace gas detection contains several components that havebeen developed in-house, including a Fourier Transform Spectrometer (FTS) and anauto-balancing detector. This is the one used in this thesis work and it includes a highfrequency data acquisition card (DAC) recording interferograms in excess of 107 double-precision �oating point samples per sweep of the FTS's retarder. For acquisition andanalysis to be possible in both directions of the retarder the interferograms needs to beanalysed in a sub-second timeframe, something not possible with the present software.The aim of this thesis work has thus been to develop a system with optimized analysisimplementations in MATLAB. The latter was a prerequisite from the group to ensuremaintainability, as all members are well acquainted with it.

Ful�lling its primary purpose MATLAB performs vector and matrix computationsquite e�ciently, has mostly fully mutable datatypes, and with recent just-in-time (JIT)compilation optimizations vector resizing performance has improved to what in manyinstances is perceived as equivalent to preallocated variables. This memory managementabstraction, however, also means that explicit control of when arguments are passed byvalue or by reference to a function is not o�cially supported. The following performancerami�cations naturally increase with the size of the data sets (N) passed as argumentsand become quite noticeable even at moderate values of N when dealing with datavisualization, a key function in system. To circumvent these problems explicit datareferences were implemented using some of the undocumented functions of MATLAB'slibmx library together with a custom data visualization function.

The main parts of the near real time interferogram analysis are resampling and aFourier transformation, both of which had functionally complete but not optimized im-plementations. The minimal requirement for the reimplementation of these were simplyto improve e�ciency while maintaining output precision.On experimentally obtained data the new system's (DAQS) resampling implementationincreased sample throughput by a factor of 19 which in the setup used corresponds to108 samples per second. Memory usage was decreased by 72% or in terms of the theo-retical minimum from a factor 7.1 to 2.0. Due to structural changes in the sequence ofexecution DAQS has no corresponding implementation of the reference FFT function asthe computations performed in it have been parallelized and/or are only executed on de-mand, their combined CPU-time can however in a worst-case scenario reach 75% of thatof the reference. The data visualization performance increase (compared to MATLAB'sown, as the old system used LabVIEW) depends on the size in pixels of the surface it isvisualized on and N , decreasing with the former and increasing with the latter. In thebaseline case of a default surface size of 434x342 pixels and N corresponding to one fullsweep of the FTS's retarder DAQS o�ers a 100x speed-up to the Windows 7 version ofMATLAB R2014b's plot.

ii

In addition to acquiring and analyzing interferograms the primary objectives of thework included tools to con�gure the DAC and controlling the FTS's retarder motor, bothimplemented in DAQS.

Secondary to the above was the implementation of acquisition and analysis for bothdirections of the retarder, a HITRAN reference spectra generator, and functionality toimprove the user experience (UX). The �rst, though computation time allows for it,has not been implemented due to a delay in the DAC-driver. To provide a genericimplementation of the second, the HITRAN database was converted from the text-basedformat it is distributed in to a MySQL database, a wrapper class providing frequency-span selection and the absorption spectra generation was developed together with agraphical front-end. Finally the improved UX functionality mainly focused on providingeasy-access documentation of the properties of the DAC.

In summation, though the primary objectives of optimizing the data analysis func-tions were reached, the end product still requires a new driver for the DAC to provide thefull functionality of the reference implementation as the existing one is simply too slow.Many of DAQS' components can however be used as stand-alone classes and functionsuntil a new driver is available. It is also worth mentioning that National Instruments(NI), the DAC vendor, has according to their technical support no plans to develop nativeMATLAB drivers as MathWorks will not sell them licenses.

iii

Sammanfattning

Optical Frequency Comb Spectroscopy (OFCS) Gruppen vid Umeå Universitet utvecklarOFC-baserade tekniker för extremkänslig gasdetektering, beröringsfri temperaturmät-ning, och andra problemspeci�ka applikationer. Flera av de centrala komponenterna igruppens uppställning för gasdetektion är designade och byggda på plats, bland dessaingår Fourierspektrometern (FTS) och en auto-balanserande detektor. Det är den, sommed sitt högfrekvent datainsamlingskort (DAC) från National Instruments (NI) produc-erar interferogram i storleksordningen 107 �yttal med dubbel precision per svep medFTSns retrore�ektor, har använts i examensarbetet. Interferogrammen behöver anal-yseras i semirealtid (<1 sekund) för att göra kontinuerlig insamling och veri�ering avsignalen möjlig. Målet med examensarbetet har således varit att i MATLAB utvecklaen optimerad applikation för just datainsamling och analys (DAQS). Valet av program-språk var givet av gruppen för att säkerställa långsiktigt underhåll av mjukvaran, då allagruppens medlemmar är väl bekanta med det. Beräkningsmässigt är MATLAB indus-triledande med mycket e�ektiva vektor- och matrisoperationer, muterbara datatyper, ochi senare versioner har just-in-time (JIT) kompileringen e�ektiviserat iterationsbaseradstorleksanpassning av både matriser och vektorer till, för vad en användare ofta upplevssom likvärdigt förallokerade variablers prestanda. Det senare har emellertid medfört enabstraherad minneshanteringsmodell utan o�ciellt stöd för explicit kontroll av när funk-tionsargument skickas som referenser eller direkta värden. Det här gör att kods prestandai termer av exekveringstid i värsta fall degraderas linjärt med storleken på dataseten (N)som behandlas, något som vid datavisualisering blir noterbart redan vid moderata vär-den på N . För att kringgå denna problematik utvecklades explicita datareferenser (attjämföra med pekare i C) med hjälp av odokumenterade funktioner i MATLABs libmx-bibliotek och en skräddarsydd visualiseringsklass.

För interferogramanalysen tillhandahölls referensimplementationer av omsamplingsru-tinen och den �nita, diskreta Fouriertranformationen (FFT), vilka gav en övre gräns förexekveringstid för de nya implementationerna.

På experimentellt erhållen data ökade DAQSs omsamplingsimplementation genom-�ödet med en faktor 19, vilket i den aktuella uppställningen motsvarar omsamplings-frekvens på 108 �yttal per sekund. Minnesanvändningen minskade med 72% eller från7.1 till 2.0 i termer av det teoretiska minimumet. Till följd av en omstrukturerad exekver-ingssekvens och ökad funktionalitet i den nya datavisualiseringsklassen saknar DAQS enFouriertransformfunktion motsvarande den i referensimplementationen, FFTn sker istäl-let bara vid behov och �era delar har parallelliserats. Vid manuellt sekvensierad exekver-ing uppgick dock CPU-tiden för motsvarande funktionalitet i värstafallsscenariot till 75%av referensen. Som referens till visualiseringsklassen användes MATLAB R2014bs plot-funktion i Windows 7, där de jämförda tiderna var de från funktionsanrop till färdigritad�gur. Till skillnad från plot varierar klassens tider inte bara med N utan bara med stor-leken i pixlar på visualiseringsytan. Vid, av MATLAB given, standardstorlek på ytanoch N = 18.5 · 106 (motsvarande ett svep av retrore�ektorn) visualiserar klassen datan100x snabbare än plot.

iv

Utöver att hämta in och analysera data innefattade de primära målen även verktygför att kon�gurera DACet och kontrollera stegmotorn till FTSns retrore�ektor, bådaimplementerade i DAQS.

I tillägg de primära formulerades även tre sekundära mål; kontinuerlig inhämtning avdata för retrore�ektorns båda färdriktningar, en HITRAN-baserad referensabsorptionssp-ektrumgenerator, och funktionalitet för ökad användarvänlighet. Det förstnämnda visadesig, trots tillräckligt reducerad analystid, inte möjligt att implementera med den be�ntligadrivrutinen för DACet. För att maximera användbarheten av generatorn konverter-ades HITRAN-databasen till MySQL-format, varefter ett abstraheringslager i form aven MATLAB-klass med metoder för val av absorptionslinjer och spektrumgenerering medett tillhörande gra�skt gränssnitt (GUI) utvecklades. Slutligen bestod förbättringarnaav användarupplevelsen till stor del av omstrukturering och gruppering av GUI-elementsamt integration av dokumentation (hjälp-knappar) i GUIt.

Sammanfattningsvis kräver den, för projektet slutgiltiga produkten fortfarande en nydrivrutin för DACet för att uppnå likvärdig funktionalitet med referensimplementatio-nen. Många av DAQSs komponenter kan emellertid användas som fristående klasser ochfunktioner fram till dess. Nämnvärt är också att NI enligt egen utsago inte har någraplaner på att utveckla en MATLAB-speci�k drivrutin då MathWorks inte säljer licensertill dem.

v

Acknowledgements

I would like to thank my supervisor, Amir Khodabakhsh, and my examiners AleksandraFoltynowicz-Matyba and Ove Axner for their seemingly endless patience, help during thework itself and for letting me stray and explore many of the interesting aspects of thisthesis work.Further I would like to thank Alexandra Johansson for her invaluable input, Olof Rydbergand Edvin Norén for great company during the work, and Elisabeth Wetzer for all thehelp, encouragement, and proofreading.Finally this work would never even have begun without the inspiration and help alwaysgiven by my brother Arvid Åhrberg.

vi

Contents

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Theory 4

2.1 Fourier Transform Spectrometer . . . . . . . . . . . . . . . . . . . . . . . . 52.1.1 Optical Frequency Comb FTS . . . . . . . . . . . . . . . . . . . . . 6

2.2 Resampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Data reduction/interpolation for visualization . . . . . . . . . . . . . . . . 82.4 Molecular absorption spectroscopy and HITRAN . . . . . . . . . . . . . . 10

2.4.1 Lorentzian lineshape . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.2 Gaussian lineshape . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.3 Voigt pro�le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.4 van Vleck-Weisskopf lineshape . . . . . . . . . . . . . . . . . . . . . 122.4.5 Numerical evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Method 14

3.1 MATLAB internals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.1 Java back end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 C representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Design patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.1 CoW and function arguments . . . . . . . . . . . . . . . . . . . . . 173.2.2 Preallocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.3 Boolean object evaluation . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Parallelization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.1 MATLAB local pool . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2 GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Notes on optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5 MATLAB GUI programming . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5.1 GUI layout management . . . . . . . . . . . . . . . . . . . . . . . . 223.5.2 GUI back end versions . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6 Data visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Implementation 25

4.1 Previous system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 New system - DAQS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.2 Usage and structure . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.3 HITRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2.4 MATLAB functionality extensions . . . . . . . . . . . . . . . . . . 29

vii

4.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Results 325.1 Primary objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1.1 Resampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1.2 FFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2 Secondary objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2.1 HITRAN interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3 End product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Discussion 376.1 HITRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 Code optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.3 MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

References 40

Appendices 42

A Analytical interferogram derivations 42A.1 Single frequency interferogram . . . . . . . . . . . . . . . . . . . . . . . . . 42A.2 Multiple frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

B HITRAN data 45

C mxArray and libmx 48

D Files and descriptions 49

viii

1. INTRODUCTION

1 Introduction

1.1 Background

Real time data acquisition and analysis have today become a commodity, implementedin everything from augmented reality functions in smart phones to oscilloscopes usedby experimental physicists. The tools to implement such functionality rarely o�er easycustomization though, in consumer markets the vast majority of applications share acommon need which is just variations of pattern recognition within image data. Inscienti�c �elds applications are as diverse as the term indicates, even when narrowingthe scope to spectroscopic ones.

The Erbium-�ber OFC setup of the OFCS Group at the Department of Physics atUmeå University includes several unique, in-house developed components that acquireabsorption spectra in a fraction of the times required by commercially available systems.The digitizer used, a National Instruments PCI-5922, is capable of acquiring data at arate of 15 MS/s per channel with a sample rate dependent resolution ranging from 16 to24 bit. This requires a real time acquisition and analysis software to be able to performat least a magnitude more single-precision �oating point operations per second, whilealso visualizing the data continuously.

The initial implementation of this software was based on LabVIEW, using its MATLAB-interconnectivity to implement the computationally intense parts of the analysis. Whilethe interoperability of the two are highly useful it imposes some restrictions on executiontime and exchanged data set size (N) as arguments from one to the other are alwayspassed by value. The combination of this, data set sizes in the 107-range, the fact thatMATLAB by default uses double precision number representation, and that explicit in-vocations of garbage collection are strongly discouraged in both languages resulted in theneed for a new, more optimized implementation.

1.2 Scope

Though the end product is speci�cally designed to �t the needs of one spectroscopic setup,the Noise Immune Cavity Enhanced OFCS (NICE-OFCS), it is deliberately developedin a generic fashion to be reusable in similar settings. Hence, only the components ofthe current setup that are needed to produce the right input for the data acquisition andanalysis system (DAQS), and their governing theory, are covered in this report. For acomprehensive description of the setup see [1].

Basic programming skills in MATLAB, a general understanding of object orientedconcepts and laser-based spectroscopy as well as familiarity with the more commonlyused components therein is expected by the reader. It should be noted that, though thisis covered by many text books the nomenclature in this thesis closely resembles that in[2].

As the main body of work consisted of programming in MATLAB, emphasis hasbeen put on the language's strengths and weaknesses in these types of applications andthe design choices made to facilitate high cohesion, reusability, and maintainability in

1

1. INTRODUCTION

performance critical settings.

1.3 Objectives

The primary objectives for the thesis work have been to implement the following inMATLAB

• A graphical con�guration and data acquisition utility for the DAC

• Stand-alone data analysis functions which can be invoked during acquisition

• To-disk saving of raw acquisition data and analysis results

• FTS retarder motor control

The minimum requirement for the above was to perform their individual tasks in less timebut with identical numerical results (where applicable) as the reference implementation,for which the end product should work as drop in replacement. This includes not onlyequivalent functionality but also a user experience (UX) that �ts into the work�ow ofthe spectroscopy group.With the primary ful�lled and given time, improvements in functionality was set as thesecondary objectives. Tasks given were

Con�guration pro�lesSaving and loading sets of DAC-con�guration parameters to and from named pro-�les.

Two way acquisitionGiven su�cient data analysis time reduction the acquisition and analysis shouldrun continuously, i.e. in both directions of movement of the retarder.

HITRAN reference spectraFrom the parameters of an acquisition a reference absorption-spectrum should begenerated from HITRAN-data.

In addition to these, the general goal given for the project was maintainability. Incombination with the need for high performance this boiled down to a substantial amountof documentation.

1.4 Thesis outline

TheoryThe section covers the algorithms and super�cially the theory governing the dataanalysis, data-reduction for visualization, and HITRAN-based numerical evaluationof the basic theory of absorption spectroscopy. The main focus of the last part isto describe it from an implementational perspective, hence constants are generallyseparated in equations where they in other literature would not be.

2

1. INTRODUCTION

MethodSection 3 describes the development environments and tools in terms of theirstrengths and weaknesses. It also includes subsections covering some of the specialconsiderations which need to be taken when working with MATLAB in performancecritical situations.

ImplementationThe section includes a brief description of the previous system and the logical struc-ture of the acquisition and analysis before covering the implementation of DAQS.This is followed by a comparison between the two. A more in-depth description ofthe intricacies DAQS is available in [3], which should be seen as a complement tothe thesis in general and this section in particular.

ResultsThe most signi�cant results of performance improvements are presented in the�rst part of this section in terms of performance relative to the reference imple-mentation, with only short examples of the absolute values as these are entirelyhardware-dependent. The secondary objectives, end product, and a description ofthe precision in the calculations performed in DAQS then follows.

DiscussionThoughts and discussions covering primarily the project itself, its key componentsand concepts. It includes a short description of the spin-o� project for HITRAN-interaction, the e�ects of MATLAB's high-level programming concepts, and a moregeneral discussion of code optimization in scienti�c projects.

3

2. THEORY

2 Theory

An OFC can in many absorption based spectroscopic techniques be viewed as the equiva-lent of using thousands of synchronized laser lines in a measurement. The output, a trainof extremely short pulses, is produced by locking together the phases of a large numberof longitudinal modes of the laser. This technique is �ttingly called mode-locking andthe details of it can be found in [4]. In �gure 2.1, a small subset of pulse train is depictedtogether with the frequency domain representation of it. The key properties de�ned inthe �gure are the o�set frequency,

ω0 = −∆φ

tr(1)

where ∆φ is the pulse-to-pulse carrier-envelope phase shift and tr the pulse separationin time, and the angular-frequency spacing, or angular repetition frequency

ωr =2π

tr. (2)

t

E(t)

tr

→ ←∆φ

→ ← τ

/ / / /

ω

I(ω)

→ ←ω0

→ ←ωr→ ← δω

/ /

Figure 2.1: Mode-locked pulse train of an OFC in time and frequency domain. The o�set frequency, ω0,corresponds to the carrier envelope phase shift, ∆φ, in the time domain and can be seen in the OFCsspectral envelope as well.

4

2. THEORY

Given these two, a frequency

ωn = ω0 + nωr (3)

where n is any positive integer such that ωn falls within the spectral envelope, shown inthe frequency domain in �gure 2.1, can be obtained. The FWHM of this is de�ned bythe temporal duration of each pulse τ as

δω = 2π/τ (4)

and thus the spectral output of the OFC. Knowing and being able to control these param-eters constitutes the lower limit of what is needed to employ an OFC-based setup togetherwith DAQS, accomplished in the experimental setup with a MenloSystems FC1500-250-WG with a repetition rate of 250 MHz and output in the near infrared (NIR) wavelengthrange (1.5-1.6 µm).

2.1 Fourier Transform Spectrometer

A FTS is based on the Michelson interferometer (MI), but instead of having one �xedand one moving mirror both the re�ected and transmitted part of the beam are routed toa double-sided retrore�ector mounted on a rail as shown in �gure 2.2a. The displacementof the retarder,

∆L = 4δOPD (5)

thereby corresponds to four times the change in optical path di�erence (OPD), δOPD.

OFCHeNe

TR+RT

TT +RR

I (δOPD)BS ∆L

(a) Fourier transform spectrometer.

t[

λ

4v

]

I(δ

OPD)[I

0]

0

1

(b) Theoretical HeNe inteferogram.

Figure 2.2: Figure (a) shows the layout of an FTS with top output consisting of through the beamsplitter (BS) twice transmitted (TT in the �gure) and twice re�ected (RR) OFC beams, middle outputof �rst transmitted then re�ected (TR) and vice versa (RT ). (b) shows a HeNe interferogram, lower

output, given constant retarder velocity and δ(0)OPD = 0.

5

2. THEORY

As seen in 2.2a the two output beams, not counting the HeNe reference, will have arelative phase-shift of π. The upper (TT + RR in �gure 2.2a) with an odd number ofre�ections i.e. ∆φup = (2n+ 1)π = π and the lower (middle, TR+RT ) with ∆φdown =2nπ = 0. When one of these are subtracted from the other, as is done in the currentsetup by an auto-balancing detector, common-mode noise is considerably reduced whilethe resulting maximum amplitude corresponds to I0 − (−I0) = 2I0, where I0 is theintensity incident on the detector.

The interferogram shown in �gure 2.2b has twice the frequency of one from a corre-sponding MI. This can be deduced by equation 5, the constructive interference condition,

δOPD = nλ, (6)

and the destructive one,

δOPD =

(n+

1

2

)λ (7)

where n is any positive integer and λ the wavelength. Given that ∆L = v∆t, where v isthe retarder velocity, the frequency of the interferogram, fI , will be

fI ≡ fFTSI = 2fMII =

4v

λ. (8)

Before moving on to the OFC interferogram it is worth considering the practical impli-cations of fI . As mentioned earlier the DAC operates at discrete sampling-frequencies.To ensure valid measurement results the Nyquist-Shannon sampling theorem, given in[5], gives an upper limit for the retarders velocity as

vmax =λfS

8(9)

where fS is the sample rate.With equation 8 the interferogram for a single wavelength beam such as the one from aHeNe laser is simply a cosine-wave with a linearly v-dependent frequency and a phaseshift, ∆φ, determined by the initial OPD. The e�ect of a constant versus non-constantretarder velocity can be seen by comparing �gure 2.2b and 2.4a, and b (dotted line only).

2.1.1 Optical Frequency Comb FTS

Starting with the expression for a single frequency MI interferogram with a perfect beam-splitter (BS), as described in [2], and an arbitrary initial OPD the expression for thetransmitted intensity can be expressed in terms described by equations 6 and 8 as fol-lows,

I (δOPD) = 2RTI0 [1 + cos (2πfIt+ ∆φ)] (10a)

= 2RTI0

[1 + cos

(2π

4v

λt+ ∆φ

)](10b)

= 2RTI0 [1 + cos (2π4δOPD (t) + ∆φ)] (10c)

6

2. THEORY

where R and T are the re�ection and transmission coe�cients of the BS. Above, with aperfect one, both are 0.5. Treating an OFC simply as a sum of multiple single frequencylasers results in its FTS interferogram becoming the sum of equation 10, as seen in �gure2.3,

I (δOPD) = 2RTI0

N∑n

[1 + cos (2πfInt+ ∆φn)] (11a)

= 2RTI0

N∑n

[1 + cos

(2π

4v

λnt+ ∆φn

)](11b)

= 2RTI0

N∑n

[1 + cos (2π4δOPDn (t) + ∆φn)] (11c)

where N is the number of frequencies, and ∆φn the pulse-to-pulse carrier envelope phaseshift. For a more complete, analytical derivation of equations 10 and 11 refer to appendixA.

No.

Frequencies,N

40

41

42

43

Multiples of (dt · frep)−1

0 1 2 3 4 5 6 7 8 9 10

(a) Summation of multiple single frequency signalswith normalized amplitudes.

Samples×106

0 2 4 6 8 10 12 14 16 18

I[V

]

-5

-4

-3

-2

-1

0

1

2

3

4

5

(b) Experimental OFC interferogram

Figure 2.3: Comparison of summations of single frequency signals, (a), and experimental OFC interfer-ogram, (a).

2.2 Resampling

Due to mechanical limitations the retarder cannot run at a constant velocity throughout asweep, which is why a reference beam is needed. With a well de�ned reference wavelength,λ = 632.9914 nm, for HeNe and a constant sample rate, fS , the velocity of the retarder,v, may be unknown as long as it is less than vmax, as given by equation 9. Withsamples of a sweep separated by a constant ∆t = 1/fS , and a zero-mean adjusted HeNeinterferogram, two adjacent (interpolated) zero-crossings will be separated by λ/2 in thespatial domain. Using these together with the extreme points described by equation

7

2. THEORY

6 and 7 the OFC interferogram can be resampled to a constant sample separation ofλ/4 with algorithm 2.11, thus ful�lling the equispaced samples requirement of the �nitediscrete Fourier transform.

Algorithm 2.1: Resampling of OFC interferogram1

1. in: H(t), Zero mean HeNe interferogramin: D(t), OFC interferogramout: R(λ), Resampled OFC interferogram

2. Fetch indices of zero-crossing pairs (green and black dots in �g. 2.4b)i : (sgn (Hi) + sgn (Hi+1) = 0)

i′ := i+ 1

3. Calculate fractional indices of zero-crossings (red x's)dzi := i+ Hi

Hi−Hi′

4. Interpolate OFC interferogram values at zero-crossingsRi := Di − |dzi − i| (Di −Di′)

5. Calculate fractional indices of local extreme values (magenta x's)

dx :=dzi+d

zi−1

2

6. Determine indices of local extreme pairs, assuming adjacency to dx

k :[|Hk| = max

(∣∣Hbdxc∣∣ , ∣∣Hddxe∣∣)]k′ := k − 1 + 2 (ddxe − k)

7. Interpolate values at local extremesRk := Dk − |dx − k| (Dk −Dk′)

t

v[v

0]

(a) Retarder velocity pro�le.

t

I[I

0]

(b) HeNe inteferogram.

δOPD [λ]

I[I

0]

(c) Resample points.

Figure 2.4: Example stages from FTS re�ection to resample points. Notice the HeNe interferogramsdependence on the retarder-velocity and the resample points' lack thereof.

2.3 Data reduction/interpolation for visualization

Rendering large datasets using the built in functions in MATLAB, even when hardware-accelerated graphics are supported, is a time consuming task independent of the size

1Here ":" should be read as such that and ":=" as is equal to.

8

2. THEORY

of the surface to visualize it on. In cases where the number of samples in a data set,N , is larger than what can be visually represented with a line plot manually reducingthe set is - in the experimental setup - far more e�cient than letting MATLAB renderit in its entirety.2 Given a data visualization implementation expecting surface size-dependent data sizes as input the reverse situation (N smaller than available surfaceallows) will in certain instances introduce an overhead caused by value interpolation. Inthe experimental setup however, this overhead is negligible. With the following data setreshaping algorithm the time required from function call to actual rendered data is thussigni�cantly reduced in most use cases.

Algorithm 2.2: Pre-line plot visualization data set reshaping

1. in: I, data set to be visualizedin: N , length of data setin: M , desired length of output dataout: O, reduced or interpolated input data

2. If M = N :

a. Set output to inputO := I

3. Else if M > N :

a. Evenly distribute I in On := {1, 2, 3, . . . , N}m := n+

⌊(n− 1)M−NN−1

⌋Om := In

b. Linearly interpolate values for empty, forward adjacent elements in O (�nal stepfor cases where M ≤ 2N − 1)

i : (mi+1 −mi > 1)

Omi+1 := Omi +Omi+1−Omi

mi+1−mi−1

c. Interpolate remaining values (if any)

m′j :={j : j ≤M, j ∈ N+\{m}

}Om′j+1

:= Om′j +(Om′j −Om′j−1

)4. Otherwise:

a. Set O to the max and min values of all contiguous subsets of I of size N/Mnij :=

{i : i < j NM , i ∈ N+,

{j : j NM ≤ N, j ∈ N+

}}m :=

{0, 1, . . . , M2 − 1

}O2m := max

(Inij

)O2m+1 := min

(Inij

)2While this is also true for scatter plots only line plots were implemented in DAQS.

9

2. THEORY

Note that the implementation of the algorithm in most programming languages requireschecking and calculating values for "residual" indices in both step 3 and 4.

2.4 Molecular absorption spectroscopy and HITRAN

The Lambert-Beer law,

IA = I0e−α(ν) (12)

states that the intensity of light transmitted through an absorbing sample, IA decreasesrelative to the incident intensity I0 by the exponential factor

α (ν) = ηSpcrelLχ (ν) (13)

η = 10−6n0T0/T

where η is, given a constant temperature, T , a scaling constant [molecules / (cm3·atm)]containing the Loschmidt constant, n0 [molecules / m3], and T0 = 273.15 K. S, theintegrated molecular linestrength [cm−1 / (molecule·cm−2)] is given in HITRAN, p isthe pressure [atm], crel the relative concentration of the species, L the length of thesample [cm], and χ (ν) is the area-normalized absorption lineshape function [1/cm−1].The last term describes the broadening of the observed intensity dip, mainly caused bythe movement and internal interactions of the molecules.

For gaseous molecules and incident light in the NIR spectrum the absorption causingthe amplitude of the dip in transmitted energy is primarily caused by transitions in therotational and vibrational (ro-vibrational) states of the molecules. The number of suchtransitions depends on the number of atoms making up the molecule, giving a nonlinearmolecule a maximum of 3n degrees of freedom to move, n being the number of atoms.Three of these represent translational motion in mutually perpendicular directions, an-other three the rotational motion about the x, y, and z axis of the molecule, and theremaining 3n − 6 the number of ways atoms in a nonlinear molecule can vibrate. Fordetailed information on these vibrational modes and Fourier transform spectrometry inthe infrared spectra see [2].

The molecular properties governing ro-vibrational absorption are also documented inHITRAN (a list of all the properties in it is available in table B.1). It currently containsin excess of seven million records, spanning 47 di�erent species of gaseous molecules andtheir most signi�cant isotopologoues. With these and the exponent from equation 12given by equation 13 theoretical absorption spectra from any of the 47 species can begenerated.

2.4.1 Lorentzian lineshape

When pressure broadening dominates, i.e. when the lifetime of molecular states areshortened mainly by collisions, as is the case at room temperature and pressures above0.1 [atm] (altitudes below 16 km), the lineshape is described by a Cauchy distribution,

10

2. THEORY

in spectroscopic applications called the Lorentzian lineshape,

χL (ν) =1

π

δνL

(νd)2 + (δνL)2

(14)

νd = ν − (ν0 + δairp)

where νd is the detuning frequency [cm−1], the transition line frequency, ν0 [cm−1], andthe pressure-induced line shift, δair are both given in HITRAN. The Lorentzian pro�lehalf-width-half-maximum (HWHM) is calculated using equation A12 from [6] as follows

δνL =

(TrefT

)nairp (γair (1− crel) + γselfcrel) (15)

where Tref = 296 K, and both the air broadening and self broadening coe�cients, γairand γself respectively, are found in HITRAN. When lacking other data the classical value,as suggested by [7], of the temperature dependence exponent nair = 0.5 can be used.

2.4.2 Gaussian lineshape

In lower pressure situations where the main broadening mechanism is the Doppler e�ectexperienced by the molecules; having a velocity component v‖, parallel to the direction ofpropagation of the light will cause them to interact with a frequency ν ′0 = ν0

(1 + v‖/c

).

Doppler broadening causes a Gaussian lineshape,

χG (ν) =kχG

δνDexp

[−(νdδνD

)2]

(16)

kχG = 2√

ln (2) /π

where δνD, the HWHM (in this case) also known as the half Doppler width, is given by

δνD = kδνDν0√T/M (17)

kδνD =

√2 ln (2) 103R

c

where R is the molar gas constant. The factor 103 comes from R's unit being J / (mol·K)= m2·kg/(mol·s2·K) and the molar mass, M , being given in units of g/mol.

2.4.3 Voigt pro�le

In settings where both Doppler and pressure broadening are in�uential a convolution ofthe two named after German physicist Woldemar Voigt is used. Due to the computationalcost of convolutions Whitings approximation is used in DAQS, and with the assumptionα (ν)� 1 equation 13 is reduced to

α (ν) =I0 − ITI0

=∆I

I0= σV L (18)

11

2. THEORY

where σV is given by

σV (ν) = σV (ν0) (1− x) exp(−kσV1 y2

)+

x

1 + y2

+ kσV2 x(1− x)

[exp

(−kσV3 y2.25

)− 10

10 + kσV4 y2.25

](19)

x =δνLδνV

y =|ν − ν0|δνV

=|νd|δνV

σV (ν0) =S

2δνV (kσV5 + kσV6 x+ kσV7 x2)

where the constants kσVi , i = 1, ..., 7, given in table 2.1, have been adjusted from theoriginal approximation in [8] to account for δνV as HWHM which is given by [9] as such

δνV = kδνV1 δνL +

√kδνV2 (δνL)2 + (δνD)2 (20)

where, again, kδνV1 = 0.5346 and kδνV2 = 0.2166 have been adjusted. The approximationreduces to the Gaussian pro�le as δνL → 0 and is always accurate to within 0.01%.

Table 2.1: kσVi values

i 1 2 3 4 5 6 7Value 0.6930 0.0160 0.0841 0.2100 1.065 0.447 0.058

2.4.4 van Vleck-Weisskopf lineshape

The three lineshape functions listed above are by far the most commonly used ones. Inthe special case of Lorentzian lineshape and extremely long wavelengths, ν0 < 200 cm−1,the van Vleck-Weisskopf lineshape o�ers a slight improvement, as described in [10], andis given by

χVW (ν) =δνLπ

(ν

ν0

)2 [ 1

(νd)2 + (δνL)2

+1

(ν + ν0)2 + (δνL)2

](21)

2.4.5 Numerical evaluation

To implement the above for a uniformly distributed set of wavenumbers W , of size nand corresponding HITRAN records H, where W0 ≤ Hν0

0 and Wn ≥ Hν0m where m is the

total number of records in H, the following algorithm has been used3. Note that for anaccurate approximation of the absorbance spectrum A, n ≥ 100m and n � Hν0

m −Hν00

needs to be true.3For brevity only references to equations are included.

12

2. THEORY

Algorithm 2.3: HITRAN based absorption spectra generator 3

1. in: W , uniformly distributed set of wavenumbers [cm−1]in: H, set of HITRAN recordsout: A, absorbance spectrum

2. Calculate δνL and δνD as given in equation 15 and 17 from H

3. Calculate δνV as given in equation 20 from table B.2

4. Calculate x and σV (ν0) as given in equation 19 from H

5. For all records i in H:

a. Set νdi = W −Hν0i

b. Calculate yi as given in equation 19 from Hi and δνVic. Evaluate and add the results of equation 18 and 19 to A

13

3. METHOD

3 Method

As mentioned in the introduction the DAQS is implemented in the numeric comput-ing environment MATLAB which employs a fourth-generation programming language.The generational division of programming languages is not necessarily chronological,instead it is based on abstraction. Each generation adds a layer of abstraction ontothe hardware, i.e. �rst-generation languages are pure machine code, historically pro-grammed with punch cards but rarely used today. Assembly languages are categorizedas second-generation, more easily read and written by humans but still architecture-speci�c. Most general purpose languages are third-generation meaning they are notmachine dependent and the host on which it runs or is being compiled generates themachine instructions. Fourth-generation languages do not only abstract hardware butalso many concepts such as data representation, storage, mathematical optimization, andare often domain-speci�c. The layers of abstraction introduced should ideally produceno or very little overhead in terms of execution speed and memory consumption. InMATLAB however this is not true for every aspect, hence the following section describesin general terms the methods used to minimize the overhead introduced in various partsof the implementation of DAQS as well as other measures to optimize MATLAB code.

3.1 MATLAB internals

With execution time being integral to DAQS simply optimizing function calls and codestructure proved to be insu�cient. To increase speed even further the internal structureof MATLAB had to be examined, a not entirely trivial task given the age and maturityof it. The internals have been in development for over 30 years and have during thistime provided a relatively consistent interface to many of the best performing and mostversatile math-libraries, including MathWorks' own. This requires abstraction not onlytowards the end user but internally as well. When the di�erent back ends of MATLABare not taken into account the overhead created by the internal abstraction layers can,as noted during the development of DAQS, become quite substantial. One of the mostobvious cases of this is when large amounts of data has to be copied due to graphicaluser interface (GUI) related actions. To avoid this, as the o�cial documentation on thesubject is rather sparse, the structure of MATLAB's Java back end, which is responsiblefor GUI-interaction, had to be examined and contrasted with the non-GUI related ones.

3.1.1 Java back end

Since version 6.0, released in November of 2000, MATLAB comes bundled with a pre-con�gured Java Virtual Machine (JVM). It uses this on hosts where newer versions areavailable as well, an understandable design choice even with the obvious drawback ofmissing new features.4 With it cross-platform GUI-programming capabilities based onJava's AWT and Swing toolkits are supplied.

4This has rarely been a problem with the notable exception of rendering on new, high resolution/highpixel density monitors.

14

3. METHOD

MATLAB's GUI-components are primarily wrappers for their Java toolkit counter-parts. These, though not o�cially available to the programmer are quite easily accessibleusing built-in functions only. Modifying GUI components by accessing their underlyingJava-controls can be useful when only minor changes in the components functionality re-quires major additions to its wrapper's callback. However, since internal structures andtoolkit-versions change with MATLAB-releases this is not a practice that should be incor-porated in any distributed project. Instead the still undocumented, but since the initialrelease supported, Java component constructor family of functions should be used. Giventhat many toolboxes, including the ones shipped with the base installation of MATLABrely heavily on them and that they have stayed consistent over the recent major revisionupdate of the graphical back end, the risk of changes in their syntax or functionalitycan be considered quite small in the foreseeable future. The main advantage of the con-structors are that they, unless explicitly stated otherwise, create Java-components anda generic MATLAB parent component using the toolkits distributed with MATLAB inthe structure used by the running instance.Creating and interacting with Java-components as opposed to their wrappers is in prac-tice usually only necessary when major changes in functionality of an existing or a com-pletely new type of component is needed. An illustrative example of the former is theuiedit-class and its autocomplete-functionality. The lack of control of caret positionand text-selection in a uicontrol(’Style’, ’edit’) -control makes inline autocomple-tion quite tedious to implement, with the underlying Swing JTextField though it isa fairly straight forward process. With the extra control that using pure Java controlsgrants any operation that may be native to the MATLAB control can be easily cus-tomized.

3.1.2 C representation

While the technique described above is useful to extend GUI-functionality its use inperformance-tuning, primarily by minimizing data copy operations, requires at least a ba-sic understanding of MATLAB's internal data representation. In versions before R2013bwhen developing mex-�les, i.e. compiling C/C++ or Fortran (not covered here) codeinto functions callable from MATLAB, the C structure-representation, called mxArray,of arguments and outputs were, though opaque, accessible to the programmer. Theintention of having an opaque datatype represent variables and provide an applicationprogramming interface (API) mimicking the MATLAB language is, as in the case of thelanguage itself, to abstract the internal workings and thus have the ability to changeit without breaking legacy code support. It does however also impose many of the re-straints present in such a high-level language on an earlier generation language. For thisreason, investigative purposes, and pure academic curiosity Peter Boettcher and GarethJones documented [11] and supply a header �le giving direct access to the �elds of themxArray, a subset of which are listed in table C.1. From their work details on MAT-LAB's copy-on-write (CoW) mechanism can be discerned. The direct e�ects of it can beexamined using the undocumented -memory option of profile as illustrated by listing3.1 and table 3.1.

15

3. METHOD

Listing 3.1: MATLAB CoW% cow_profiler.mfunction cow_profiler(r, c)

x = rand(r, c); % initial allocationy = x; % crosslink set, no allocationx(1, 1) = 0; % data copied to y and then modified

end% profiling call>> profile(’-memory’, ’on’);>> cow_profiler(1e4, 1e4);>> profile(’viewer’);

Table 3.1: MATLAB CoW-related pro�ling results

Line Code Total Time Allocated Memory

2 x = rand(r, c); 0.802 s 782780 Kb3 y = x; 0 s 0 Kb4 x(1, 1) = 0; 0.243 s 782780 Kb

As seen the data in x is not actually copied until one of the variables value is altered.Implementationally this corresponds to updating the crosslink and pdata �elds of themxArray; at line 2 the mxArray of x is created, at line 3 the same happens for y and

the crosslink of x is updated. Finally a new data segment is allocated, the original

data in x is copied to it, y s pdata is updated and both their crosslinks are reset.Boettcher and Jones' work covers the MATLAB releases of 2012. In later versions the

undocumented functions of the libmx-library highly suggest that MathWorks has movedto a dynamic mxArray structure, a notion supported by tests carried out during thisthesis work. Using the undocumented functions of libmx is comparatively safer than di-rectly accessing the oblique structure and has made custom functionality less hazardousto implement.Though experimental results strongly indicate the size of an mxArray in MATLABR2014b running on the 64 bit version of Windows 7 to be 112 bytes and can thus beassumed to contain more �elds than the 104 byte big one described by [11] the subsetlisted in table C.1 is su�cient to extend mex-functionality to amongst other things imi-tate C-style pointers.For consistency most of the code in DAQS is designed to avoid unnecessary memory al-locations and while this may not be apparent without knowledge of the CoW mechanismthe data-acquisition loops rely heavily on it. The plot-wrapper class screen2 also uti-lize one-time allocations in combination with C-style pointers to provide single-allocationdata visualization.

3.2 Design patterns

The introduction of just-in-time (JIT) compilation in R2011a has reduced the inherentstructural performance problems of MATLAB's object-oriented programming language

16

3. METHOD

but also added a few quirks which can seem incoherent, i.e. seemingly small and some-times insigni�cant changes in code having a signi�cant performance impact. A ratherunfortunate e�ect of the object oriented structure which is not a�ected by JIT, is thatimplicit object evaluation can in the cases of code branching and variable initializationbe considered non-trivial and can easily result in bugs that are hard to locate. Commonpractice in many similar languages is to always use explicit evaluation and enforce cer-tain code styles that improve readability and are in large considered good practice. Doingthe latter often comes with a performance trade-o�, this is especially true in the caseof MATLAB. Performance critical code may therefore not only deviate from these stan-dards but do in some cases require a structure almost exact opposite of them. Followingthe guidelines given in [3] the cases in which this style is used have been almost entirelyisolated to DAQS-speci�c �les, resulting in what could be described as predictable codestructure inconsistency.

3.2.1 CoW and function arguments

As brie�y described in section 3.1.2 the CoWmechanism is designed to reduce the numberof memory allocations. This feature is particularly important to keep in mind whenworking with large data sets. To avoid unnecessary copies in-place data manipulationshould be utilized when possible. This also relates to function arguments though ina slightly more involved way. MATLAB passes arguments to functions by referencewhen possible, that is when their values are not altered within the function. Hence thegeneral rule would be to avoid assigning new values to input arguments, the most notableexception to this is small functions where in- and output are strongly related. As withanonymous functions it is possible to avoid allocating memory for variables within afunction by using the same name for both input and output arguments as illustrated bylisting 3.2. The de�nition of "small functions" in this context is functions where the sizeof local variables does not depend on N .

Listing 3.2: Minimizing memory usage in functionsfunction x = myFunction(x, y)

% temporary variable x is not allocated[x, z] = someOperation(x, y); % z is a scalarx = someOtherOperation(x, z);

end

It should be noted that a design optimized for large N often includes global or persistentvariables, parent-scoped variables within nested functions and/or heavy use of propertiesof handle class objects. In small N situations this can result in degraded performancedue to the overhead of this structure and it is therefore important to ensure at least anapproximate magnitude of N before settling on it.

3.2.2 Preallocation

If there is no way to know the size of a vector at compile time or preallocation for someother reason is not possible the method used to grow said vector a�ects performance

17

3. METHOD

profoundly, as seen in listing 3.3. In this case JIT has played a major role in performanceboosting [12]. Depending on the magnitude of N on-the-�y preallocation, i.e. dynami-cally increasing the vector's size by certain a factor when it runs out of space is generallya, performance-wise, safe choice. The other, earlier strongly discouraged ways of eitherusing out of bounds indices or concatenation have in case of indexing, since R2011aincreased in speed and are by the 2014-releases on par with most on-the-�y methods.Concatenation, however, is still severely lacking. The small di�erence between end-basedand direct indexing is the result of MATLAB having to determine the length of the vectorduring each iteration in the former and, though the relative di�erence in certain situa-tions can be quite big, the actual impact in a loop with any type of computation is inmost cases negligible.

Listing 3.3: Dynamically growing vectors>> data = []; y = 0;>> tic();while(y < 1e6)

data = [data, 1];y = y + rand();

endtoc()Elapsed time is 5687.447569 seconds.>> length(data)ans =

1999465>> data = []; y = 0;>> tic();while(y < 1e6)

data(end + 1) = 1;y = y + rand();

endtoc()Elapsed time is 0.438919 seconds.>> length(data)ans =

1998533>> data = []; y = 0; i = 1;>> tic();while(y < 1e6)

data(i) = 1;y = y + rand();i = i + 1;

endtoc()Elapsed time is 0.433163 seconds.>> length(data)ans =

2000989

18

3. METHOD

3.2.3 Boolean object evaluation

As a consequence of being a weakly typed, computation-centric language MATLAB hasa special way of evaluating objects as conditions. In many weakly typed languagesargument validation are often either forcibly explicit through toBoolean-like methodsor implicit as built in functions and operations will throw exceptions when suppliedarguments of the wrong class. This is not the case for all built-ins in MATLAB, evaluatingcells or structs as booleans will throw exceptions but doing so with vectors or matriceswill not. Unfortunately the evaluation of matrices di�ers depending on if it is empty, asshown in listing 3.4, or contains elements in which case if(A) , where A is the matrix,

is equivalent to if(all(A) && ~isempty(A)) .

Listing 3.4: Boolean evaluation of empty vector>> A = [];>> if(A); disp(’A == true’); end>> if(~A); disp(’A == false’); end>> if(~A == A); disp(’A == undefined’); end>> if(any(A)); disp(’At least one in A == true’); end>> if(all(A)); disp(’All in A == true’); endAll in A == true

Though the behavior of all is as documented in [13], the documentation is a bit con-

tradictory, �rst describing all as a natural extension of the logical AND operator butlater stating that it will return logical true given an empty vector, a case for which theresult of AND is strictly unde�ned.To circumvent some of the problems of direct object evaluation isempty is intendedto supply a safe way to test if a variable is empty regardless of class. However, thede�nition of empty di�ers between classes as shown in table 3.2. When taking theseaspects of MATLAB into account argument validation becomes a more strenuous taskthan in many other languages. One remedying quality with regards to this is that thelanguage uses short-circuit condition evaluation, i.e. as soon as a condition is logicallyevaluated the evaluation stops. This way a qualifying condition can be placed in frontof a class-speci�c one (this is the default style of user input based condition evaluationin DAQS).

Table 3.2: isempty return values for various arguments

contentargument

[] {} struct()∗

Nothing true true false[] true false false{} false false truestruct() false false false

∗) Content given as value to key ’field’, except for Nothing.

19

3. METHOD

3.3 Parallelization

Vector and matrix computations are in later version of MATLAB internally parallelized tothe extent supported by the CPU and OS. The parallel toolbox expands this with meansto perform explicit parallelization. In general this can be implemented using one of twomethods, distributed (local or over a network) worker pools or by using a local graphicsprocessing unit (GPU) with multiple cores. Both introduce an overhead in their respec-tive setup and teardown and are therefore mainly appropriate in computation-intensesituations, i.e. not only (or necessarily) very large N but when element transformationsare complex. The main reasons for these pre- and post-calculation overheads are dis-tribution and gathering of data, respectively. From an end user perspective these aremethod-agnostic actions, results computed in parallel, called composite variables, needto be merged into one variable per result. Implementationally, this process di�ers funda-mentally between the two, something that needs to be taken into account when selectinga method of parallelization.

3.3.1 MATLAB local pool

Distributed computations are based on pools of workers, locally Mathworks recommendsone worker per logical CPU core, though similar performance can be obtained usingnw =

ncpu

2m workers, where nw is the number of workers, ncpu number of logical coresand m ∈ N+. The main bene�t of running a local pool as opposed to letting MATLABdistribute the computations over the cores is that they will be utilized to a higher degree.This does not automatically mean shorter execution time, on the contrary, since locallydistributed workers in practice can be compared with several user interface-less MATLABinstances running on ncpu

nwcores each, unless the computations in the loop body are at

least partially execution order independent and time-consuming the result is often theopposite as exempli�ed by listing 3.5.

Listing 3.5: parfor comparison with execution order dependent computation loop body

>> a = rand(1, 1e6);>> b = rand(1, 1e6);>> c = zeros(1, 1e6);>> tic();parfor i = 1 : length(a);

c = (a(i) + sum(b)) / (length(b) + 1);endd = gather(c);toc()% Elapsed time is 370.933364 seconds.% Average CPU-load core 0: 100%, 1: 100%, 2: 100%, 3: 100%

>> tic();for i = 1 : length(a);

d = (a(i) + sum(b)) / (length(b) + 1);endtoc()% Elapsed time is 247.411576 seconds.

20

3. METHOD

% Average CPU-load core 0: 97%, 1: 99%, 2: 97%, 3: 96%

The startup and shutdown of a local pool also introduce additional overheads, the for-mer normally a few seconds though these are one-shot costs. These factors make localpools suitable only in very speci�c situations and performance gains should, as with alloptimization, be con�rmed rather than assumed especially in distributed projects wherethe underlying hardware cannot be controlled.

3.3.2 GPU

Though technically no set up is required for GPU parallelization, checking for the pres-ence of a supported GPU is in any distributed project necessary and adds an overheadtime-wise comparable to setting up a local pool of four workers. Implementationally, theparallel toolbox relies on CUDA, a parallel computing platform distributed by video cardmanufacturer NVIDIA, and is thus limited to their cards. Since even consumer gradevideo cards contain several hundred streaming cores, compared to eight or twelve logicalones in high-end CPUs, and CUDA is inherently designed for computation, performancegains are obtained in a wider range of situations than with local pools even though GPUcores in most cases operate at lower frequencies and with di�erent instruction sets thantheir CPU counterparts.

Data distribution and gathering are, as it has to be copied to and from the actualvideo card, quite a bit slower than in-RAM copies. This also imposes the amount ofRAM on the video card as the new restriction on address space, i.e. the amount of datathat can be used for computations. The restriction di�ers slightly from the one whenworking directly in MATLAB as the OS employs several swapping and virtualizationmechanisms to accommodate new allocations, making the theoretical maximum memoryavailable larger than that of the physical RAM. For GPU-calculations the amount ofRAM available on the video card is (at the moment) the maximum number of bytesavailable for calculations. However, with proper memory management and code that isdesigned with parallel execution in mind the GPU parallelization can be distributed withcon�dence.

3.4 Notes on optimization

The general rule of "make it run, make it right, make it fast", while sound princi-pals in wide purpose application development, does not always apply in the same sensewhen working in domain speci�c environments and languages. When working with data-analysis in MATLAB a developer will, given a good understanding of the computa-tions performed, have a very good idea of where most of the processing time will bespent. Therefore, to learn and utilize the quirks of the language, and combine themwith comments on the related code sections will produce code that is, within reasonableconstraints, as maintainable as its sometimes substantially slower but more easily readcounterparts.

In special cases with large "black boxes", wide purpose frameworks or toolboxes, theprinciple should be employed to its fullest extent. An example of this is rendering graph-

21

3. METHOD

ics, where performance depends heavily on platform, OpenGL hardware accelerationsupport, and MATLAB version.

Finally, it should be noted that there are instances where the versatility of MATLABis the largest culprit in terms of performance. Simply implementing a function in alower level, i.e. earlier generation, language can in these situations improve executionspeed many times over. The prime example of this in DAQS is the resample routine(sinresample). Though not quite a literal translation from MATLAB to C, only minortweaks were applied resulting in a 20x speed up, as seen in �gure 5.2a.

3.5 MATLAB GUI programming

Even with the undocumented Java component constructors described in section 3.1.1 theMATLAB GUI programming API is somewhat rudimentary compared to other frame-works. Its GUI development environment GUIDE does not support automated individualcomponent resizing and the default setting for new �gures is �xed size. Over all Math-Works leaves a lion share of the work required to create a rich user experience (UX) tothe programmer.

3.5.1 GUI layout management

Graphical toolkits normally support a few di�erent ways to manage the layout of controlswithin containers. The bare minimum is horizontal and vertical stacking, also referredto as packing, shown in �g 3.1. MATLAB is one of the very few exceptions to thisand does not o�cially supply any layout management except for parent-child relationsbetween controls together with absolute and normalized units of measurement. Withnormalized units a control's size and position relative the lower left corner of its parentare given as a fraction of its parent's size, with absolute they are given in number ofpixels, points5 or characters. The two main problems with missing layout managementare that the complexity of programmatic construction of dynamic GUIs and GUI scalingi.e. parent window resizing, increase. The former is a quite obvious problem, the latterstems from the fact most layouts, including that of DAQS, contains a mix of statically(absolute units) sized controls like buttons and dynamically (normalized units) sized oneslike axes.

There are undocumented functions that supply layout management described byamongst others in [14], very similar to that of AWT and Spring. With them layoutssuch as the one shown in �g 3.1, with sane scaling rules are easily obtained. Thoughold they are only sparsely used in toolboxes, often with comments detailing a need forrefactoring, and while that alone should not be used directly as a metric on how likelya function is to change or be removed, it is one of the very few ways available to get anindication of it.

51 point is equal to 1/72 inch or about 1/28.35 cm, both of which are valid units.

22

3. METHOD

Vertical stackingHorizontal stacking

Figure 3.1: Layout management by stacking, dashed boxes represent controls being added.

3.5.2 GUI back end versions

The major revision of the aforementioned internal functionality and structure responsi-ble for rendering graphical components, abstracting the Java toolkits and supplying theMATLAB GUI API was in R2014b o�cially updated. The new version, named HG2,has been in development and has shipped with (but been inactive by default) MATLABsince at least 2007 as reported by Yair Altman6. It introduces major changes both aes-thetically and implementationally, the latter documented in [15]. Though most of thechanges are introduced with backward compatibility the move from numeric to objecthandles has introduced a number of situations where common GUI-element constructionroutines are no longer functional, leading to the safest course of action for cross-versioncompatibility being to implement wrappers for the ui-family of functions as shown inlisting 3.6. Another change that needs to be taken into account when using the undoc-umented Java constructors is that the default settings for the JavaFrame has changed,making it opaque (as opposed to transparent in earlier versions).

Listing 3.6: HG2 mitigation% ui-wrapper for uicontrolfunction ctrl = uiControl(varargin)

ctrl = uicontrol(varargin{:});if(isnumeric(ctrl))

ctrl = handle(ctrl);end

end

The most notable addition in HG2 used in DAQS is the native tab panels, these haveexisted as undocumented functions for several years but have been quite buggy.

6He reported the discovery without any further details in the following discussion:http://www.mathworks.com/matlabcentral/newsreader/view_thread/154510#387811 (accessed2014-11-09).

23

3. METHOD

3.6 Data visualization

Despite MATLAB's CoW scheme when dealing with function arguments, all its data-visualization functions create a copy of the data sent to them (this is true for the case ofsetting YDataSource of a lineseries handle as well, as can be seen byedit([matlabroot ’/toolbox/matlab/graphics/refreshdata.m’]) ), andan equally sized dataset for cases when only one argument is given, before renderingit.7 Coupled with the sophisticated rendering techniques used, this leads to a steeplylinear relationship between N and rendering time. In cases where the size of the datasetis within one magnitude of the available RAM the copying itself could lead to instabilitieson the less robust operating systems supported by MATLAB. The apparent reasons forthis are primarily to facilitate on demand displaying of subsets of the data, i.e. zooming,and increased subpixel rendering accuracy.

The amount of data that can be accurately visually represented is limited by theamount of pixels it is displayed on. Using the default settings a plot-call with a singlevector as argument visualizes the data as a 2D line graph on an 434x342 px area. In aline graph with the independent variable on the horizontal axis a maximum of two datapoints, the min- and maximum values of contiguous subsets of size s = N

nwpx

where nwpx isthe width of the area in pixels, can be visualized in every pixel column. Consequentially,every dataset larger than 868 elements is reduced. Using the scatter plot function thetheoretical upper limit would be 434 · 342 elements. This would however require theability to uniquely di�erentiate every pixel in the area, a feature screen manufacturersare actively working towards making impossible for the naked eye.

To mitigate the performance implications of large data set-copying DAQS includesa plot-wrapper utilizing C-style pointers to reduce the amount of data copied to s.While the entire set still needs to be analyzed, tweaked plot-settings and the reducedRAM-I/O makes the wrapper a near real-time data visualizer.

7The situation has improved with HG2, though copies are still made.

24

4. IMPLEMENTATION

4 Implementation

DAQS is, while UI-wise inspired by the old implementation, a complete rewrite of theprevious system in MATLAB. As indicated by previous sections a few mex-�les havebeen written in C. These were however designed to, without sacri�cing too much perfor-mance, be as generic in nature as possible. To facilitate easy maintenance and furtherdevelopment, every function and class, including the mex-�les, have been documented inaccordance with the common practice of MATLAB documentation. The comments, as ishow MATLAB documentation is produced, have not been exported to any stand-aloneformat. Due to the lack of support of open, third party tools, e.g. Doxygen, they havenot been formatted for any special export format either.8 Instead a handbook-style Notesfor developers document [3], has been written.

4.1 Previous system

The previous system was implemented using 32-bit LabVIEW and both MATLAB andMathScript. The major, structural drawback of this combination is the 4GB memory capintroduced by 32-bit address space that in combination with the fact that data sent toand from MATLAB is always passed by value can cripple performance when working withlarge data sets. The LabVIEW visual programming language, G, is a data�ow language,a paradigm where the execution of a program is modelled as one or more directed graphswhere data �ows between the nodes with the underlying run-loop completely hiddenfrom the programmer. Nodes can always be represented visually as at least one input oroutput is required.

The �rst stage of execution in the LabVIEW implementation is committing the rele-vant con�guration parameters to the PCI-5922 (DAC), which need to be entered in theGUI before execution starts. Thereafter follows in forced sequential order, as timingon separate branches due to LabVIEW's transparent parallelization is unde�ned, dataacquisition, and saving and visualization. The data�ow is illustrated without some ofthe governing logic by the graphs in �gure 4.1 where rectangles indicate data operationsand rhombi data sources and sinks.

In G, as in most data�ow-based languages, execution is started by data being avail-able, hence the lower graph will simply wait for data to become available i.e. when the�rst acquisition is completed. The issues of data concurrency and timing of simultaneous�le writes following loop (a) and (b) in �gure 4.1 running in parallel are solved inter-nally by LabVIEW. The former, as local variables are used (though it is discouragedby LabVIEW documentation [16]), by simply creating an atomic copy of the data onevery read. The latter by either serializing the writes or for certain �le types by usingan asynchronous �le I/O API, however unless manually implemented the I/O-operationperformance will in most cases su�er.To elaborate on �gure 4.1, after starting the program and the Con�gure DAC node hasbeen passed, it enters an idle state before running loop (a). Loop (a) and consequently

8Though such alternatives exist, most notably m2html, they do not require any special syntax.

25

4. IMPLEMENTATION

Userinput

Con�gureDAC

Acquiredata

Localvariable

Writeto disk

Display

?

(a)

Localvariable

Resample

Writeto disk

FFT Display

Writeto disk?

?

? ?

(b)

Figure 4.1: Previous, LabVIEW based system graph with data acquisition loop in (a) and analysis in(b). Question marks indicate conditional execution and orange nodes operations executed in MATLAB.

(b) are then started by pulling a virtual lever. Once that is done the program runs untilstopped by the user after which �le I/O is �nalized and it exits. Should an error occurduring runtime the execution is interrupted and the �nal state is unde�ned.

4.2 New system - DAQS

DAQS, as noted earlier, is implemented in MATLAB and C (as mex-�les), both textbased and at least super�cially procedural languages. Followingly its source carries vir-tually no similarities with that of the old implementation.A key focus in development has been to structurally avoid performance-wise costly op-erations, sacri�cing a few common practices in the process. At the heart of this strategylays the knowledge that the primary data length, N , is large. An initial task was thusto identify the number of data sets of size kN needed, their lifetime and functions ofcomputational complexity ≥ O(n). All of this can be found in �gure 4.1; the initial setof size N , that acquired from the DAC, should live no longer than

tdac = max(tdacwrite, t

dacdisplay, tresample

)(22)

where tdacwrite is the time it takes to write it to disk, tdacdisplay to display it, and tresample toresample it. Similarly

26

4. IMPLEMENTATION

tresample = max(tresamplewrite , tFFT

), (23)

tFFT = max(tFFTwrite, t

FFTdisplay

). (24)

Even though the resample functions complexity is O(n) and the fast Fourier transformsO (n log (n)) as they both operate in-RAM their combined execution time adds up to lessthan a single disk-bound, O(n) complex twrite. Adding to this that while the acquisition,and resampling and FFT can be executed in parallel the data sets needs to be storedsequentially on disk making the combined

ttotwrite =∑i

tiwrite (25)

the main time issue and therefore where a caching scheme is needed. While parallelizationof the writes would be possible using separate temporary �les, meta-information, andconcatenation on closing, in the present setup with non-raid, HDD based storage media,it would improve performance moderately at best. This amounts to the approximationtdac = ttotwrite.

To separate the logic of caching �le writes from the acquisition and analysis it isimplemented as a thin wrapper class of the regular �le I/O functions utilizing a �rstin, �rst out (FIFO) bu�er and making them non-blocking to the caller. That way thecondition for caching, tdac < ∆t(a), where ∆t(a) is the time of one iteration of theacquisition loop, is ful�lled without ever being explicitly tested. The logical module-structure of DAQS is depicted in �gure 4.2, the corresponding implementational detailsare covered in section 4.2.2.

LauncherRuntime

environment

GUI Back endData

acquisition

GUI buildersData

analysisFile I/O

InstrumentI/O

Figure 4.2: Logical structure of the new system, arrows indicate any type of data transfer except errorcodes. Instruments include all equipment associated with the experimental setup. Blue backgroundsindicate one-shot execution, i.e. functions that are only ever called once.

As seen above the Back end sits very much at the center of operations of DAQS.Together with the File I/O node they are the only logical modules who have directimplementational counterparts. The daqs_backend-object is created following successfulGUI-creation. Not depicted in �gure 4.2 is the one-shot initialization of the Back end, it

27

4. IMPLEMENTATION

connects to the GUI by setting up callback chains in which it places its own methods last.Before entering the internal run-loop, i.e. its idle state, it also reads the default DACcon�guration, preallocates bu�ers in accordance with it, and commits it to the DAC.

4.2.1 GUI

Due to the overhead and restrictions introduced by GUIDE it has not been used butthe GUI is built programmatically leading to about 15% of the source code, in terms oflines of code (SLOC), being strictly GUI-related. Though by nature task speci�c, eachpane in the GUI, with the exception of the DAC con�guration which due to the design ofMATLAB's Instrument Control Toolbox requires a device object, is self contained. Theset up consists of the Launcher performing dependency-checks, creating the main window,setting up a tab-control and passing the individual panels as parents to the di�erent pane-constructors (the GUI builders). The panes assume that their dependencies, as listedin the documentation, are available. Should they not be, the construction will throwexceptions and the �nal state is unde�ned.Resizing rules, i.e. scaling and movement relative sibling and parent controls, are notimplemented but prepared for. Pane-constructors return structures similar to those fromGUIDE. Ordered in a parent-child tree, they contain all the controls that should bemoved and/or resized on a parent resize event.

4.2.2 Usage and structure

Post-initialization and GUI-construction, when the run-loop is entered, there are twomain courses of action expected by the user. The initial pane presents a set of DAC-con�guration options, during initialization the default pro�le of options has been ap-plied, and if content with these the user can simply move on to the data acquisitionpane. Otherwise a new set of options can be applied and optionally saved, if applied thecon�guration is immediately committed to the DAC, the acquisition bu�ers are updated,and the run-loop is then reentered.

When an acquisition session is started a session-bound environment is set up beforeentering the acquisition loop. This entails setting up a motor controller for the retarder,associating the current bu�ers with the screen2s, con�guring the DAC for acquisition,and starting the retarder motor. The loop itself is designed for speed, only performingthe minimum set of operations needed with the selected data analysis options. DAQS'sacquisition loop structure di�ers from that of the old system, in terms of �gure 4.1, Re-sample, FFT and Display are all still conditionally executed but inside the acquisitionloop, hence there is never a need for a copy of the acquired data to be made. Bothdata write-nodes are however moved to a separate thread, or loop in the �gure, in whichconditional caching is performed, thereby a copy of the data sent to be written is onlycreated if the write can not be performed immediately. Bu�ers for the results of resam-pling and FFTing are allocated on demand. Further, when the loop is terminated bythe user, DAQS reenters its idle state giving the user the option to restart acquisitionwithout having to restart the program.

28

4. IMPLEMENTATION

4.2.3 HITRAN

User

HITRANMySQL DB

Wrapperclass

GUI

Figure 4.3: HITRAN DB implementationstructure.

DAQS includes a basic HITRAN-interface that wasinitially designed to only generate a reference ab-sorption spectrum based on the settings used dur-ing acquisition, but got extended to support generalpurpose usage with a focus on transmission line ex-ploration and selection. It is much less a full-�edgedinterface than a front-end to the database with anabsorption-spectrum generator. For ease of use, aspectrum similar to that produced by the FFT dur-ing acquisition can be generated from its meta data,this is performed by the algorithm described in sec-tion 2.4.5. The generator supports both GPU- andlocal pool-parallelization and resides in what is in �gure 4.3 referred to as the wrapperclass. All the nodes have implementational counterparts and are, as depicted, designedwith user-centric interfaces.

4.2.4 MATLAB functionality extensions

Due to the properties of fourth generation programming languages and certain limita-tions in MATLAB speci�cally, a small number of performance centric extensions to thelanguage and its functionality have been added.

C-style pointersMATLAB's inferred by reference/value passing of arguments makes using data referencesinstead of copying the values in certain situations, e.g. when setting a property of a class,not possible. Explicit references, or pointers, were implemented primarily as the basisfor screen2 but are also key to the multi-threaded �le I/O.

Screen-style data visualizationThe built in data visualization functions of MATLAB are all extremely powerful in termsof functionality though, as described in section 3.6, not nearly so in terms of speed. As analternative, screen2 provides a way to visualize streaming data modelled after the screenof an oscilloscope. Instead of the descriptive plotting style axes the axes in screen2 aredesigned to, from a user perspective, act as a mechanism of control. Designed for adi�erent purpose, it does not replace e.g. plot but is rather a strict addition to facilitatecontinuous data visualization.

MySQL-interfaceTo minimize access time but maintain and even increase accessibility, the HITRAN ASCIItext-based database has been converted to a MySQL-database. Even though MATLAB'sDatabase Toolbox supports MySQL there are some issues; the cross platform supported

29

4. IMPLEMENTATION

JDBC drivers are unacceptably slow, the native ODBC-drivers o�er better but still vary-ing performance, both APIs, due to their generic nature, require non-trivial code fortrivial MySQL-operations, and the toolbox itself is not included in the standard versionof MATLAB but has to be bought separately.The mysql_*-family of functions supplies a comparatively well performing and easy touse MySQL-interface modelled after the highly popular scripting language PHPs imple-mentation, though with a small feature set.

4.3 Comparison

As DAQS is a complete rewrite of the original implementation using a a di�erent languagethere are, as described above, some di�erences in functionality. Hence the strengths andweaknesses in a comparison somewhat depends on the user's needs and requirements.The most prominent features that have not been included in DAQS and the reasons forthat are

• Drag-and-drop based GUI manipulationThis design feature of LabVIEW does not exist in MATLAB and its replicationwas deemed too time consuming.

• Inherent CPU-parallelizationThis is made possible primarily by the data�ow paradigm and while DAQS ismultithreaded, MATLAB is a procedural language. It should be noted that evenwithout explicit parallelization MATLAB does distribute computations over severalcores as exempli�ed by listing 3.5.

• Native PCI-5922 supportWith both LabVIEW and the PCI-5922 being products of NI the former supportsevery feature of the latter natively. NI does however not supply drivers for it toMATLAB, instead an interchangeable virtual instrument (IVI) driver is used.

Conversely DAQS introduces new, as well as improved features of the previous imple-mentation

• Speed upsThe primary purpose of real-time data acquisition and basic analysis relies heavilyon execution speed. The core functionality of the analysis, resampling and FFT,have in DAQS been signi�cantly optimized.

• ModularityHigh cohesion and self-containment have been the important design goals com-promised only when countering the primary goals of execution speed and memoryconsumption. As a result, large parts of the codebase can be directly used infollowing analysis or separate projects.

• DocumentationMATLAB allows formatted documentation to be included in source code, a featurewhich have been thoroughly utilized and incorporated in the GUI.

30

4. IMPLEMENTATION

• Cross-platform supportMATLAB provides full support on all three major platforms, Windows, Mac OSX, and Linux, for the toolboxes utilized in DAQS, the LabVIEW code is Windowsexclusive.

• Common languageAs MATLAB, at least within the �eld of physics, has become the de facto standardfor numerical computing the maintainability of projects implemented in it is high.

31

5. RESULTS

5 Results

5.1 Primary objectives

The purely functional objectives - con�guration, acquisition, saving, and motor controlwere all implemented though without further description needed than that given in theprevious sections.The following subsections outline the results in terms of relative improvements and newfeatures. To put these in the context given primarily by the theory section, �gures 5.1athrough c depict the key data sets relevant to DAQS.

Samples ×1060 2 4 6 8 10 12 14 16 18

I [V

]

0

0.05

0.1

0.15

0.2

0.25HeNe interferogram

(a) HeNe interferogram.

Samples ×1060 2 4 6 8 10 12 14 16 18

I [V

]

-5

-4

-3

-2

-1

0

1

2

3

4

5OFC interferogram

(b) Resampled OFC interferogram.

A(ν)I(t)

(c) Single peak of resampled OFC interferogram and reduced FFT result.

Figure 5.1: (a) and (b) depict the steps in �gure 2.4 with experimental data. In (c) a single peakinterferogram and absorption spectrum (FFT) is shown.

32

5. RESULTS

The main goal of the analysis was to be faster than the old one, therefore the resultsare presented in terms of relative performance. For stability comparisons two data sets arecompared in each step, one with experimental data and one with an OFC interferogram tointerpolate but random data as calibration signal (HeNe interferogram). To measure howwell the implementation scales with N it is fed concatenated copies, given as multiplesin �gure 5.2a and 5.2b, of the same dataset. The experimental OFC- and correspondingzero-mean calibration interferogram, shown in �gure 5.1a and b, contained 18.5 · 106

samples, the latter with 8955390 zero crossings. The size of the random calibrationsignal was 17.9 · 106 and with just over 9 · 106 crossings. To avoid performance boosts bycaching, values were cleared and reread from disk between each run.

All results were obtained using MATLAB 8.4.0.150421 (R2014b) running in a 64-bitversion of Windows 7 powered by an 3.4GHz Intel i5-4670 processor and 8 GB of 1600MHz DDR3 RAM. Results on other versions of MATLAB may vary slightly althoughthe relative improvements should be consistent on any x86-based hardware-con�guration.The absolute numbers however will scale linearly with computation power.9

5.1.1 Resampling

Two versions of the resampling algorithm, as described in section 2.2, were implemented.The �rst one producing, with nε accuracy, where n is an integer less than 10 and ε = 2−52

machine epsilon, the same results as the original. The small di�erences in the results,occurring with a frequency of about 1 in every 106 samples, are not related to changesin the algebraic structure but rather that the new back end was implemented in C.MATLAB, in which the old version was implemented, does in some instances whenevaluating double-precision expressions ignore the least signi�cant bit in intermediateresults.10 Thus, the deviations in the new C version are in theory towards a more preciserepresentation of the true values.

The implementation of the slightly modi�ed resampling algorithm designed to in-crease extreme value detection accuracy is, as described in section 2.2 and seen in �gure5.2a, also tuned to perform well on well formatted input, sacri�cing some worst caseperformance. The main di�erence between it and the original algorithm is step 6, wherethe original one de�ned k := ddxe. The change introduces a decreased rescaling size ofan average of 8% on experimentally obtained data.

Both algorithms implementations employ factor growth, also known as dynamic allo-cation routines of complexity O (N log (N)) which results in identical memory consump-tion, hence only one test case is given in �gure 5.2b. In it the minimum possible usage iscalculated based on the size of the returned vector, this corresponds to a perfectly cen-tered peak in the OFC interferogram and a requested output-size equal to the numberof points in the result. In practice, this value is about 1.5-2 times as large.

9Computation power measured in �oating-point operations per second (FLOPS), which is not neces-sarily related to clock-frequency and/or number of cores.

10The circumstances under which this occurs was, after ensured to be the sole cause of the deviations,not further investigated.

33

5. RESULTS

Multiples of dataset1 2 3 4

t DA

QS /

t old

0.05

0.06

0.07

0.08

0.09

0.1

0.11Resampling, execution time

RandomExperimentalNew, randomNew, experimental

(a) Execution time of resampling.

Multiples of dataset1 2 3 4

mem

DA

QS /

mem

old

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45Resampling, memory usage

RandomMin possible, randExperimentalMin possible, exp

(b) Memory usage of resampling.

Figure 5.2: Execution time and memory usage of DAQS resample implementation in terms of thereference (old) implementation.

The factor growth routine's performance depends heavily on how well the size isinitially estimated. As the estimation is based on DAC-settings and properties of theHeNe-laser the comparatively bad performance on random data is expected. This is thee�ect of multiple reallocations and can be seen by comparing experimentally obtainedcalibration data (dashed lines) and its random counterpart (dotted lines) in �gure 5.2a.Memory usage wise the reallocations have little e�ect as shown by �gure 5.2b. In absoluteterms, the throughput on the platform described in the parent section stays steadily above108 double-precision samples per second given experimentally obtained input, for bothalgorithms.

5.1.2 FFT

Due to logic restructuring, the need for a custom FFT implementation has been com-pletely removed. It is still performed, but instead of calculating the absolute value ofthe entire generated spectrum only the subset currently being displayed is used. Thex-scale value generation, i.e. the set of wavenumbers the spectrum spans, of complex-ity O (N) is replaced with screen2s constant time XTickTransformFcn, which, as thename suggests, only rescales the values displayed as text below the x-axis. The per-formance increase is thus situation bound, but is, in a theoretical worst case scenario15%.

5.2 Secondary objectives

As with the primary objectives, both con�guration pro�les and maintainability goalswere realized, the �rst as documented in section 4.2 and the second, separately in [3] and

34

5. RESULTS

appendix D. Due to problems with the IVI driver, two way acquisition has not yet beenimplemented, though the analysis speed ups provide the time needed.

5.2.1 HITRAN interface

As demonstrated in the theory section, the HITRAN-implementation does not take anysetup-speci�c input into account. The governing principal for it was to be a tool thatcould be used in post-acquisition analysis and more general settings, which is why thevan Vleck-Weisskopf lineshape function was included as it is primarily used in astrophys-ical applications. This is also why sample length and temperature are taken as inputparameters, and does mean the output needs to be adjusted to �t most applications, aninconvenience considered less than that of getting tailored output only applicable to acertain setup.

5.3 End product

A key component in DAQS is the screen2 class. As noted in previous sections, MAT-LAB's rendering back end is simply not designed for real-time data visualization, a factmade obvious in �gures 5.3a and (b) where MATLAB's plot-function is compared withscreen2. In them the two surface-sizes, on which the data is plotted, corresponds to thedefault window-size of a new �gure and one which �lls a full HD (1920x1080 px) screen.

Set size ×1071 2 3 4 5 6 7 8

t scre

en2 /

t plot

0.008

0.01

0.012

0.014

0.016

0.018

0.02

0.022

0.024

0.026

0.028Data visualization, rendering time

434x342 px surface1482x913 px surface

(a) Rendering times of screen2.

Set size ×1071 2 3 4 5 6 7 8

mem

scre

en2 /

mem

plot

×10-4

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8Data visualization, memory usage

434x342 px surface1482x913 px surface

(b) Memory usage of screen2

Figure 5.3: To screen rendering (and scan out) time and memory usage of screen2 in terms of MAT-LAB's plot command.

Much like with the resampling implementation, the absolute rendering time is crucialto accommodate two way acquisition. The largest set size above is close to twice thatof what the current experimental setup produces per sweep, 71.6 · 106 versus 36 · 106

samples, and was rendered in 0.0671 s and 0.0853 s on the smaller and larger surface.More importantly, it scales well with N , the smallest set size of 17.9 · 106 samples was

35

5. RESULTS

rendered in 0.0306 s and 0.0459 s respectively. Further testing con�rmed the theoretical,linear relationship between rendering time and set size.

As described in section 3.6 screen2's memory consumption is independent of N andsince plot's is not the ratio in �gure 5.3b will simply head towards zero as N grows. Fi-nally, DAQS includes a few features not mentioned earlier that improve on the conceptsof the old implementation. The DAC-con�guration utility o�ers a more �nely grainedcontrol of the settings which all come with built in documentation. To ensure backwardcompatibility the data �le produced by DAQS retains the format of the old implemen-tation. It does however also produce a meta data �le usable, as mentioned earlier, withthe HITRAN-implementation as well as being an easily expandable MATLAB-struct.As noted in previous sections maintainability and high cohesion have been importantparts, the reason for the �rst is quite obvious. As for the latter, while contributing tothe former, a second, and hopefully just as important aspect, is that many of the func-tions can easily be moved to other projects with similar needs. The core functionality ofresampling, MySQL-interaction, and data-acquisition are all implemented in C, makingthem easy to adapt to even non MATLAB based projects.

36

6. DISCUSSION

6 Discussion

While most of the goals set up for DAQS were ful�lled, reimplementing a componentin use always carries a sense of uncertainty with it. Added functionality and changes inthe layout-structure can easily break the work�ow of long running users. The small userbase of a single research group have mitigated this concern to a certain extent, as mostof the layout has been developed in collaboration with them. However the late, and inretrospect not quite satisfactory, testing has kept it alive.Another concern is the lack of LabVIEW's easily extensible GUI, in an experimentalenvironment it is arguably one of its most valuable functions. Trying to replace it withmodular code and to some extent the meta data �le, work in terms of simply extending thecurrent functionality but do little to accommodate radically new ideas into the work�ow.

6.1 HITRAN

The HITRAN database can, with its exhaustive amounts of data, be an invaluable as-set in spectroscopic applications. To make its "full potential" conveniently accessiblethough, methods for easy access, selection, and sorting are needed. In the format it isdistributed none of these criteria are ful�lled. The tools available are also somewhatlacking in functionality, the Java HITRAN Atmospheric Workstation (HAWKS) o�erslittle in terms of interoperability with other software, the selection process is rather slowand hard to automate, and sorting options are few and static. There are online optionswhich match most of the criterion, o�er post-selection computation, and good exportingoptions such as spectralcalc.com and hitran.iao.ru. The fact that they are onlineservices, however, severely limits the options for reliable automation, as well as, in theformer case, being a paid service.

As it was a low priority secondary objective I arguably spent too much time imple-menting the functionality surrounding HITRAN. It was however a very good learningexperience, and has led me to start working on an open source library called "C interfaceto HITRAN" (libcith) designed for multipurpose HITRAN interaction. As in DAQS,HITRAN is �rst and foremost converted to a SQL database, for the library the publicdomain software SQLite has been chosen in favor of MySQL. The time needed for multi-criterion selection of transition lines from the entire database has, using an early versionof the library, been reduced from around 100 seconds in HAWKS to below a tenth of asecond.

With all of the HITRAN interaction isolated in its own classes in DAQS, movingfrom the current implementation to a libcith-based one should be quite straight forward.

6.2 Code optimization

As has been described several times earlier, execution time is key in many parts ofDAQS. A common course of action when dealing with computationally heavy and timecritical problems today is to add more powerful hardware rather than spending timeoptimizing code. This is a rather new approach to a problem as old as the computer itself.

37

6. DISCUSSION

In the early days of computing execution time was reduced by maximizing hardwareusage, not only CPUs, but also in-memory data alignment and representation. Manyof the more common methods for this was in 1957 assembled into the �rst revision ofthe programming language FORTRAN.11 It was at �rst met with a certain amount ofskepticism, as these more generic versions of optimized routines were by many expectedto add too much overhead and thus produce poorly performing machine code. Thereduced amount of programming statements required however led to wide adaptation,especially in scienti�c and other numerically intensive software. This, in turn, motivatedthe authors of compilers to write products whose main goal was to produce machine codethat outperformed competitors. By 1977 FORTRAN had been extended with most ofthe block-structures and loop-functionality available in today's languages, still with, byhand optimized assembly back ends.

Following the extreme success of the less computation-centric language C, which was�rst released in 1972 but really gained traction after the release of the informal speci-�cation The C Programming Language in 1978, and the rapid development of personalcomputers during the 1990s, the number of programmers in the world increased expo-nentially. The earlier ideals of producing high performance code got replaced by theiropposites, the metrics for "good code" became its readability, cohesion, hardware in-dependence, and even the performance of a function should now be measured by thecomplexity of its underlying algorithm (commonly using big O notation) rather thanhow much CPU-time it used given its expected input. As this attitude evolved andCPUs became increasingly powerful and complex, code optimization became viewed, inmost cases, as something negative. This is not rarely motivated by phrases such as "Aprogrammer's time is more valuable than a CPU's" or the, constantly taken out of con-text, quote from Donald Knuth "premature optimization is the root of all evil"12. Theproblems with this attitude in general purpose programming has been addressed in sev-eral contexts, but few as elegantly as by Randall Hyde, author of The Art of AssemblyLanguage and creator of the High Level Assembly (HLA) language, in [18]. In scien-ti�c computing one of the core tenant of optimization-opposition, i.e. "it is hard to knowwhere the CPU will spend most of its time", is simply false. In this context, given a goodunderstanding of the problem and programming language used the author of the codemust know where most CPU time will be spent. If not, one or both of the prerequisitesare lacking and the result produced should thus, in most cases, not be trusted.

Despite this modern day opposition to, what in my opinion is "good code", Math-Works Inc. have made the choice to keep their mex �le API, with native bindings toboth FORTRAN and C. This gives the user the option to invest time rather than moneyto improve execution time. The choice to use C for the mex �les in DAQS was primarilybased on the fact that, using some of the tricks learnt from FORTRAN, it produces fastenough functions.

11The language was formalized in 1956 but the �rst compilers did not appear until early 1957.12Taken from [17], in which he promotes one of the few concepts that is even more frowned upon than

"premature optimization", use of the goto-statement.

38

6. DISCUSSION

6.3 MATLAB

The mex API is arguably one of MATLAB's most usable features, and though quite afew of its quirks and shortcomings have been discussed in the method section I haveyet to touch on the e�ects of its other strengths in DAQS. In short, the implicit paral-lelization of vector algebra is really impressive, function documentation is comparativelywell implemented, and the object oriented programming (OOP) concepts have maturedwell over the few releases. Unfortunately, as mentioned earlier, data references have notyet been implemented meaning the strides towards a more pure OOP structure have insome, though few, instances increased the number of data copy-operations needed toperform a given task (with backwards compatibility). From an end user perspective thisseems odd as, given the data representation documented in section 3.1.2 and table C.1,a simple argument quali�er could cause e.g. plot to increase the refcount and createa crosslink entry instead of copying the entire data set, much like how the screen2class works. With documentation on how this would a�ect JIT performance and garbagecollection any user familiar with the concepts would be able to produce more e�cientcode.

Another feature in MATLAB that simply went unused in DAQS is GUIDE. Againthis choice was the result of what I believe to be quite strange shortcomings. The mostapparent and basic one would be the lack of a numeric input control. That is, thenumeric computing environment MATLAB is missing a native numeric input componentin its graphic user interface builder. The text input control, i.e. the natural parent of anumeric input control, in general is fairly rudimentary, o�ering few modern features suchas auto completion, spell-checking and syntax highlighting, all of which are commonplacein most other GUI frameworks.The small number of native components, while also a contributing factor, in my opinion isnot as big of a problem as the worst culprit, the lack of layout management (as discussedin section 3.5.1).

Finally, while large parts of this thesis work have been working around the short-comings of MATLAB this is more related to the nature of the project than a re�ectionof MATLAB itself. To say that it would have been less work to implement DAQS in alower level language may be overreaching as few, if any, languages o�er such a rich andconsistent interface to numerical computation libraries and built in functions as MAT-LAB. The work would, however, have been focused more on creating new functions thandeconstructing existing functionality and modifying it to �t the needs of this project.The, within its niche, overwhelming success of MATLAB makes it the go-to language formost problems, sometimes even for problems where other languages may be better suited.From a usability perspective, in many of the instances it falls short, it does so becauseof its strengths. The fact that it is expandable using mex-�les does widen its possibleapplications, but in the end it is an interpreted language and JIT, and other runtimeoptimizations can only take it so far. The trade o� for its versatility and �exibility isspeed and memory usage, the question is if you as the user are willing to make it.

39

REFERENCES

References

[1] Amir Khodabakhsh, Alexandra C Johansson, and Aleksandra Foltynowicz. �Noise-immune cavity-enhanced optical frequency comb spectroscopy: a sensitive tech-nique for high-resolution broadband molecular detection�. In: Applied Physics B119.1 (2015), pp. 87�96.

[2] Peter R Gri�ths and James A De Haseth. Fourier transform infrared spectrometry.2nd ed. Vol. 171. John Wiley & Sons, 2007. isbn: 978-0471194040.

[3] R Seton. �DAQS Developers Manual. Notes for developers and maintainers�. UmeåUniversity, Sweden, 2015-03.

[4] PW Milonni and JH Eberly. Laser Physics. Wiley, Hoboken, 2010. isbn: 978-0470409701.

[5] Claude E Shannon. �Communication in the presence of noise�. In: Proceedings ofthe IEEE 72.9 (1984), pp. 1192�1201.

[6] Laurence S Rothman et al. �The HITRAN molecular spectroscopic database andHAWKS (HITRAN Atmospheric Workstation): 1996 edition�. In: Journal of Quan-titative Spectroscopy and Radiative Transfer 60.5 (1998), pp. 665�710.

[7] RM Goody and YL Yung. Atmospheric Radiation. Theoretical Basis. 2nd ed. Ox-ford University Press, Oxford, 1989. isbn: 978-0195102918.

[8] Ellis E Whiting. �An empirical approximation to the Voigt pro�le�. In: Journal ofQuantitative Spectroscopy and Radiative Transfer 8.6 (1968), pp. 1379�1384.

[9] JJ Olivero and RL Longbothum. �Empirical �ts to the Voigt line width: a brief re-view�. In: Journal of Quantitative Spectroscopy and Radiative Transfer 17.2 (1977),pp. 233�236.

[10] JH Van Vleck and VF Weisskopf. �On the shape of collision-broadened lines�. In:Reviews of Modern Physics 17.2-3 (1945), pp. 227�236.

[11] Peter Boettcher. Peter's MATLAB Stu�. Massachusetts Institute of Technology.2003-07-14. url: http://www.mit.edu/~pwb/matlab/headerdump (visitedon 2014-10-18).

[12] Steve Eddins. Automatic array growth gets a lot faster in R2011a. The MathWorks,Inc. 2011-05-16. url: http://blogs.mathworks.com/steve/2011/05/16/automatic-array-growth-gets-a-lot-faster-in-r2011a (visitedon 2014-11-22).

[13] MATLAB Help. all. Technical documentation. Version 8.4.0.150421 (R2014b). TheMathWorks, Inc. Chap. Language Fundamentals. url: http://se.mathworks.com/help/matlab/ref/all.html.

[14] Yair Altman. Matlab layout managers: uicontainer and relatives. 2010-06-09. url:http://undocumentedmatlab.com/blog/matlab-layout-managers-uicontainer-and-relatives (visited on 2014-10-08).

40

REFERENCES

[15] Graphics Changes in R2014b. The MathWorks, Inc. 2014-10-03. url: http://se.mathworks.com/help/matlab/graphics-changes-in-r2014b.html(visited on 2015-10-20).

[16] LabVIEW Help. Technical documentation. Version 13.0f2 (2013). National Instru-ments Corporation. 2013-06. Chap. LabVIEW Style Checklist.

[17] Donald E Knuth. �Structured Programming with go to Statements�. In: ACM Com-puting Surveys (CSUR) 6.4 (1974), pp. 261�301.

[18] Randall Hyde. �The fallacy of premature optimization�. In: Ubiquity 2009.February(2009), p. 1.

41

Appendices

A Analytical interferogram derivations

The intensity of an electromagnetic wave is in vacuum given by

I = cε0 〈E(t)〉2 (26)

where c is the speed of light, ε0 the permittivity of free space, and E(t) the �eld itself.

A.1 Single frequency interferogram

The E-�eld of a single frequency light-source with f = c/λ, where λ is the wavelength,is described by

E(t) = E0 cos (2πft) = E0 cos (ωt) . (27)

Inserting this into equation 26, with⟨cos2 [x (t)]

⟩= 1

2 , the intensity of this �eld is givenby

I0 = cε0 (E0)2 1

2. (28)

The intensity of two interfering waves A and B with the same angular frequency ω, buta relative phase shift of ∆Φ is thus described by

IAB = cε0⟨EA0 cos (ωt+ ∆Φ/2) + EB0 cos (ωt−∆Φ/2)

⟩2= cε0

[⟨EA0 cos (ωt+ ∆Φ/2)

⟩2+⟨EB0 cos (ωt−∆Φ/2)

⟩2+⟨EA0 E

B0 2 cos (ωt+ ∆Φ/2) cos (ωt−∆Φ/2)

⟩ ]= IA + IB + cε0E

A0 E

B0 〈cos (2ωt) + cos (∆Φ)〉 . (29)

Given that the source of EA and EB is a perfect BS, as described in section 2.1, thesum of the individual amplitudes will be that of the beam incident on the BS, E0, i.e.EA0 = EB0 = 1

2E0. Inserting this into 29 yields

I0 = cε0

⟨1

2E0 cos (ωt+ ∆Φ/2) +

1

2E0 cos (ωt−∆Φ/2)

⟩2

= cε01

4〈E0 cos (ωt+ ∆Φ/2) + E0 cos (ωt−∆Φ/2)〉2

=1

4

[I0 + I0 + cε0 (E0)

2 〈cos (2ωt) + cos (∆Φ)〉]

=1

2I0 [1 + 〈cos (2ωt) + cos (∆Φ)〉] , (30)

42

A. ANALYTICAL INTERFEROGRAM DERIVATIONS

the resulting expression oscillates, as seen above, with the sum of the angular frequencyof the beams and changes in their relative phase shift. In laser-based spectroscopicapplications measurements of the oscillations will however only re�ect the change in thephase shift as ω is simply too high to be measured with any available DAC. The measuredintensity, over time, is thus

I (t) =1

2I0 [1 + cos (∆Φ (t))] . (31)

This is also derived in section 2.1, resulting in equation 10.

A.2 Multiple frequencies

An E-�eld from an OFC, i.e. a �eld comprised of multiple frequencies is, as given byequations 1 through 3, described by

E(t) =

N∑n

En cos (ωnt)

=

N∑n

En cos (2πνnt)

=

N∑n

En cos

[2πνn

(δφ

2π+ n

)t

](32)

While this sum can be inserted into equations 28 through 30, using the expression fora frequency, ωn, as described by equation 3 eliminates the need for it. To then includethe carrier envelope shift, ∆φ, in a "compound" center frequency, ωc, as described byequations 1, 2, and �gure 2.1, further reduces the number of terms. With a perfect BSand taking into account the doppler shift from the FTS retarder movement the two OFC�elds depicted in �gure 2.2a are hence described by

EA =1

2E0 cos

[(ωc + nωr) t+ (ωc + nωr)

2v

ct

](33a)

EB =1

2E0 cos

[(ωc + nωr) t− (ωc + nωr)

2v

ct

](33b)

where v is the speed of the retarder. The intensity oscillations of the interference of theabove two �elds, i.e. the equivalent of equation 30, follows in equation 34.

43

A. ANALYTICAL INTERFEROGRAM DERIVATIONS

In(t) = cε0 〈EA + EB〉2

= cε01

4

{⟨E0 cos

[(ωc + nωr) t+ (ωc + nωr)

2v

ct

]⟩2

+⟨E0 cos

[(ωc + nωr) t− (ωc + nωr)

2v

ct

]⟩2

+⟨2× E0 cos

[(ωc + nωr) t+ (ωc + nωr)

2v

ct

]×

E0 cos

[(ωc + nωr) t− (ωc + nωr)

2v

ct

]⟩}

= cε01

4

{1

2(E0)

2 +1

2(E0)

2 +

(E0)2

⟨cos [2 (ωc + nωr) t] + cos

[2 (ωc + nωr)

2v

ct

]⟩}=

1

2I0 +

1

2I0

⟨cos [2 (ωc + nωr) t] + cos

[(ωc + nωr)

4v

ct

]⟩=

1

2I0

{1 +

⟨cos [2 (ωc + nωr) t] + cos

[(ωc + nωr)

4v

ct

]⟩}(34)

Just as described for equation 31 the oscillations are thus be described by

In (t) =1

2I0

{1 + cos

[(ωc + nωr)

4v

ct

]}(35)

44

B. HITRAN DATA

B HITRAN data

Table B.1: Fields in HITRAN 160 character records

Field Description Unit

M Chronologically assigned molecule number 1I Isotopologue number ordered within terrestrial 1

abundance of moleculeν Vacuum wavenumber cm−1

S∗ Integrated molecular linestrength cm−1/(molecule·cm−2)A Einstein A-coe�cient s−1

γair∗ Air-broadened HWHM cm−1atm−1

γself∗ Self-broadened HWHM cm−1atm−1

E′′ Lower-state energy cm−1

nair∗∗ Temperature-dependence exponent for γair 1

δair∗ Air pressure-induced line shift cm−1atm−1

V ′ Upper-state "global" quanta molecule speci�cV ′′ Lower-state "global" quanta molecule speci�cQ′ Upper-state "local" quanta molecule speci�cQ′′ Lower-state "local" quanta molecule speci�cIerr Accuracy for parameters ν, S, γair, γself, nair, δair encodedIref Reference indices for ν, S, γair, γself, nair, δair encodedX Availability of program and data for the case of boolean

line mixingg′ Statistical weight of the upper state 1g′′ Statistical weight of the lower state 1

∗) Values given at standard 296 K∗∗) γair(T ) = γair(T0)× (T0/T )nair

45

B. HITRAN DATA

Table B.2: Molecules in HITRAN 2004

Number Formula Name Molar mass (g/mol)

1 H2O Water vapour 18.015362 CO2 Carbon dioxide 44.009953 O3 Ozone 47.99824 N2O Nitrous oxide 44.012845 CO Carbon monoxide 28.010556 CH4 Methane 16.043077 O2 Dioxygen 31.99888 NO Nitrogen oxide 30.006129 SO2 Sulfur dioxide 64.062810 NO2 Nitrogen dioxide 46.0055211 NH3 Ammonia 17.0306612 HNO3 Nitric acid 63.012913 OH Hydroxyl radical 17.0073814 HF Hydrogen �uoride 20.00638315 HCl Hydrogen chloride 36.4606816 HBr Hydrogen bromide 80.9119817 HI Hydrogen iodide 127.9123818 ClO Chlorine monoxide 51.452119 OCS Carbonyl sul�de 60.0745520 H2CO Formaldehyde 30.0265121 HOCl Hypochlorous acid 52.4600822 N2 Nitrogen 28.0134423 HCN Hydrogen cyanide 27.0258524 CH3Cl Chloromethane 50.4877925 H2O2 Hydrogen peroxide 34.0147626 C2H2 Acetylene 26.0382627 C2H6 Ethane 30.0701828 PH3 Phosphine 33.997729 COF2 Carbonyl �uoride 66.00735630 SF6 Sulfur hexa�uoride 146.05441831 H2S Hydrogen sul�de 34.0799632 HCOOH Formic acid 46.0259133 HO2 Hydroperoxyl radical 33.0067834 O Oxygen 15.999435 ClONO2 Chlorine nitrate 97.4576236 NO+ Nitrosonium ion 30.0061237 HOBr Hypobromous acid 96.9113838 C2H4 Ethylene 28.0542239 CH3OH Methanol 32.0424740 CH3Br Bromomethane 94.93909

Continues on next page

46

B. HITRAN DATA

Table B.2: Molecules in HITRAN 2004 (continued)

Number Formula Name Molar mass (g/mol)

41 CH3CN Acetonitrile 41.0529642 CF4 Carbon tetra�uoride 88.00476243 C4H2 Diacetylene 50.0605644 HC3N Cyanoacetylene 51.0481545 H2 Hydrogen, molecular 2.0159646 CS Carbon monosul�de 44.0751547 SO3 Sulfur trioxide 80.0622

47

C. MXARRAY AND LIBMX

C mxArray and libmx

TableC.1:mxA

rray

�eldsof

interest

Fieldname∗

Datatype

libmxFunctions

Description

name

char*

Not

available

Variablename,�rst

elem

entin

mxArray,i.e.o�setis

0in

(atleast)MATLABR2012athroughR2014b

class_id

int

mxG

etClassID

MATLABdatatype

ofvariable

crosslink

uint64_t

mxG

etLinkO

�set∗∗

Datasharinglistlink

refcount

uint64_t

mxG

etReferenceCount∗∗

Num

berof

references

tovariable,only

whenthisis

mxSetReferenceCount∗∗

zero

canthevariablebe

cleared

number_of_dims

int*

mxG

etDimensions

Num

berof

dimensionsin

data

matrix

mxSetDimensions

rowdim

size_t

mxG

etM

Num

berof

rowsin

data

matrix

mxSetM

coldim

size_t

mxG

etN

Num

berof

columns

indata

matrix

mxSetN

pdata

void*

mxG

etData

Actualdata

ofvariable

mxSetData

double*

mxG

etPr

mxSetPr

flags

uint64_t

mxG

etScopeO

�set∗∗

Flags

that

amongotherthings

containinform

ationon

uchar

mxIsG

lobalScope∗∗

variablescope

uchar

mxIsLocalScope∗∗

uchar

mxIsM

emberScope∗∗

uchar

mxIsTem

poraryScope∗∗

uchar

mxIsU

nknownScope∗∗

∗)

Asgiven

by[11]

∗∗)

Undocu

mented

48

D. FILES AND DESCRIPTIONS

D Files and descriptions

Though all production �les are documented, their context and a few test- and develop-ment �les may not always be. Following is a short description of each �le, and their pathand purpose. READMEs and TODOs are not listed as their purpose is clear.

Table D.1: Files of DAQS

Path Description

daqs.m User function, checks environment variables andcalls launcher

daqs_backend.m Main class of running instancedaqs_conf.m Con�guration script, see [3]daqs_fft.m DAQS speci�c FFT implementationdaqs_launcher.m Launcher that connects GUI and back end and

then hands over control to the latterdaqs_resample.m Resample implementationfileio.m File I/O wrapper, see [3]motorcontroller.m Motor controller for the retarderdevtools/ Tools for development and testingdac_test.m Test script for DAC-con�guration and acquisitiondaqs_evaluator.m Benchmarker for DAQS data analysis and

visualizationdumpargs.m Utility scriptloadbin.m readfile -style wrapper for acquisition datapng2mat.m Converts PNG-images to MAT-�lesprofile_fft.m FFT benchmarker and pro�lerprofile_resample.m Resample benchmarker and pro�lerreveng/ Utilities for reverse engineering mxArray and

libmx

tc.m Generic test class for evaluating MATLAB OOPfunctionality

tester.m Generic test functions for evaluation MATLAB'sfunction argument passing

gui/ The GUI and its dependenciesbencher.m Benchmarker for screen2daqs_gui.m GUI builderscreen2.m screen2, see [3]uiConfigPanel.m Con�guration panel builderuiCtrl.m uicontrol wrapper with HG2-�xuiDaqPanel.m Data acquisition panel builderuiDaqSaveDialog.m Data save dialogueuiDaqsSplash.m Wrapper for Java-class

Continues on next page

49

D. FILES AND DESCRIPTIONS

Table D.1: Files of DAQS (continued)

Path Description

uiedit.m uicontrol(’Style’, ’edit’) replacementuiHitranPanel.m HITRAN panel builderuiHtmlLabel.m uicontrol(’Style’, ’text’) replacement with

HTML functionalityuiLabel.m uicontrol(’Style’, ’text’) replacement with

extended functionalityuiPostProcessingPanel.m Post processing panel builderdeps/ GUI dependency root pathhelp/ Panel-speci�c help documentationimg/ Image root path for GUIjava/ Java classessrc/ Java sourcesbuild.sh Build script for Java-classesDaqsSplash.java Splash screen classMonitor.java Alternative implementation of screen2

hitran/ HITRAN interface rootbuildhitrandb2.m Converts HITRAN ASCII-based database to

MySQL-tablesdatamanipulationquery.m Database Toolbox JDBC-driver extension for data

manipulation querieshitran.sql HITRAN-table SQL-query patternhitranevent.m Event class for hitranmoleculehitranmolecule.m High level HITRAN MySQL database interfacehitran_autocomplete.m uiedit auto-completion function, for HITRAN

molecule formulae and nameshitran_meta.sql HITRAN meta information table SQL query

patternhitran_molecule_weigh... Molar mass calculator for HITRAN-like moleculeshitran_moln.sql HITRAN-molecule table SQL query patternhitran_spectrum.m Absorption spectrum generator for HITRANmol_nums.sql HITRAN-molecule meta information table SQL-

query patternreshapehitran.m Script for splitting HITRAN tables containing all

molecules into individual molecule tablesupdatemol_numvalues.m SQL insert and update HITRAN molecule query

wrapperjava/ HITRAN-related Java classesClassTester.java Individual Java-class testerHitranQueryTable.java Spreadsheet-style query builder for HITRANllipcshm.java IPC implementation using shared memory

Continues on next page

50

D. FILES AND DESCRIPTIONS

Table D.1: Files of DAQS (continued)

Path Description

llipcsocket.java IPC implementation using Java socketsParforProgressBar.java Progressbar Java-class for MATLAB parfor

using IPCexample/ Java examples related to uiHitranPanel

mex/ mex root pathdaqs_build_all_mex.m Script that builds all mex-�les (excluding

mysql_*)datafromptr.c Fetch data from pointer functiondatafromptr.m Documentation for datafromptrdatalistlength.c Length of linked list (crosslink) used internally

by MATLABdatalistlength.m Documentation for datalistlengthdataptr.c Fetch pointer to mxArray of argumentdataptr.m Documentation for dataptrdatasizeptr.c Fetch size of data pointed to by argument,

equivalent to MATLAB's size functiondatasizeptr.m Documentation for datasizeptrmatlabutils.h Common macros and function for all mex �lessinresample.c Resample function, see section 2.2sinresample.m Documentation for sinresamplestrinca.c Fetches index of string in cell arraystrinca.m Documentation for strincatm.c Generic mex-�le testerc-mysql/ MySQL-interface root pathmextest.c MySQL C-library functionality testermysql_backup_db.m MySQL database backup scriptmysql_close.c MySQL close connection functionmysql_commons.h Common macros and functions for all mysql_*

functionsmysql_create_db.c MySQL database creator functionmysql_insert_id.c Function to fetch last automatically generated idmysql_open.c MySQL open connection functionmysql_open.m Documentation for mysql_openmysql_query.c MySQL query functionmysql_query.m Documentation for mysql_query

NI/ National Instruments related �lesmatlabPCI5922.mdd Con�guration �le for DAC IVI drivermyNI5922.mdd Con�guration �le for DAC simulator driverhelp/ Documentation and related �les for NI-related

functionalityContinues on next page

51

D. FILES AND DESCRIPTIONS

Table D.1: Files of DAQS (continued)

Path Description

refs/ Documentation and references for MATLABfunctionality and HITRAN theory

52