UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS F´ISICAS Y MATEMATICAS´ DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION´

FADRA: A CPU-GPU FRAMEWORK FOR ASTRONOMICAL DATA REDUCTION AND ANALYSIS

TESIS PARA OPTAR AL GRADO DE MAG´ISTER EN CIENCIAS, MENCION´ COMPUTACION´

FRANCISCA ANDREA CONCHA RAM´IREZ

PROFESOR GU´IA: MAR´IA CECILIA RIVARA ZU´NIGA˜ PROFESOR CO-GU´IA: PATRICIO ROJO RUBKE

MIEMBROS DE LA COMISION:´ ALEXANDRE BERGEL JOHAN FABRY GONZALO ACUNA˜ LEIVA

Este trabajo ha sido parcialmente financiado por Proyecto FONDECYT 1120299

SANTIAGO DE CHILE 2016 Resumen

Esta tesis establece las bases de FADRA: Framework for Astronomical Data Reduction and Analysis. El framework FADRA fue dise˜nadopara ser eficiente, simple de usar, modular, expandible, y open source. Hoy en d´ıa,la astronom´ıaes inseparable de la computaci´on,pero algunos de los software m´asusados en la actualidad fueron desarrollados tres d´ecadasatr´asy no est´andise˜nadospara enfrentar los actuales paradigmas de big data. El mundo del software astron´omicodebe evolucionar no solo hacia pr´acticasque comprendan y adopten la era del big data, sino tambi´enque est´enenfocadas en el trabajo colaborativo de la comunidad.

El trabajo desarollado consisti´oen el dise˜no e implementaci´onde los algoritmos b´asicos para el an´alisisde datos astron´omicos, dando inicio al desarrollo del framework. Esto con- sider´ola implementaci´onde estructuras de datos eficientes al trabajar con un gran n´umero de im´agenes,la implementaci´onde algoritmos para el proceso de calibraci´ono reducci´onde im´agenesastron´omicas,y el dise˜noy desarrollo de algoritmos para el c´alculode fotometr´ıay la obtenci´onde curvas de luz. Tanto los algoritmos de reducci´oncomo de obtenci´onde curvas de luz fueron implementados en versiones CPU y GPU. Para las implementaciones en GPU, se dise˜naronalgoritmos que minimizan la cantidad de datos a ser procesados de manera de reducir la transferencia de datos entre CPU y GPU, proceso lento que muchas veces eclipsa las ganancias en tiempo de ejecuci´onque se pueden obtener gracias a la paralelizaci´on. A pesar de que FADRA fue dise˜nadocon la idea de utilizar sus algoritmos dentro de scripts, un m´odulo wrapper para interactuar a trav´esde interfaces gr´aficastambi´enfue implementado.

Una de las principales metas de esta tesis consisti´oen la validaci´onde los resultados obtenidos con FADRA. Para esto, resultados de la reducci´ony curvas de luz fueron compara- dos con resultados de AstroPy, paquete de Python con distintas utilidades para astr´onomos. Los experimentos se realizaron sobre seis datasets de im´agenesastron´omicasreales. En el caso de reducci´onde im´agenesastron´omicas,el Normalized Root Mean Squared Error (NRMSE) fue utilizado como m´etricade similaridad entre las im´agenes. Para las curvas de luz, se prob´o que las formas de las curvas eran iguales a trav´esde la determinaci´onde offsets constantes entre los valores num´ericosde cada uno de los puntos pertenecientes a las distintas curvas.

En t´erminosde la validez de los resultados, tanto la reducci´oncomo la obtenci´onde curvas de luz, en sus implementaciones CPU y GPU, generaron resultados correctos al ser comparados con los de AstroPy, lo que significa que los desarrollos y aproximaciones dise˜nados para FADRA otorgan resultados que pueden ser utilizados con seguridad para el an´alisis cient´ıficode im´agenesastron´omicas. En t´erminosde tiempos de ejecuci´on,la naturaleza intensiva en uso de datos propia del proceso de reducci´onhace que la versi´onGPU sea incluso m´aslenta que la versi´onCPU. Sin embargo, en el caso de la obtenci´onde curvas de luz, el algoritmo GPU presenta una disminuci´onimportante en tiempo de ejecuci´oncomparado con su contraparte en CPU.

i Abstract

This thesis sets the bases for FADRA: Framework for Astronomical Data Reduction and Analysis. The FADRA framework is designed to be efficient and easy to use, modular, expandable, and open source. Nowadays, astronomy is inseparable from computer science, but some of the software still widely used today was developed three decades ago and is not up to date with the current data paradigms. The world of astronomical software development must start evolving not only towards practices that comprehend and embrace the big data era, but also that lead to collaborative work in the community.

The work carried out in this thesis consisted in the design and implementation of basic algorithms for astronomical data analysis, to set the beginning of the FADRA framework. This encompassed the implementation of data structures that are efficient when working with a large number of astronomical images, the implementation of algorithms for astronomical data calibration or reduction, and the design and development of automated photometry and light curve obtention algorithms. Both the reduction and the light curve obtention algorithms were implemented on CPU and GPU versions. For the GPU implementations, the algorithms were designed considering the minimization of the amount of data to be processed, as a means to reduce the data transfer between CPU and GPU, a slow process which in many cases can even overshadow the gains in execution time obtatined through parallelization. Even though the main idea is for the FADRA algorithms to be run within scripts, a wrapper module to run Graphical User Interfaces (GUIs) for the code was also implemented.

One of the most important steps of this thesis was validating the correctness of the results obtained with FADRA algorithms. For this, the results from the reduction and the light curve obtention processes were compared against results obtained using AstroPy, a Python package with different utilities for astronomers. The experiments were carried out over six datasets of real astronomical images. For the case of astronomical data reduction, the Normalized Root Mean Squared Error (NRMSE) was calculated between the images to measure their similarity. In the case of light curves, the shapes of the curves were proved to be equal by finding constant offsets between the numerical values for each data point belonging to a curve.

In terms of correctness of results, both the reduction and light curve obtention algorithms, in their CPU and GPU implementations, proved to be correct when compared to AstroPy’s results, meaning that the implementations and approximations designed for the FADRA framework provide correct results that can be confidently used in scientific analysis of as- tronomical images. Regarding execution times, the intensive data aspect of the reduction algorithm makes the GPU implementation even slower than the CPU implementation. How- ever, for the case of light curve obtention, the GPU algorithm presents an important speedup compared to its CPU counterpart.

ii Acknowledgements

First I would like to thank my family for always supporting me and helping me follow my dreams. This work and everything else I’ve accomplished so far would not have been possible without their love and encouragement. I would also like to thank Fernando Caro for his support and company, not only through the development of this thesis but in life.

I would like to thank my friends for being the best company I could ask for, and for putting up with my long disappearances because “I have to work on my thesis tonight”, many nights. Thank you for being so patient and for always cheering for me and supporting me.

I also want to thank Professor Patricio Rojo for all these many years of friendly work and advice. This thesis would not have happened if it wasn’t for him and his insistence on making better astronomical software. I would also like to thank Professor Maria Cecilia Rivara for her great support through my years as a student and all through this thesis, which I probably wouldn’t have finished already if it wasn’t for her relevant advice and comments. Both of my advisors were a fundamental part of my student years and of this work and I would not have made it this far if it wasn’t for them.

Finally I would like to express my thanks to the members of the revision committee, Professors Alexandre Bergel, Johan Fabry, and Gonzalo Acu˜na,for their careful reviews of my thesis and for their relevant comments to improve it. Last but definitely not least I want to thank Ren Cerro for kindly taking the time to proof-read this text.

iii Contents

List of Tables vi

List of Figures vii

1 Introduction 1 1.1 Astronomical data analysis ...... 1 1.2 Astronomical software development ...... 2 1.3 Thesis description ...... 3 1.3.1 Goals and objectives ...... 3 1.3.2 Research questions ...... 4 1.3.3 Software architecture ...... 4 1.3.4 Use of previous work ...... 5 1.3.5 Programming languages ...... 5 1.3.6 Validation of results ...... 5

2 Literature revision 8 2.1 Existing software ...... 9 2.2 Criticism of existing solutions ...... 15

3 Astronomical data and analysis 17 3.1 Astronomical data ...... 17 3.1.1 Astronomical images ...... 17 3.1.2 Astronomical spectra ...... 18 3.2 Astronomical image acquisition ...... 19 3.3 Astronomical image reduction ...... 21 3.4 Astronomical image processing ...... 22 3.4.1 Image arithmetic and combining ...... 23 3.4.2 Filter application ...... 24 3.4.3 Photometry ...... 25 3.4.4 Light curve or time series generation ...... 29

4 Introduction to General-Purpose Graphics Processing Unit (GPGPU) computing 30 4.1 What is the Graphics Processing Unit (GPU)? ...... 30 4.2 General-Purpose GPU computing (GPGPU) ...... 33 4.3 GPGPU use in astronomy ...... 34 4.3.1 GPGPU use for astronomical data analysis in this thesis ...... 35

iv 5 Software design and implementation 36 5.1 Data handling: AstroFile and AstroDir classes ...... 36 5.2 Calibration image combination and obtention of Master fields ...... 37 5.3 Astronomical image reduction ...... 39 5.3.1 CPU reduction implementation ...... 40 5.3.2 GPU reduction implementation ...... 40 5.4 Light curve obtention: the Photometry object ...... 41 5.4.1 Data handling for light curve obtention ...... 42 5.4.2 Obtaining target data stamps ...... 43 5.4.3 Reduction process using stamps ...... 45 5.4.4 Aperture photometry ...... 45 5.4.5 Light curve data handling and visualization: the TimeSeries object . 47 5.5 Graphical User Interface ...... 49

6 Experimental settings 52 6.1 Validation of results ...... 52 6.1.1 Experiment 1: Validation of reduction results ...... 53 6.1.2 Experiment 2: Light curve evaluation ...... 54 6.1.3 Experiment 3: Comparison between FADRA’s CPU and GPU photometry implementations ...... 55 6.2 Execution time comparison ...... 56 6.3 Platforms ...... 56

7 Results 57 7.1 Validation of FADRA results ...... 57 7.1.1 Experiment 1: Validation of reduction results ...... 57 7.1.2 Experiment 2: Light curve evaluation ...... 59 7.1.3 Experiment 3: Comparison between FADRA’s CPU and GPU photometry implementations ...... 61 7.2 Execution time comparison ...... 62 7.2.1 Reduction ...... 62 7.2.2 Light curve generation ...... 64

8 Conclusions 65 8.1 Development of basic algorithms for astronomical data analysis ...... 65 8.2 Implementation of algorithms for light curve obtention ...... 67 8.3 GPU implementation of algorithms ...... 68 8.4 Future work ...... 70 8.4.1 Within the scope of this thesis ...... 70 8.4.2 The FADRA framework ...... 72

Bibliography 73

A Details of results 80 A.1 Validation of reduction results ...... 80 A.2 Execution time results ...... 80

v List of Tables

6.1 Datasets used for experiments ...... 53

7.1 Mean, median, and standard deviation for reduction results ...... 59 7.2 AstroPy and FADRA’s CPU light curve results comparison ...... 61 7.3 FADRA’s CPU and GPU light curve results comparison ...... 62

A.1 NRMSE for reduction result validation ...... 80 A.2 Reduction execution times ...... 81 A.3 Light curve obtention execution times ...... 81 A.4 Average execution time for reduction ...... 81 A.5 Average execution time for light curve obtention ...... 81

vi List of Figures

3.1 Diagram of a spectrograph ...... 18 3.2 Diagram of a telescope ...... 19 3.3 Diagram of a CCD detector ...... 20 3.4 Wavelength filters ...... 20 3.5 Example of the reduction process ...... 22 3.6 Gaussian kernel ...... 25 3.7 Air mass ...... 26 3.8 Raw vs. differential photometry ...... 27 3.9 Target, sky annulus, and reference star selection for photometry ...... 28

4.1 Host and devices on GPU computing ...... 31 4.2 Memory on a GPU ...... 32 4.3 Work-items and work-groups on a GPU ...... 33

5.1 The AstroFile and AstroDir classes ...... 38 5.2 The Photometry object ...... 41 5.3 Data stamps for aperture photometry ...... 43 5.4 Data stamps following targets ...... 44 5.5 Data stamp parameters ...... 45 5.6 The TimeSeries class ...... 47 5.7 GUI for AstroDir creation ...... 49 5.8 GUI showing loaded AstroDir objects ...... 50 5.9 GUI for photometry targets selection ...... 50 5.10 GUI for aperture photometry parameters selection ...... 51 5.11 Example of light curves for two targets ...... 51

7.1 NRMSE between AstroPy and FADRA CPU reduction results ...... 58 7.2 NRMSE between FADRA’s CPU and GPU reduction results ...... 60 7.3 Execution times for reduction algorithms ...... 63 7.4 Execution times for light curve obtention ...... 64

vii Chapter 1

Introduction

1.1 Astronomical data analysis

Starting from the first astronomical observations, when the human eye was the only tool used to examine the Cosmos, ancient astronomers realized that the movement of the objects in the sky was related to the seasons, and thus to cycles in nature relevant to survival. Since the beginning, astronomers have used all the available resources to keep track of the movements on the celestial sphere, from clay tablets to ancient papyri. After the invention of the telescope was made public by Galileo Galilei in 1609, a new era of astronomy emerged, in which much more than meets the eye was to be observed in the sky and subsequently recorded. The only way to document astronomical observations was to spend countless hours behind a telescope, taking notes and making illustrations of what was being seen. Some of the most important astronomical discoveries of all times were carried out during this era.

It was not until the early decades of the 20th century that the use of photographic plates as detectors on telescopes became the standard, granting astronomers the chance to finally and permanently capture exactly what they were seeing through the instrument. Thousands of new objects were discovered through the careful human-eye inspection of these plates. During the 1980s, the use of digital detectors on telescopes became widespread, again revolutionizing the way astronomical analysis could be conducted. With the astronomical images in digital formats, and with the aid of computers, the analysis of astronomical data became more precise, more standardized, and faster.

Nowadays, astronomy is inseparable from computer science. And, today, a new era of observational astronomy is also starting: the survey era, which goes hand in hand with the big data era in technology. The usual observational astronomy paradigm, in which the astronomer applies for nights at an observatory, observes the desired target objects for a few nights, and then goes back home with the data, is starting to be replaced by survey telescopes: instruments devoted to observe the complete night sky, or their specific catalog of objects, all night, every night. Data from these surveys is then released online for astronomers to download the information relevant to their scientific interests and perform analyses without the need of visiting an observatory.

1 Along with new ways of obtaining data, there is also a need for new ways of processing and analyzing it. Looking for changes pixel by pixel, frame by frame as was done in the times of photographic plates is simply unfeasible with the amount of data available today. Right now, astronomy is not only concerned with the science obtained from observations, but also with designing better ways to inspect data. Furthermore, as new telescopes and astronomical detectors are developed all over the world, astronomical data thrives and so is the science that utilizes it.

1.2 Astronomical software development

The development of astronomical software oriented to astronomers for individual use dates back to the 1980s. As will be further commented on chapter 2, a lot of software developed almost three decades ago is still used to this day. Of course, these software are completely reliable, and when working with them one can be assured that the results will be correct. However, having been developed so long ago, they are not up to date with the current data paradigms. Waiting minutes for one astronomical image to be calibrated, or having to set parameters and analyze each image frame separately, are common occurrences in the most established astronomical software used today.

This has lead astronomers to develop their own astronomical software according to their needs. Today, most astronomers have a preferred programming language and implement their own algorithms. Even though this may seem like a good solution, in practice it yields a lot of dissimilar software, prone to human errors, since the same algorithms are implemented over and over by different scientists. Users of certain programming languages, such as Python, are working in the development of libraries to make the task of analyzing astronomical data easier. These projects, however, have so far only yielded separate algorithms, but no unified software has been released. Also, by taking care of just very specific functionality, these developments serve more as an aid for programmers, rather than a software program or framework that is ready for astronomers to use.

Since software development is such a fundamental part of the work of astronomers, doing so in the best possible way should be a priority for them; sadly, this is not always the case. Given the fact that astronomers need to program their own code, they are often not able to fully finish or polish it before they have to begin doing science on their images; much less document or release it publicly for the rest of their colleagues [81]. These problems could be greatly diminished, for example, by the creation of open source frameworks allowing astronomers to freely add new packages according to their needs. This reduces duplicate efforts, and makes it easier for the whole astronomical community to work together making better software tools.

The world of astronomical software development must start evolving not only towards practices that comprehend and embrace the big data era, but also that lead towards collab- orative work in the community.

2 1.3 Thesis description

The aim of this thesis is to set the bases of the FADRA framework for astronomical image reduction and analysis. The work carried out in this thesis considers setting up the modular structure of FADRA, as well as implementing the basic algorithms needed for astronomical image analysis and also more advanced procedures for light curve obtention.

Besides the focus on the design of the framework and algorithm implementation, this thesis experiments with GPU implementations of certain algorithms. Investigating the possibilities of using GPU-accelerated algorithms for astronomical software meant for common use could bring about more efficient and faster ways for astronomers to calibrate and analyze their data, a critical point in the big data era.

1.3.1 Goals and objectives

The following goals are achieved with the work implemented in this thesis:

G1: To develop a framework that provides the basic algorithms necessary for astronomical data analysis: data reduction algorithms and image combination algorithms for the obtention of calibration files. G2: To provide algorithms for automated light curve (time series) generation, with as mi- nimal user intervention as possible, but also that are efficient in execution time and provide good results. G3: To provide GPU accelerated versions of reduction algorithms and of light curve obten- tion procedures. G4: To create this framework through code that is modular, expandable, well documented, and open source.

These goals can be further specified through the definition of a set of secondary goals, or objectives, achieved through the work of this thesis. These objectives consider:

O1: Implementation of data structures that are efficient when working with hundreds or thousands of astronomical images. O2: Implementation of algorithms to combine images and obtain calibration files needed for the astronomical image analysis process. O3: Implementation of algorithms for astronomical image reduction, or calibration, that are easy and direct to use over a large amount of images. O4: Design of novel ways to implement the reduction and analysis processes over several astronomical images for the obtention of light curves, as a means to reduce computa- tion time and make data transfer more efficient when dealing with GPU accelerated algorithms. O5: Validation of the quality of the results obtained with the FADRA framework, carried out by comparing said results to the ones obtained with established astronomical software.

3 O6: Implementation of Graphical User Interface modules that allow the user to use FADRA’s functionalities in an interactive way, and which provide visualization for the data and the corresponding calculation results.

All the algorithms and processes to be carried out over astronomical images mentioned in the goals and objectives are further detailed and explained in Chapter 3. The technical design and implementation aspects of the aforementioned objectives can be found in Chapter 5.

1.3.2 Research questions

This thesis develops and evaluates GPU-accelerated versions of some of the algorithms nec- essary for the analysis of astronomical images. Even though some approaches to GPU imple- mentations for astronomical applications exist, they focus mainly on numerical cosmological simulations [17, 32, 38, 43, 64, 80]. GPU performance analysis of classical astronomical image algorithms is an area that is just now being developed [7,34,87]. Chapter 4 presents a more extended review of GPU use in astronomical software.

Since data transfer rates between CPU and GPU are still slow, it is of vital importance to make sure that the transfer is made in the most efficient way possible. Because of this, the implementation of this thesis considers a novel approach in terms of data handling, transfering to the GPU only the least amount of data as possible. This process is further explained in section 5.4.

The experiments performed in the context of this thesis seek to answer two questions:

Q1: Is it possible to obtain significant GPU speedup in astronomical algorithms that deal with a large amount of data transfers between CPU and GPU? Q2: Are these speedups justified? In other words, is the obtained acceleration worth it considering the extra implementation that GPU algorithms convey?

This thesis answers these questions by analyzing the results of timing performance on the different algorithms. Execution time comparisons were carried out between the GPU and CPU implementations of FADRA, as well as between FADRA algorithms and established astronomical software.

1.3.3 Software architecture

FADRA is designed as completely modular software. All algorithms and functions belonging to specific processes were implemented as separate Python packages. This serves two main purposes: first, it allows users to easily find the implementation of the algorithms and func- tions, in case they wish to edit some of them to better fit their personal needs. Secondly, it makes it easier for users to simply create new packages and integrate them to the FADRA code. The organization of modules in Python packages also allows for users to simply import

4 certain packages in their own personal implementations, in case they do not need to use FADRA’s complete implementation.

1.3.4 Use of previous work

As a starting point for the algorithms of this thesis, previous work by Professor Patricio Rojo, developed in the Astronomy Department of Universidad de Chile was reviewed. Said work encompasses the development of data structures to work with large number of astronomical images at a time (further explained in section 5.1) as well as the approximation for aperture photometry used in the CPU version of said algorithm (further explained in section 5.4.4).

This preceding implementation was adapted to work through the developments carried out in this thesis. Further comments about the existing code and its consequent adaptation is given in the relevant chapters of this thesis.

1.3.5 Programming languages

FADRA was developed using the Python programming language. The version used was Python 3.4.3. Python is currently one of the most widely used languages for data analysis, especially in astronomy. Beginner-friendly but still powerful, Python currently competes directly with astronomical programming languages such as the commercial IDL or MATLAB. The GUIs were implemented using Tk through its package Tkinter for Python.

The GPU part of the algorithms was implemented in the GPU-oriented programming language OpenCL (Open Computing Language) [36,73]. Although CUDA (Compute Unified Design Architecture) [52,58] is a widely used language for GPU programming, it presents the disadvantage of running only on NVidia hardware. OpenCL, on the other hand, is open, free, cross-platform, and really heterogeneous: it runs on any brand of graphical hardware. The implementation of this thesis was done in OpenCL as a means to not restrict the machines where the framework can be used. The version used was OpenCL 1.2.

1.3.6 Validation of results

The validation of the results obtained through the algorithms and functions developed for this thesis consists in two different stages: validation of astronomical reduction results, and validation of light curve results. The reduction process for astronomical images is further explained in section 3.3, whereas the process of light curve obtention is explained in section 3.4.4.

Reduction of astronomical images is the first step to be carried out before performing analyses over the data. Because of this, the results from the reduction algorithms must be correct. The best way to demonstrate this is to compare the results from FADRA’s reduction implementations, both in CPU and GPU versions, to the results of reduction carried out with

5 different, established astronomical software. In this case, AstroPy (section 2.1.2) was used, with its module ccdproc, designed to perform basic operations in astronomical images such as calibration and combinations.

The similarity metric used to compare the pairs of reduced images was the Normalized Root Mean Squared Error (NRMSE). The NRMSE measures the percentage of difference between a predicted value and a real, observed value. For the case of comparing FADRA’s reduction results to AstroPy results, the latter was considered as the predicted or gold stan- dard value and the former considered as the observed value. When comparing FADRA’s CPU results to GPU results, the CPU reduction results were considered as the standard, and the GPU results were considered as the observed values. Further details on the calculation of the NRMSE and the evaluation of reduction results are given in Chapter 6.

The validation of results also considers evaluating the correctness of light curve obtention results. Again, FADRA’s CPU results were compared again established software results, and FADRA’s CPU and GPU algorithms were compared against each other. When comparing curves, relationships between the points that compose each different curve were found, to check that the differences between the points inside of the curves themselves are maintained. This is because the most important feature to evaluate when comparing two light curves is not only that they are similar, but that the variations within the points are exactly the same, since it is these variations that are of importance when studying light curves of variable astronomical objects.

Further details about the experiments carried out in this thesis, similarity metrics, and datasets, are given in Chaper 6.

Outline

Chapter 2 of this thesis consists in an exhaustive literature revision of current astronomical software. Every software that vouches to offer utilities similar to the ones in the FADRA framework is described, and an analysis of why none of the existent solutions covers the same extents as FADRA is given.

Chapter 3 presents detailed explanations on astronomical data obtention, processing, and scientific analyses. The said chapter introduces all the basic processes to be carried out over astronomical images, which are implemented in the FADRA framework. Chapter 4 presents an introduction to General Purpose Graphics Processing Unit computing, or GPGPU com- puting, the state-of-the-art method for algorithm acceleration. A description of how GPGPU is used to the advantage of analysis in the FADRA framework is also stated.

Chapter 5 discusses the software design and implementation steps carried out for the creation of FADRA. The different classes, data structures, and algorithms implemented in this thesis are detailed and explained.

The experimental framework and settings used for the validation of FADRA results are detailed in Chapter 6. The metrics used to compare the different results are introduced, and

6 the details of the datasets used on the experiments are presented.

The results of said experiments and analyses over several astronomical datasets are pre- sented in Chapter 7. Timing analyses of different FADRA algorithms are also presented, to show the speedup obtained with GPU acceleration compared with FADRA’s own CPU algorithm implementations.

Finally, in Chapter 8, the conclusions obtained from the results are presented, as well as a revision of the current functioning of FADRA and an overview of the future work to be implemented for the framework.

7 Chapter 2

Literature revision

The following is an exhaustive summary of current existing astronomical software. All the details regarding astronomical image processing and analysis will be further explained in Chapter 3. There are, however, some basic concepts to be introduced before presenting the software review:

ˆ Astronomical image reduction (section 3.3) corresponds to the process of calibra- ting astronomical images after they are acquired through a telescope. The reduction process for astronomical images is standardized and must be applied to every astrono- mical image over which scientific analyses are to be carried out. It is a basic, essential tool for astronomical image processing. ˆ Filter application (section 3.4.2) refers to the application of convolution kernels over the images, such as a Gaussian filter or mean filter. ˆ Photometry (section 3.4.3) is the process of measuring the amount of light received from an astronomical object, through the images obtained during the observations of said object. The most common type of photometry performed over astronomical images is called aperture photometry. ˆ Light curves (section 3.4.4) are curves resulting from the photometry measurements over a series of images of the same astronomical object through a period of time. Light curve obtention is a crucial step for many areas of astronomy, including variable stars, supernovae, and extrasolar planet studies, among others. ˆ FITS files (section 3.1.1) are the standard data storage system for astronomical images.

The criteria for the software to be included in this list were the following:

ˆ The software must focus on the analysis of astronomical images in the visual spectrum. Software dedicated to radioastronomy and spectroscopy was not considered, since this work does not cover those areas. ˆ Only software that has at least basic astronomical image reduction tools was consid- ered. Software meant for telescope control or just image acquisition, but without image processing tools, was not considered.

8 2.1 Existing software

2.1.1 Aladin Sky Atlas [11] Launch year: 1999 Latest version: March 2014 License: GPL v31 Platforms: Linux, Mac OSX, Windows Developer team: Centre de Donn´eesastronomiques de Strasbourg, Universit´ede Stras- bourg Interactive sky atlas, cross-platform. It allows visualization of astronomical images obtained from the SIMBAD database2. It includes photometric information in its latest version, how- ever the photometry is not calculated from the images, but loaded from the VizieR astrono- mical catalog3, also from Strasbourg University [3]. Its latest version was launched alongside Aladin Lite [10], HTML5 version to be used in web browsers. In its desktop version, it allows the user to create operation scripts, using Aladin’s own Application Programming Interface (API)4.

2.1.2 AstroPy [5] Launch year: 2011 Latest version: December 2015 License: 3-clause BSD license5 Platforms: Linux, Mac OSX, Windows Developer team: open-source Python package including different tools of common use in astronomy. For now, it has tools for opening, reading and writing FITS files, astronomical coordinate use, and some astrometry6 tools. Analysis functions, image visualization and photometry packages are mentioned as “planned”, but have not been developed yet [4].

2.1.3 The Starlink Project [48] Launch year: 1980 Latest version: June 2015 License: part GPL1, part commercial (original Starlink license) Platforms: Linux, Mac OSX Developer team: from 1980 to 2005, the Joint Astronomy Centre, Hawaii University. From 2005 to present, the East Asian Observatory. Group of software developed for general astronomical use. It provides tools for reduction,

1https://www.gnu.org/copyleft/gpl.html 2http://simbad.u-strasbg.fr/simbad/ 3http://vizier.u-strasbg.fr/viz-bin/VizieR 4An application programming interface, or API, is a set of functions and procedures that allow access to the features or data of a software. Many software have their own API definitions, which are the unique commands necessary to run the program. 5https://github.com/astropy/astropy/blob/master/licenses/LICENSE.rst 6The measurement of the exact position of astronomical objects in the sky and their variations through time

9 aperture photometry, and statistical analysis of the images. The aperture photometry im- plementation requires the user to input the target object coordinates for each frame of the series. It provides a graphical interface through the GAIA-Skycat software (2.1.17). Since the administration change in the year 2005, its focus has been sub-milimetric (radio) data reduction [20].

2.1.4 IRAF: Image Reduction and Analysis Facility [77] Launch year: 1984 Latest version: March 2012 License: free for public domain use. Platforms: Linux, Mac OSX, Windows through Cygwin Developer team: NOAO, National Optical Astronomical Observatories. AURA, Associa- tion of Universities for Research in Astronomy. Tucson, Arizona. One of the most widely used astronomy software tools. Its functioning is based on various method packages, developed by different institutions. Each user can define their own pack- ages, which must be written in the native IRAF command language, SPP. It possesses image reduction packages, as well as packages for stellar and aperture photometry [21]. It does not have any visualization or graphical tools of its own, and all the interaction must be carried through the command line. To visualize images, it must be used together with different software. The commonly used one is DS9 (2.1.15).

2.1.5 STSDAS: Space Telescope Science Data Analysis System Launch year: 1994 Latest version: March 2014 License: STSci license7. Free for public domain use. Platforms: Linux, Mac OSX Developer team: Science Software Branch of the Space Telescope Science Institute IRAF (2.1.4) based astronomical software suite. Contains tools for reduction and analysis of images, for both general use and specific for Hubble Space Telescope (HST) data. It is designed as a series of enhancements for IRAF. The user interface and graphical terminals are given by IRAF, so they are just as minimal as in such software. It possesses tools specifically for aperture photometry [15]. It can also be used through the IRAF Python package, PyRAF (2.1.14).

2.1.6 IRIS [14] Launch year: 1999 Latest version: September 2014 License: free for non-commercial use. Platforms: Windows Developer team: Christian Buil Software designed mostly for astronomical image acquisition. It also contains tools for basic reduction and analysis, including rudimentary aperture photometry which must be performed by the user manually over each frame.

7http://www.stsci.edu/institute/software hardware/pyraf/pyraf-license

10 2.1.7 CCDSoft Launch year: - Latest version: January 2001 License: Commercial Platforms: Windows Developer team: Software Bisque8, together with Santa Barbara Instrument Group (SBIG)9. Designed together with astronomical instrumentation company SBIG, CCDSoft is an image acquisition software that also contains reduction and analysis tools. It has an interactive graphical interface, which includes interactive options for photometry. However, just like in Aladin (2.1.1), the photometry is not calculated directly from the images, but obtained from catalogs. The program allows loading and accessing different photometric catalogs, includ- ing the US Naval Observatory CCD Astrograph Catalog [84] and the VizieR catalog from Strasbourg University [57]. Software Bisque, the developer company, specializes in camera and telescope control software.

2.1.8 Mira Pro Launch year: 1988 Latest version: December 2012 License: commercial Platforms: Windows Developer team: Mirametrics10 Promoted as software “with no peer for speed, features, and efficiently integrating a rich collection of tools for image display, plotting, processing, measurement, and analysis”. It possesses a graphical interface, with tools for image reduction and also for obtaining and plotting the photometry of the images, to be executed one image at a time. This program stands out with its good handling of images of great size. It allows the user to create and run scripts, in the programming language Lua11. A version designed for the amateur public, Mira AL, is available and also commercial. It does not have complicated analysis tools. The software was developed by Mirametrics, company dedicated to imaging software for science an engineering, mainly for astronomy and medical sciences.

2.1.9 MaxIm DL Launch year: 1993 Latest version: 2013 License: commercial Platforms: Windows Developer team: Diffraction Limited12 Integrated software with tools for both telescope control and image acquisition, as well as im- age reduction and basic analysis. Provides interactive tools for basic photometry, to be done one image at a time, through a graphical interface. It was developed by Diffraction Limited,

8http://www.bisque.com/sc/ 9http://www.sbig.com 10http://www.mirametrics.com 11https://www.lua.org/ 12http://www.cyanogen.com/

11 a Canadian company dedicated to astronomical, biomedical, and laboratory software.

2.1.10 AIP4Win Launch year: 2000 Latest version: 2006 License: commercial Platforms: Windows Developer team: Willmann-Bell, Inc.13 Software originally designed to go with the book “The Handbook of Astronomical Image Processing”, by Richard Berry and James Burnell [9]. It provides a graphical visualization interface and tools for image reduction and analysis. It has basic photometry tools which obtain the numerical value of the studied object, but it does not have tools for plotting or visualizing such information.

2.1.11 CCDOps Launch year: - Latest version: November 2011 License: commercial Platforms: Windows, only the first version available for Linux and Mac OS X Developer team: Diffraction Limited12 Similar to CCDSoft (2.1.7). Used mainly for astronomical image acquisition from SBIG cameras. Provides a graphical interface and tools for image reduction and basic image en- hancement [66]. It does not provide tools for photometry, filter application, or complex image analysis, since it is mainly aimed at image acquisition.

2.1.12 AstroArt Launch year: 1998 Latest version: February 2015 License: commercial Platforms: Windows Developer team: MSB Software14,15 Software designed for astronomical image reduction. Provides catalog-assisted astrometry and photometry tools. It also provides basic filters for image enhancement.

2.1.13 IDL Astronomy User’s Library [78] Launch year: 1990 Latest version: May 2016 License: free download, but requires the commercial programming language IDL Platforms: Linux, OS X, Windows

13http://www.willbell.com/aip4win/aip.htm 14http://www.msbsoftware.it/ 15http://www.msb-astroart.com/

12 Developer team: Astrophysics Science Division (ASD) of NASA16 Low-level astronomical routine repository, developed in the programming language IDL, which is only distributed on payware license. It is not an integrated package, but sepa- rate routines which can be used independently by the users [46, 47]. It contains aperture photometry routines, similar to the package DAOPHOT [22] from IRAF.

2.1.14 PyRAF [33] Launch year: 2000 Latest version: November 2015 License: STSci license7 Platforms: Linux, OS X, Windows Developer team: Science Software Branch of the Space Telescope Science Institute Python package developed to work with IRAF (2.1.4) commands. It gives users the ability to run different IRAF packages, taking advantage of Python’s flexibility. It provides access to all of IRAF’s reduction and analysis packages, including the photometry package DAOPHOT. All instructions must be given through IRAF commands. Since IRAF does not provide a graphical user interface, neither does PyRAF. Some plotting packages have been planned and designed, to show IRAF plots on Python’s graphical interfaces [23,24], but it does not come with its own GUI or allows interactive performing of operations such as aperture photometry.

2.1.15 SAOImage DS9 [72] Launch year: 1999 Latest version: December 2015 License: combination GPL, LGPL, and BSD, depending on the package Platforms: Linux, OS X, Windows Developer team: Smithsonian Astrophysical Observatory (SAO) Center for Astrophysics, Harvard University A tool focusing on image visualization [40]. With a graphical interface based on simplicity [41], its premise is visualization only: although it provides the option of having different image frames, scale changes, zoom, and geometrical markers, it does not come with image reduction tools or any other type of operation to be performed on images. This is why it is used together with IRAF (2.1.4), giving it the visual interface that the analysis software does not possess.

2.1.16 MIDAS: Munich Image Data Analysis System [6] Launch year: 1983 Latest version: September 2015 License: GPL Platforms: Linux, OS X Developer team: European Southern Observatory (ESO) Software developed by ESO with general tools for reduction and analysis of astronomical images. It provides mathematical and statistical tools, and also packages for astrometry and photometry. Instructions are given through the command line, and they must be in their

16http://idlastro.gsfc.nasa.gov/

13 own MIDASCL language.

2.1.17 GAIA-Skycat: Graphical Astronomy and Image Analysis [2, 25] Launch year: 1997 Latest version: 2014 License: GPL Platforms: Linux, OS X Developer team: Very Large Telescope (VLT) project at ESO Visualization software belonging to the Starlink Astronomical Software Project (2.1.3). It provides a graphical user interface, besides basic tools for image reduction and photometry.

2.1.18 MOPEX: MOsaicking and Point-source EXtraction [55] Launch year: 2006 Latest version: December 2014 License: GPL Platforms: Linux, OS X, Windows Developer team: Spitzer Science Center, California Institute of Technology Reduction and analysis software, designed by the Spitzer Space Telescope17 team and spe- cialized to work on data acquired by this instrument. Even though it works for general data, the team recommends checking data parameters and they do not assure that it will work as well with data from telescopes other than Spitzer. It also provides a command line interface. The GUI does not allow for use of all the available functionalities, only the most common reduction ones. More complex analysis must be carried out through the command line inter- face. It has basic aperture photometry tools. Its strength is in its generation of astronomical image mosaics18.

2.1.19 THELI [70] Launch year: 2005 Latest version: February 2016 License: GPL v2 Platforms: Linux Developer team: Gemini Observatory, University of Bonn THELI is a package designed for automated astronomical data reduction. It provides tools for background calibration, astrometry, and basic photometry tools for flux calibration only, not for light curve obtention. It does not have filter application functions. The GUI version of THELI gives the user a graphical interface to select the input data and to insert the necessary parameters. It offers acceleration through CPU parallel implementations of some algorithms.

17http://www.spitzer.caltech.edu/ 18A mosaic must be obtained when a large object spans over a series of images. These images must be carefully aligned to make sure the fit of the images is perfect and thus that the final image is correct.

14 2.1.20 ATV.PRO [8] Launch year: 1998 Latest version: January 2016 License: free download, but requires the commercial programming language IDL Platforms: Linux Developer team: Aaron Barth, University of California Irvine Just like DS9 (2.1.15) serves as a visualization tool for IRAF (2.1.4), ATV.PRO serves as a visualization tool for IDL Astronomy User’s Library (2.1.13). It provides image visualization, scaling, color scales, and world coordinate systems. It also provides a very simple aperture photometry tool, for calibration purposes only and it does not allow for light curve obtention. It provides no other analysis or filter application functions.

2.1.21 Aperture Photometry Tool (APT) Launch year: 2012 Latest version: May 2016 License: Free for research and educational purposes Platforms: Linux, OS X, Windows Developer team: Infrared Processing and Analysis Center (IPAC), California Institute of Technology, on behalf of the National Aeronautics and Space Administration (NASA) As its name says, APT is designed to perform GUI based aperture photometry analysis. It does not provide any kind of reduction, calibration, or filtering functions. APT is designed for manually analyzing one image at a time, and light curve obtention is not supported.

2.2 Criticism of existing solutions

Even though there is varied availability of reduction and analysis software, the offers are very dissimilar in terms of efficiency, functionality, and availability for users. Some points can be directly noted:

ˆ None of the free software options possesses automated photometry, light curve obten- tion, or time series generation tools. ˆ None of the software options previously mentioned provide GPU support. ˆ Software that allows scripting requires that it is done through their own APIs. Although this is understandable, it can also pose problems when the user is to use the software or to add new functionality. ˆ Software from science institutions, even though they are mainly free for public use and open source, focus on their own APIs, or are optimized for their own specific data. They are available for general use from astronomers and their personal projects, but the specificity of the software may carry usage problems. ˆ In general, astronomical software development focuses on mathematical analysis, leav- ing simplicity for users behind, since in many cases scripts must be written using the APIs of the program. This sets a gap between the software and the individual users.

15 ˆ The best applications, that integrate the larger number and better level analysis tools with interactive GUIs are all payware and without free access. ˆ The best software for image visualization and editing is mostly Windows-based. This is because the focus of such a software is for amateur astronomy and astrophotography, and not for scientific astronomy.

In terms of performance, none of the previously mentioned software exploits the GPU as a way to speed up the processing time of algorithms. Nowadays, many applications take advantage of GPU computing, including everyday applications such as computer games, which do not require specific, state-of-the-art machines to be run. Current astronomical software solutions have not yet taken advantage of this area.

It can be said that there is currently no scientific astronomical software framework that covers reduction, data analysis, and automated light curve obtention, that is free of charge for users and open source.

16 Chapter 3

Astronomical data and analysis

These days, astronomy itself and astronomical data are very diverse. Data comes from many different sources and, as such, takes many different forms. Astronomical data can be split up in two main categories: images and spectra. Even though both have their own subcategories, the finer distinctions are only relevant in terms of the science to be carried out on the data. That is why only the two main categories will be discussed and presented as such. Since the analysis of astronomical spectra is not considered in this thesis, the following sections of this chapter (acquisition, calibration, and processing) will be regarded only in terms of astronomical images.

3.1 Astronomical data

3.1.1 Astronomical images

By far, images are the most widely recognized type of astronomical data, and the one most commonly related to this discipline. The standard accepted format for astronomical images is the .FITS (Flexible Image Transport System) [82]. FITS is an open standard for scientific data transport and storage. A .FITS file consists of one or more blocks, each one composed of a Header and a Data Unit. Each one of these blocks is called an HDU for short. All .FITS files must contain at least one HDU, which is called the primary. More HDUs are optional, and they depend on the type of data stored. These secondary HDUs are known as extensions. Each part of an HDU is composed as follows [37]:

ˆ Header: ASCII-formatted unit containing metadata about the Data Unit. Each Header contains an 80-character keyword sequence, with the format KEYWORD = value / comment string. In the case of astronomical data, the Header can contain information such as name and position of the observed object; time exposure of the image; location, date and time of the observation; instrument used; climate conditions of the night, among others. The Header also contains information about the celestial coordinate system used to find the object and obtain the image. This way, image pixel positions can be

17 mapped to coordinates and positions in the sky. ˆ Data Unit: data array, usually containing a 1-dimensional spectrum, a 2-dimensional image, or a 3-dimensional data cube. The Data Unit can contain arrays, of dimension from 1 to 999, of integers of 1, 2 or 4 bytes, or floating point real numbers of 2 or 4 bytes, in IEEE representation. The Data Unit may also correspond to tabular data, in ASCII or binary format. These binary Data Units are usually stored as extensions of another HDU, to be used in relational database systems.

During the last decade, since digital cameras and portable telescopes have become more easily available to the public, amateur astronomy imaging has also seen an increase, in what is usually known as astrophotography. Astrophotography is the process of obtaining astro- nomical images for pure aesthetic purposes, with no means of carrying out scientific analysis. These images are usually stored in the usual .JPG and .RAW formats, as in every digital camera, and processing is done using common image editing software, such as Photoshop or GIMP. In the last few years, however, new software has been developed specifically for astrophotography image editing. This software, although not containing detailed analysis tools, bring the editing of astrophotography images closer to the world of scientific astro- nomy image editing, by providing tools for reduction and correction of images similar to the ones in scientific software, but not as precise.

3.1.2 Astronomical spectra

Spectroscopy provides information about astronomical objects that would not be easily ob- tained from images, such as density, temperature, and chemical composition. An electromag- netic spectrum is a plot of light intensity, or power, as a function of frequency, wavelength, temperature, or other physical properties. Spectra is used in astronomy to measure three main bands: optical, radio, and X-Ray.

Optical spectra are obtained through telescopes, just like astronomical images. The dif- ference is that an spectrograph must be used instead of a camera. Essentially, what the spectrograph does is make the light pass through a light dispersion device, for example a prism, before reaching the image acquisition system (Figure 3.1). This way, the light coming from the astronomical object is not captured directly, but rather “fanned out” in the com- plete light spectrum. Slits are usually used to make sure that only the light from the desired object is entering the spectrograph. This way, different information about wavelength can be obtained.

Figure 3.1: Simple diagram of a single-slit spectrograph.

18 Spectra, just like astronomical images, can be stored in .FITS files. The science performed on spectra, however, is completely different from the one done over images. The software used to analyze spectra and images are different and do not usually come together.

3.2 Astronomical image acquisition

There are two necessary tools for acquiring astronomical images: telescopes and detectors. Telescopes serve as the zoom for a camera: it is within their internal structure that light gets captured. Most telescopes these days, from portable, amateur telescopes to the giant structures that can be found around the world, are based on a combination of mirrors and lenses that collect light from distant astronomical sources. The mirror and lenses help direct the light to the detection device. Figure 3.2 shows a basic diagram of how light is directed to the observer, using mirrors.

Figure 3.2: Simple diagram of a Newtonian telescope, which uses only mirrors to direct the light to the observer. Light enters the tube of the telescope through the left side of the diagram, where it travels all the way to the right to meet the primary mirror. This mirror redirects light to the smaller, secondary mirror, where it is then directed to the eye-piece of the observer, shown in red at the top. Image source: [44].

The amount of light collected by a telescope is proportional to the size of the primary mirror. This is why bigger telescopes are needed to see the fainter and further objects in the sky. Once the light passes through the telescope and onto the detector, however, the process remains the same, even across different instruments.

Professional telescopes use different optical arrays devices to capture the light and trans- form it into a digital image. The most common ones are Charge-Coupled Devices (CCD). A CCD allows the transformation of electrical charge into a digital value. CCDs are widely used in digital cameras and, since the 1980s, are the type of detector used in telescopes, replacing the old photographic plates, which had to be examined through human visual inspection. A CCD is usually a square array of CCD pixels, light-sensitive circuit elements covered in silicon. Photons reaching each CCD pixel generate an electronic charge, due to the photo- electric effect. This charge is then transformed to a digital copy of the light patterns coming into the device.

19 Figure 3.3: Simple diagram of a CCD detector. Arriving photons are turned into an electric current due to the photoelectric effect. This current is then turned into a numerical value in the computer.

An array of pixels on a CCD can be imagined as an array of buckets that capture photons as if they were rain water. All “buckets” are exposed to the photons for the same amount of time. The buckets fill up with a varying amount of “water”, depending on the field the telescope is observing: the areas of the CCD array where light from an astronomical object is hitting will fill up faster than the surrounding areas. Each “bucket” of the CCD is then read and transformed into a digital signal, which is transformed into a digital image in the computer.

Even though color CCDs are available and used in digital cameras, telescopes work with black and white CCDs, otherwise lots of important luminic information can be lost. Different filters can be located between the telescope and the CCD, in order to select the wavelengths to be observed. These filters can be used to enhance certain characteristics of the objects observed, since they selectively leave out colors and wavelengths that are not of interest to the observations. Filters allow astronomers to select different pass-bands, ranges of the electromagnetic spectrum between certain wavelengths [39], without the drawbacks of color cameras.

Figure 3.4: Example of the use of U, B, and V filters. The plot shows the amount of light detected through the different filters, over wavelength. Each filter defines a band of wavelength to be observed, leaving out the parts of the spectrum that are not of interest to the observations. Source: [39].

20 3.3 Astronomical image reduction

After acquisition, astronomical images are analyzed with different algorithms to obtain the relevant scientific information. The process is not standard: scientists looking for differ- ent information can carry out many different procedures over the same image. There are, however, certain algorithms which must be executed every time an astronomical image is to be analyzed, independent of the further work to be done on it. This process is known as astronomical image reduction. The reduction process considers three main steps: removing systematic electron count errors generated by the acquisition instrument, calibrating the light sensitivity of each CCD pixel, and removing defective pixels from the image.

To remove the electrons generated by the temperature of the instrument, special types of images, bias and darks, are obtained with the same CCD camera that will be used to acquire the astronomical images. Bias frames are 0 second exposure images, taken with the camera shutter closed, to obtain only the electronic background inherent to the camera and to the transmission process, from the camera to the computer. Dark frames are also obtained with the camera shutter closed, but with the same exposure time that will be used for the real astronomical images. In this way, the amount of thermal electrons added to the image during acquisition is sampled. Bias or dark frames are subtracted from the original image, since the goal is to remove these counts from it. Given the wavelenghts and filters commonly used in astronomy (section 3.2), usually only one of these fields, a bias or a dark frame, is used for the reduction of the images. From now on, only the dark frame will be considered, since it contains the bias correction.

Flat fielding corresponds to the correction and calibration of the CCD pixels, according to their sensitivity to the light received. Not all CCD pixels interact with photons in the same way: some of them may have their sensitivity altered by different causes, and this will be reflected in every image obtained through that CCD and camera. Consequently, the images need to be calibrated considering this factor. For this purpose, flat field images are obtained, which correspond to an homogeneously illuminated image. These can be obtained artificially over a drop background, or also with images of the sky at sunset or sunrise, known as sky flats. It is of vital importance to make sure that no stars or other objects appear on the image. The variation of light sensitivity of pixels has a multiplicative effect, so the original image has to be divided by the flat.

Finally, if the CCD has defective pixels, these could be reflected on the dark and flat fields. A mask of the image can be obtained to know which pixels have to be ignored or treated exceptionally in further analysis.

Because of Poisson noise inherent to the photon arrival process (further explained in section 3.4.1), each image obtained with a camera will have an associated error value. This means that if mathematical operations are to be performed between images, which is the case of image reduction, these errors have to be considered and correctly propagated through the operations. As a means to simplify the operations to be performed between the science images and the calibration ones, the error corresponding to the dark and flat fields can be minimized by obtaining several fields of each kind, and then combining them to obtain the final calibration files to be used in the procedure, usually known as Master calibration fields:

21 one MasterDark and one MasterFlat.

In the case of the MasterFlat, it can be obtained by simply combining the corresponding images as explained in section 3.4.1. In the case of the MasterDark, many times it can not be obtained directly from a combination. This, because it is important that the exposure time of the MasterDark used in the reduction is equivalent to the exposure time of the science images to be reduced. Usually, a series of dark frames is obtained with different exposure times for each. If the exposure time needed for the reduction is not present, a MasterDark can be interpolated from the rest of the images.

Once the MasterDark and MasterFlat are obtained, the MasterDark is subtracted from all fields and the reduction of an astronomical image is obtained as the result of the following operations:

Original image − MasterDark Reduced image = (3.1) MasterFlat − MasterDark

In terms of astronomical image processing, the original, pre-reduction image is referred to as a raw image. The image resulting from the reduction is referred to as the science image or the reduced image. Scientific analysis is performed over the reduced image.

Figure 3.5: Example of the reduction process. The left image shows a portion of a raw astronomical image. The middle image shows the result after subtracting the dark field, and the right image shows the result after dividing by the flat field. That final image corresponds to the reduced image over which scientific analyses are to be carried out.

3.4 Astronomical image processing

After astronomical images are reduced, scientific information can begin to be obtained from them. Depending on the data to be studied and the object observed, different processes will have to be carried out over the images in order to obtain the relevant information. There are some standard procedures to be carried out in many types of different astronomical image analyses:

22 3.4.1 Image arithmetic and combining

Often astronomical images have to be combined or stacked in different ways. Combining or stacking multiple exposures of the same object is a common method for noise reduction in astronomical images. The quality of an astronomical image can be defined in terms of the Signal-to-Noise Ratio (SNR), which corresponds to the ratio between the number of photons belonging to the observed light source (the signal) over the noise, which is the total contribution of photons from various and random sources that affect the signal:

Object (signal) photons SNR = Standard deviation of image photons

The SNR is a reflection of how well an object is measured in the image. Assuming a Gaussian distribution for photon arrival, the SNR value can be translated to standard deviation (σ) values of a Gaussian. Values between 2σ and 3σ mean that only about 68% of the photons come from the astronomical object of interest. A value of 4σ means that 95% of the photons are signal instead of noise, while 6σ means that 99.7% of the incoming photons correspond to signal.

More strictly, the number of photons N on a CCD detector follows a Poisson distribution [35]:

e−λt(λt)k Pr(N = k) = k!

This is a standard Poisson distribution, with the rate parameter λt, that corresponds to the expected incident photon count N. λ is the expected number of photons per unit time interval (thus the t). The random noise of an image can then be represented as the standard deviation for the Poisson distribution:

√ σ = N

One of the easiest ways to stack astronomical images to reduce noise is by simply summing them up. The sum is done pixel to pixel. This reduces the SNR, since the signal will be constant for all the images, but the noise is random. However, just as the SNR increases, the noise also does, although at a slower rate. When summing N images, the SNR follows:

√ SNR ∝ N

To reduce the background standard deviation noise, it is best to combine the images using average or median combining functions. A mean combining or average combining consists of taking the average value, pixel to pixel, for the N images stacked. A median combining consists of taking the median pixel, instead of the average. A median combining tends to

23 work better than an average combining, since extreme pixels are canceled out from the final image. For an average or median combining of N images, the SNR follows:

r 2N SNR ∝ π

All of these operations are done pixel to pixel over each of the N images to be combined. While noise reduction is one of the main reasons for image combining, the image combining process can also be carried out when using different filters for image acquisition, to merge the different layers into one real color image. This is commonly done for aesthetic purposes in astrophotography.

It is important to note that the stacking methods mentioned here are to be used only for Master calibration file obtention. When images with actual astronomical objects are to be stacked, the process is not so straightforward. Since there can be pixel or even sub- pixel differences between images, due to telescope movement or atmospheric interference, the stacking of astronomical images with objects must make sure that the pixels on the images are correctly aligned. This implies that some transformations, such as rotations or position changes, will have to be carried out in some of the images before the stacking procedures, yielding a process much more complex than simply calculating the mean or median values across the z axis.

3.4.2 Filter application

Combining or stacking images is not the only way to reduce noise. Smoothing filters can also be applied for this purpose. Unlike the previous case of image combination, where the average and mean are calculated between different images, the application of a mean or median filter uses the pixels of the input image only. A blurring of an image can also be used to remove unnecessary details, such as smaller objects around a larger target. A smoothing filter for an image consists essentially of successive convolutions of the image with a specific kernel, depending on the type of filter. The convolution is performed pixel to pixel. The output value for the new image pixels corresponds to the multiplication of each input pixel value with the corresponding kernel.

In the case of a Gaussian smoothing, the kernel consists of a discrete approximation of a Gaussian curve. An example of this kind of kernel is shown in figure 3.6.

Applying such a kernel over an image is an approximation of convoluting each pixel with a Gaussian curve. The degree of the smoothing is given by the standard deviation of the curve. What the Gaussian convolution outputs is a weighted average of the neighborhood of each pixel, giving a larger weight to the pixels near the center of the Gaussian.

A median filter is not based directly on a kernel, but rather on a pixel window. The filter takes each individual pixel and looks at its neighbors inside the window. Then, the value of the pixel is replaced by the median value of the neighborhood pixels. This median is obtained

24 Figure 3.6: Example of a 3 × 3 Gaussian kernel to be used in Gaussian smoothing. The multiplying factor in front of the mask is equal to the sum of the values of its coefficients, as is required to compute an average. by sorting all the pixels in numerical order.

A Gaussian filter generates a much softer smoothing than a median filter. Median filters, however, are better for removing bad pixels and random extreme value pixels, since very unrepresentative values on the pixel neighborhood will not affect the median.

3.4.3 Photometry

Images alone are not enough to gather important information about astronomical objects. While images can give us information about the morphology (shape) of the objects, quanti- tative information is needed to get estimates of energy output, temperature, size, and other physical properties. One of the ways to obtain this new information is through the process of photometry.

Photometry corresponds to the measurement of luminous flux, in terms of amount of energy as electromagnetic radiation, that is received from an astronomical object. Usually, photometry refers to measurements of flux over specific bands of electromagnetic radiation using filters such as the ones shown in figure 3.4. The measurement of this luminous flux requires the extraction of the raw image magnitude of the target object.

Absolute photometry is a complicated process that directly measures the luminous flux from the target. Many factors can interfere with the amount of photons captured from each light source: mainly, the size of the telescope (a telescope with a bigger mirror will capture more photons than a smaller one) and, when using images from earth-based telescopes, the effects of the atmosphere. The atmosphere produces extinction, meaning some of the photons from the source get absorbed or scattered in the sky before they hit the telescope mirror. It also produces seeing, which is the technical name for the effect that is normally referred to as the “twinkling” of stars, caused by the refraction of light several times as it passes through the different, turbulent layers of the atmosphere.

25 Figure 3.7: Air mass and how it affects astronomical observations. Depending on the position of the observed object in the night sky, the light will go through different amounts of air mass, which can be understood as it will travel through different lengths of atmosphere. In the image, air mass C is greater than air masses B and A. This affects what is known as the extinction of the objects: the longer the path light has to travel through the atmosphere, the more photons will be absorbed and/or scattered, not reaching the telescope. Thus, a bigger air mass means fewer photons from the object will reach the observer. Mathematically, the air mass X corresponds to the secant of the angle z formed by the zenith and the direction of the object: X = sec z.

If absolute photometry is to be performed, the observer must take into account all the mentioned effects. Observation parameters must be determined, such as nightly extinction due to air mass (Figure 3.7), calibration equations must be obtained and they have to be applied to the observations. Most of the time, photometric nights are needed for absolute photometry: a night with completely cloudless skies, and where the extinction is a simple function of the air mass. These nights only happen a few times per year at observatories, and absolute photometry should not be carried out on other nights. All of these factors make absolute photometry a very difficult process, and the type of photometry which yields the worst precision for the magnitude values.

Differential photometry or relative photometry consists in measuring not only the flux from the target object, but also from other stars, and the atmospheric effects that might be changing the value of the received amount of photons. This can be done in two different ways:

1. Using photometric standard stars. Standard stars are objects for which their absolute flux has been carefully measured and calculated, on a standard photometric system, over a long period of time and said measurements are usually available on specific astronomical catalogs. If one of these standard stars is located in the field of the image to be used, comparison between the measured flux of the standard star(s) and its known, absolute flux can be used to calibrate the atmospheric effects on the image, thus generating means to calculate the actual absolute flux of the target object, with results close to standard photometric systems.

26 2. Using comparison stars from the same field of view as the target. The magnitude of the target object is calculated relative to the magnitude of comparison stars in the field. This way, all atmospheric effects are removed from the images, since the variation will be the same for all the stars in the field. This is the simplest method for differential photometry, and also the one that yields the highest precision, especially when several comparison stars are used. The drawbacks of this method are the fact that the magnitude obtained will not necessarily be close to a standard photometric system (which is not of importance if only the variations of flux are to be studied), and also the fact that one must be very careful when choosing comparison stars, since some of them may be variable stars. The flux from the stars used to calculate photometry should be normalized, to make sure that the results do not depend on the comparison stars and different ones can be used on different images. Figure 3.9(b) shows an example of a target object, along with many comparison stars selected.

Figure 3.8 shows the difference between raw and differential photometry measurements for the same object. It is direct to see how differential photometry removes all the atmospheric effects on the measurements. The graphs are the result of performing photometry over a series of images of the same object. These curves show the variation of the light of the object over a period of time.

(a) Raw instrumental magnitude (b) Differential photometry magnitude

Figure 3.8: Comparison between raw photometry and differential photometry. Image (a) shows the raw photometric measurements of the target star’s luminosity on images taken at different times during the night. The slight upward bow in the measurements is caused by the atmospheric extinction decreasing as the object moved higher in the sky, reached its zenith, and then started getting lower again. The significant lower measurements for some points were probably caused by clouds moving through the observation field at that time. Image (b) shows photometry for the same star, using the differential magnitudes between the target and a comparison star for every image. It is clear to see how the effects of extinction and clouds are removed, giving a much clearer result of the luminosity of the target object without atmospheric interference. Images source: [12].

Whatever the method of photometry to be used, the process to obtain the actual measure- ments from the images is the same. It is important to note that because of the atmosphere, stars do not look like punctual light sources, but actually span an area of the image. This is why the most widely used photometry technique, known as aperture photometry, is carried out adding the pixel counts within a circumference centered on the target object. This is known as the aperture radius. However, photons coming from the target object will not be

27 the only ones detected in this area: the background sky of the image also contributes with photons, and they must be considered and removed from the final photon count of the target. To do this, not only the aperture radius is selected, but also a sky annulus is defined around the object. In this annulus, an average value of the nearby sky’s photon count is calculated, which is afterwards removed from the total photon count of the target. Figure 3.9 shows a target object, with its aperture radius and sky annulus selected.

(a) (b)

Figure 3.9: Aperture radius (red) and sky annulus (green) selected for a target object. Figure (b) shows the same target, along with several comparison stars selected. Although it is not pictured, the measurement of flux for the comparison stars is carried out the same way as for the target, meaning there will also be a sky annulus defined for each one of them.

Selection of both the aperture radius and the sky annulus are very sensitive parts of the photometry process. The aperture radius must be wide enough to contain the whole object, but also the least amount of sky as possible, and it should not consider objects that might be close to the target, such as another star. For the sky annulus, one must be sure that there are no stars inside, and that the area contains only background sky surrounding the target. Also, different combinations of aperture radius and sky annulus sizes can yield different results for the photometry measurements.

Photometry error

Given the fact that photometry deals with the amount of photons arriving to a particular area during a certain time, it is very important that the light curves obtained consider the associated uncertainty of the measurements. These errors can give astronomers an idea of the certainty of the performed observations.

As was explained in section 3.4.1, every astronomical image has an associated error value. The arrival of photons to the detector follows a Poisson distribution, where the random noise is represented by the standard deviation:

√ σ = N

28 In this case, N is the expected number of photons. The fact that photon arrival follows a Poisson distribution has strong implications when aperture photometry is performed. Aper- ture photometry takes an aperture radius and a sky annulus and subtracts the amount of photons, translated into digital counts, that are inside each one of them.

Since each one of the photons has an associated error, the sum of photons inside the aper- ture radius and the annulus will also have an error value. These errors must be propagated when the counts inside the sky annulus are subtracted from the counts inside the aperture radius.

3.4.4 Light curve or time series generation

Many times, obtaining photometry measurements from just one image frame is not enough for a complete analysis of the target. Variations of the photometry measurements of the same target through time can provide detailed insights about the behavior of the observed system. With multiple photometry measurements over time, a type of time series called light curve can be obtained. Light curves are valuable tools for many different areas of astronomy, such as variable star studies, supernova studies, and analysis of stars believed to have extrasolar planets around them [60,74].

Time series analysis tools [13] can also be carried out over light curves: the application of statistical and mathematical tools to a set of variable data, as a way to discover the behavior of the system. Time series analysis works by studying the variations within the points that make up a curve, looking for trends and correlations, among others.

29 Chapter 4

Introduction to General-Purpose Graphics Processing Unit (GPGPU) computing

This chapter serves as an introduction of what General-Purpose Graphics Processing Unit (GPGPU) computing is. The architecture that differentiates a GPU from a common Central Processing Unit (CPU) will be presented, as well as what makes this architecture suitable for non-graphical algorithm programming. The restrictions imposed by said architecture will also be presented, followed by a discussion of what makes an algorithm appropriate for GPU implementation.

A review of GPGPU use in astronomy is given as a means to introduce the work developed in this thesis regarding GPU implementations of certain astronomical processing algorithms. Even though a description of the general GPU implementation in this thesis is presented in this chapter, a more in depth characterization of the algorithms, as well as the technical details, data management operations, and actual implementation can be found in Chapter 5.

4.1 What is the Graphics Processing Unit (GPU)?

The Graphics Processing Unit (GPU) is an electronic circuit specialized and designed for the acceleration of image rendering in a display [53]. The GPU came to existence in the 1980s as a means to reduce the workload of the CPU in terms of image rendering. Initially, GPUs were used to accelerate computationally intensive work such as polygon rendering [1], texture mapping [71], and anti aliasing [56], among many others. Modern GPUs also support the acceleration of geometry calculations through their handling of vertices.

Regarding scene rendering, the GPU handles the complete process of turning a CPU des- cription of an image into an actual image that is ready to display. This process ranges from transforming vertices to their homogeneous coordinate representation [50] and the triangu- lation of polygons [31], to the lighting model application [19], camera position simulations,

30 texturing, pixel rasterization [61] and hidden surface handling. Not to mention that, for example in computer games, all of this must be done in real time.

It would be simply unfeasible for a sequential CPU pipeline to do all this work fast enough for a computer game to run properly. GPUs were specifically designed to handle the said processing in a parallel fashion. Because of this, the architecture of a GPU is completely different than the one of a CPU. Modern commercial CPUs are composed of around 10 cores, each one with the capacity to handle a limited number of software threads at a time. The cores of a CPU are optimized for sequential, serial processing. On the other hand, modern user-level commercial GPUs can have hundreds or even thousands of simpler, smaller, and more efficient cores, giving GPUs the ability of processing thousands of software threads at the same time.

Usually, when referring to GPU computing, the CPU receives the name of host and can be connected to several GPUs, or devices, as can be seen in Figure 4.1. This programming paradigm gives the GPU another very attractive trait over CPUs: direct scalability. Since GPU computing is data parallel, every point of data receives the same instruction to be executed, through a special program called the kernel. Every thread on the GPU will execute the instructions given by the kernel. That means that if the user wants to add more computing power to a machine, more devices or GPUs can be added to the host without requiring any changes to the code. The data will be properly distributed through the different GPU devices and the kernel will be executed in the same way as before. Such direct scaling on a CPU program would not be possible without several changes to the code.

Figure 4.1: Host (CPU) and devices (one or more GPUs) model on GPU computing.

Even though GPUs from different manufacturers vary in their hardware architecture, a general model is maintained across pretty much all graphic cards [49, 85]. Using Khrono’s Group OpenCL Specification [42] nomenclature, this model consists of a memory hierarchy formed by the global memory, constant memory, local memory, and private memory. In this same denomination, each thread is called a work-item, and work-items are associated in work-groups. Each work-item runs one instance of the corresponding kernel. A scheme of the memory model inside the devices is shown in Figure 4.2.

31 Figure 4.2: Memory inside a GPU device.

The global memory is shared by the whole multiprocessor, meaning all work-items can access it, no matter which work-group they belong to. Work-items can read from or write to any element of the global memory. Access to global memory is very slow, sometimes even hundreds of times slower than access to local memory, and thus should be used carefully. Constant memory is a special region of the global memory, and as its name says, it remains constant throughout the execution of the program. Work-items can only read from constant memory, but not write to it.

Local memory is shared within work-groups. All work-items inside the same work-group can access the group’s local memory, but work-items in other work-groups cannot access it. This memory can be used to allocate variables that will be used through the execution of a kernel. Access to local memory is much faster than access to global memory, and so it should be selected every time the program allows it. Private memory corresponds to a memory area that is private to a work-item. All variables stored in private memory cannot be accessed by another work-item, even if it belongs to the same work-group.

Work-items are accessed through the index that they occupy on their work-group. Every kernel must obtain the index of the work-item that it is going to be running on. If every work-item is equivalent to a data point, with one pixel in an image for example, no guarantees are given about the order of execution, since it is not known which pixel will be assigned to which work-item. Because of this, it is strictly necessary that the instructions executed through the kernel be the same for each data point, encompassing the GPU’s intrinsic data parallel nature. A scheme of work-items and work-groups is shown in Figure 4.3.

Because of the GPU’s unique architecture, and as can be inferred from this basic descrip- tion, modifying a CPU algorithm to run on the GPU is not always a direct procedure. The

32 Figure 4.3: Work-items and work-groups on a GPU can be accessed through indices. algorithm must first be evaluated to check if a data parallel implementation is possible and useful. Then, whatever sequential code that was inside the program must be transformed into chunks to be executed within a kernel. This is one of the main limitations for GPU implementations: not all algorithms are designed in a way that can be accelerated using a GPU.

4.2 General-Purpose GPU computing (GPGPU)

As was explained in the previous section, GPUs were designed and built to perform data- parallel computations of graphic functionalities for faster rendering. However, there are many other problems similar in nature, but not necessarily related to graphics processing, that can make use of the GPU’s properties to obtain important acceleration in execution time. General-Purpose GPU programming, or GPGPU, is the term for when the GPU is used for computations that would usually take place on the CPU.

The kind of algorithms that are well suited for GPGPU implementations are the ones which are data parallel and throughput intensive. An algorithm being data parallel means that operations can be performed over several different data elements simultaneously, and that the output from some operations does not affect the outcome of others. Being throughput intensive concerns the fact that there will be a lot of data involved, meaning a lot of procedures to be executed in parallel.

33 Nowadays, GPUs are used for tasks which used to be in the realm of high-performance CPUs. Many areas of science are taking great advantage of GPU use for their computations. For example, in the realms of biology and chemistry, parallelization has allowed faster im- plementations for evolutionary algorithms [54], DNA sequencing [76], and protein synthesis simulations [59], among many others. Applications have also surged in the area of math- ematics, including linear algebra libraries [75] and applications closer to computer science such as encryption algorithms [63].

Even though the GPU has proven to be immensely useful for calculations other than the rendering of graphics, there are still some limitations for the development of general GPU algorithms. The greatest one is the data transfer rate. The process of transferring data from the CPU to the GPU and back is still very slow, to the point that some algorithms that could highly benefit from GPU acceleration end up working faster in the CPU. It is crucial that an efficient data transfer model is implemented when GPGPU is to be used. Besides the data transfer rates and the need for an algorithm design that allows for data parallelization, there are still some precision differences between the results obtained in a GPU. Even though the differences are minimal and take several decimal places to show up, in cases where extreme accuracy of results is needed, GPGPU may still not be a reliable computational method.

Although there are still limitations in GPGPU programming, scientists across all fields are gaining knowledge about this technology that may help them achieve calculations that would have taken days on a CPU.

4.3 GPGPU use in astronomy

During the last decade, astronomy has slowly but steadily started to incorporate GPU ac- celeration for different calculations [7, 28]. Starting from the reviews by Fluke [28, 29] and Xiao et al [83], it is N-body dynamical simulations that make up most of the GPU use in astronomy, with the first implementations dating back to 2006 [26]. N-body simulations in astronomy are mostly dedicated to solving cosmological problems [16,17,32,38,43,64,65].

GPU-accelerated methods for spectra extraction have also been developed in the last decade, mostly through the implementation of data pipeline software for spectrographs [30, 83]. Radio astronomy has also benefited from GPU implementations, mostly for reduction and combination of signals coming from many different antennas in large radioastronomy arrays [18,67–69].

In terms of image analysis, deconvolution and source extraction methods are currently being implemented using GPU acceleration [51,62,79,86]. These processes are needed when the image field is too crowded with objects to perform photometric analyses directly, as detailed in section 3.4.3.

Astronomical data is thriving, observation and data analysis paradigms are changing, and astronomical software has not been left behind in terms of taking advantage of GPU acceleration. However, the astronomical community has been slow at accepting this new way

34 of parallel programming, and there is still a lot of work to do and applications to design that make use of this technology.

4.3.1 GPGPU use for astronomical data analysis in this thesis

As was mentioned in section 4.2, the algorithms best fit to be implemented on a GPU are streaming algorithms, where there are highly data parallel computations but with little reuse of input data [27].

In a first approach, matricial operations concerning the astronomical data reduction pro- cess such as the subtraction and division of Master calibration (section 3.3) files seem like procedures that could be directly implemented through a GPU kernel. The fact that these operations are performed pixel to pixel and are not dependent on data changes makes the algorithms highly data parallel and throughput intensive. However, it is likely that the need for intense data transfer between the CPU and the GPU in the reduction process makes this process not so fit to run on the GPU.

This thesis also analyzes the subject of accelerating light curve obtention (section 3.4.4) through GPU implementations. For this, a way to reduce the amount of data transferred between the CPU and the GPU was designed. Taking advantage of the fact that light curve obtention only requires a small portion of the image to be analyzed, a GPU approach is implemented and tested in this thesis. The details of the algorithm implementation for this purpose can be found in section 5.4.4.

It is probable that the reason why the GPU has not yet been exploited much in terms of astronomical data processing has to do with the current slow data transfer rates between devices. However, considering the quick development of the big data era and the jump to the new, survey-driven observational approach in astronomy, quicker ways to process and analyze data will have to be developed and incorporated in astronomical data pipelines. Considering the GPU’s great scalability properties commented in the previous section, even though right now the advantages of using GPU acceleration for small datasets may not be substantial, the future will require redesigned astronomical software to enforce parallelization. It is within this context that this thesis analyses GPU implementations for reduction and light curve obtention, seeking to answer the two research questions posed in section 1.3.2:

Q1: Is it possible to obtain significant GPU speed up in astronomical algorithms that deal with a large amount of data transfers between CPU and GPU? Q2: Are these speedups justified? In other words, is the obtained acceleration worth it considering the extra implementation that GPU algorithms convey?

35 Chapter 5

Software design and implementation

This chapter presents an outline of the complete functioning of FADRA’s currently imple- mented data structures and functions. Since every section of the pipeline was implemented as separate Python modules, FADRA can be used as an imported package through an in- teractive Python shell (such as iPython), or the packages can be imported into a separate Python script.

The present chapter begins by introducing the objects used by FADRA to handle the data from the astronomical images. Then, the processes of calibration image obtention and astronomical image reduction are presented. The light curve obtention procedure designed for FADRA is then presented.

5.1 Data handling: AstroFile and AstroDir classes

Data within the FADRA framework is handled by using the implemented AstroFile and AstroDir objects. AstroFile and AstroDir objects do not store the image data itself, but rather the filename and path to the corresponding .FITS image, working more as pointers than as data containers. This design looks to save memory by not keeping every .FITS image file open at all times. Files are opened and data is accessed only when operations over images are to be carried out.

The AstroFile and AstroDir objects are part of the dataproc Python package, a previous implementation developed by Professor Patricio Rojo, as was mentioned in section 1.3.4. The dataproc package is a requisite for FADRA, since the latter uses AstroFile and AstroDir objects directly to handle files. The implementation of these objects was not modified, and thus below follows the details on how they operate within the framework.

An AstroFile object contains the path to the original .FITS file, in string format. When an AstroFile is initialized, the referred file is checked to correspond to a valid .FITS file. An AstroFile can also contain one flat and one dark field corresponding to the calibration files of the specific image. The AstroFile class also contains functions to read and assign

36 values from the image’s .FITS header, and to read the data from the image.

The data of an AstroFile can be read through the reader function of the class. When the data or header of an AstroFile is to be read, the Python package PyFits1 is used. The PyFits package opens the .FITS file contained as a filename on the AstroFile. Both the data and the header from the open file are then available as SciPy arrays, allowing for immediate processing in Python. The PyFits package is also used when writing data to a .FITS file or editing a header value.

The AstroDir object serves as a container for AstroFile objects. An AstroDir can be initialized directly with a list of AstroFile objects, or it can be given a path to a directory, in which case AstroFile objects are created for every file on the directory and added to the AstroDir. An AstroDir can also have associated dark and flat fields, which can be used to reduce all the contained AstroFiles at once. Only one file of each calibration field type is allowed for each AstroDir. In the case that whole directories of calibration images are to be used, the corresponding MasterDark and MasterFlat fields must be obtained and then added to the desired AstroDir . The AstroDir class provides the readdata function, which reads the data from every AstroFile through AstroFile’s reader function, which was explained above.

The AstroDir class also provides a sorting function, to sort the AstroFile objects according to a given header parameter. A filter function is also provided, returning only the AstroFile objects that match the given condition for header parameters.

The direct addition of two or more AstroDir objects will yield a new AstroDir object which contains the AstroFile objects of all the added AstroDir objects. Other mathematical operations between AstroDir objects are not permitted.

5.2 Calibration image combination and obtention of Master fields

As mentioned in section 3.3, astronomical image reduction requires two kinds of calibration images: dark and flat fields. Although in most astronomical observation runs many different images of each of these kinds are obtained, the reduction process requires only one dark field and one flat field. These are usually referred to as MasterDark and MasterFlat, respectively, and are obtained from the combination of all the images of each kind.

As explained in section 3.3, there are different ways to combine said images and obtain the Master calibration fields. In the case of the flats, they can simply be combined using mean or median combining functions (or any other desired combining function). In the case of dark fields, they can be combined directly or calculated for a specific exposure time. This thesis implements both the direct combination of calibration fields and the interpolation of dark fields according to a given exposure time.

1http://www.stsci.edu/institute/software hardware/pyfits

37 Figure 5.1: The AstroFile and AstroDir classes

This thesis implements two strategies to combine calibration fields to obtain the corre- sponding Masters: a mean combining function and a median combining function. Both are implemented in the CPUmath package as mean combine and median combine respectively. Each one of these functions receives, as input, a SciPy array with the data of each file. If the files are originally contained in an AstroDirs, the data from the AstroDir must be extracted and then passed to the combine function as a parameter. This, because the CPUmath package is intended to be useful for any kind of file, not just AstroFiles or AstroDir objects.

The input files are first checked to see if they are all of the same shape, otherwise a warning is issued to the user and the combination is not carried out. When all files are of the proper shape, mean and median combining procedures are executed along the z axis. This stacks all the images together according to the selected function. The combined Master image is returned as a SciPy array, which can be saved and stored as a AstroFile.

Even though mean and median combining functions were implemented for this matter, the implementation of the Master field obtention routines, which are respectively get masterdark and get masterflat, allow for the user to explicitly give the algorithm a combination func- tion as a parameter. This allows the user to define their own way to combine the images, with no limitations or restrictions other than that the function should return files that are of the same shape as the raw science images. This thesis recommends mean combine and median combine, but the user is also allowed to pass their own combining function as a parameter of the routines. If no function is given, mean combine is used as default.

The case for the obtention of the MasterDark field is different from the previous cases, as was explained in section 3.3. Even though the option to directly combine all the dark fields is given in the get masterdark function, most of the time the astronomer desires to interpolate or calculate a specific dark field for a given exposure time, since this would be the dark field

38 that correctly reflects the amount of instrumental noise during the image acquisition time. For this matter, the get masterdark function receives the desired exposure time as one of its input parameters. First, all the given dark field files are scanned to get their corresponding exposure time. If one file is found to have the same exposure time as the desired value, this file is immediately returned as the MasterDark. If, however, no file of the exact wanted exposure time is found, a linear interpolation is carried out to artificially generate a dark field of said exposure time, which is then returned as the MasterDark. If the exposure time argument is not given to get masterdark, all the dark field images will be combined as in the cases for the MasterFlat, and exposure time will not be considered. It is up to the user to decide which method is of better use for their specific data.

Since the combining functions are used within the routines to get the Master files, the functions get masterdark and get masterflat receive as input an AstroDir or SciPy array with the files, the combining function to be used (mean combine is used as default if no option is given) and, in the case of get masterdark, the desired exposure time as an optional parameter.

The routines get masterdark, and get masterflat can be found in the reduction pack- age. mean combine and median combine can be found in the CPUmath package.

5.3 Astronomical image reduction

Image subtraction and element-wise division are image arithmetic procedures vital to the image reduction process, as explained in section 3.3. These can be thought of as operations between matrices, since each grayscale astronomical image is essentially a matrix where each value corresponds to the gray value on the said pixel.

This thesis implements astronomical image reduction for full images, in CPU and GPU versions. Both of them receive as input: an AstroDir of the raw science files to be reduced, an AstroDir related to the path were the reduced files are to be saved, and the Master calibration files. If the Master files have already been calculated, they can be passed as separate parameters or related to the input raw images AstroDir. If AstroDir objects are passed as parameters for Masters instead of AstroFile objects or SciPy arrays, the files in AstroDir objects will be used to calculate the Masters through the procedures explained in section 5.2. In this case, the function to use for the combination and the desired exposure time for the Masterdark must also be given as input parameters. The default combining function, to be used if no other specific function is given, is the previously introduced mean combine.

The use of CPU or GPU reduction procedures is determined by a GPU flag given to the reduce funtion. GPU=True will run the GPU version of the reduction, while the value False (default) will run the CPU reduction.

39 5.3.1 CPU reduction implementation

The CPU implementation of arithmetic operations between images is found in the package CPUmath. Subtraction and element-wise matrix division were implemented using SciPy’s operations between n-dimensional arrays. The data from the AstroFiles is read as needed and stored as a SciPy array while in use. Each file is opened only when needed and closed immediately after the relevant data has been fetched.

An additional step performed to the results of reduction corresponds to sigma-clipping2. Sigma clipping is a method used to prevent high peaks in data. In the case of astronomical images, extremely high or low values in certain pixels might correspond to defective pixels in the detectors, or to cosmic rays hitting the detector during the image acquisition process. These pixels should be removed before carrying out scientific analysis over the images. After the images are reduced as was explained in section 3.3, the images go through a sigma-clipping function, with the default cut out value of 3σ.

5.3.2 GPU reduction implementation

The GPU reduction algorithm receives an AstroDir of raw science images as input. Each raw science image is then flattened down to a one-dimensional SciPy array. This can be done because knowing the (pixel) size of the images allows for each work-item to be mapped to a pixel on the raw images and on the calibration files. The number of images to be concatenated and passed to the kernel is defined by the global memory size of the device. If it is not possible for all the images to fit in the devices’ memory, the kernel is called in as many iterations as needed. Each one of the calibration fields is also flattened to a one-dimensional array separately. This flattening process is done on CPU and then given as input for the GPU kernel.

The reduce.cl OpenCL kernel receives these arrays as input, as well as the original dimensions of the images, to correctly advance through the arrays indexes and make sure that the 1D operation is exactly equivalent to the direct, 2D one. The calibration arrays are passed to the GPU’s constant memory, while the image arrays are passed to global memory. Each work-item is then mapped to one pixel (one value in the one-dimensional array of images) and performs the subtraction and division with the calibration constants.

After the results are copied back to the CPU, the arrays are reshaped to the original shape of the images, which are then run through the sigma-clipping algorithm explained in the previous section, saved to disk, and added into a new AstroDir , which is returned as output of the reduction process.

2Sigma-clipping corresponds to the process of iterating through the data, rejecting data points that are above or below a specified number of standard deviations (σ). An  value can also be given as a threshold for the process.

40 5.4 Light curve obtention: the Photometry object

The light curve obtention algorithm implemented in this thesis does not make use of the astronomical image reduction process explained in the previous section. Reducing hundreds of whole astronomical images results in a loss of memory and a longer computation time, though for the light curve obtention only a few pixels on each one of the images are needed. For this reason, if the user wishes only to reduce full astronomical images, the procedures described in section 5.3 should be used. If, however, the user does not need to reduce all the images but only wishes to obtain the light curve from their data, a different procedure is carried out, which is detailed in the present section.

To handle light curve obtention, the Photometry object was created. A Photometry object is initialized with all the parameters needed to carry out aperture photometry though the process devised in this thesis. A scheme of the Photometry class is shown in Figure 5.2. The parameters will be clarified as the different stages of the process are explained in the following sections.

Figure 5.2: The Photometry object. The functions and parameters will be explained in the follow- ing sections.

41 5.4.1 Data handling for light curve obtention

The current astronomical image processing paradigm, implemented by IRAF (currently the most widely used astronomical data analysis software) and others, considers the following steps:

1. Read raw image from disk. 2. Reduce image following steps in section 3.3. 3. Save reduced science image to disk. 4. Each time scientific analysis is to be carried out over a reduced image, read said image from disk.

This approach presents several problems:

1. Each image is read from disk, reduced, and saved to disk. In cases where lots of images are available (which is usually the standard for astronomical observation runs), this pre-processing can take a long time and take up lots of memory during computation. 2. There might not be sufficient disk space available to save all the reduced images. 3. Some images might be reduced, but never considered for analysis, thus having wasted computation time on images which are never to be used.

The software implemented in this thesis follows a paradigm designed for faster and more efficient processing and analysis. The obtention of light curves is based on the use of stamps: to obtain a light curve, only a few targets from the complete astronomical images are used. This software does not pre-process the whole images, but only the “stamps” surrounding the target stars. This makes it possible to handle light curves with lots of image frames, something that may not be possible when having the full astronomical images available in memory. Reduction is also done as needed: when the user has selected the images to use and the corresponding targets, reduction is performed only in the target stamps.

This approach is based on the system used by the Kepler space telescope3. The Kepler space telescope is dedicated exclusively to the observation of stars believed to have extrasolar planets around them. The telescope has a very large field of view, 105 square degrees. In comparison, the fields of view of even the biggest telescopes in the world are around one square degree. This means that each image obtained with the Kepler space telescope may contain hundreds of targets. Because of this, the Kepler Data Search and Retrieval4 interface used to obtain scientific data from the telescope returns only a handful of pixels surrounding each star on the target list given by the user [45]. The users obtain only stamps with their relevant targets, this way making data transfer and further analysis more efficient. A similar stamp approach is used in [51] to implement GPU-accelerated source extraction in astronomical images.

In the case of this thesis, the stamp approach also serves as a way to optimize the GPU implementations of the algorithm. Data transfer between the host and the device is a time-

3http://kepler.nasa.gov/ 4http://archive.stsci.edu/kepler/data search/search.php

42 Figure 5.3: Example of data stamps for aperture photometry. Instead of using the full, 1024×1024 pixels image, the stamps of size 100×100 pixels each are used to obtain the photometry measure- ment. critical operation, and should be reduced as much as possible. When using full astronomical images, lots of information that will not be useful in the process is passed back and forth between host and device, making the process very inefficient, and in many cases the data transfer rate can even overshadow the gains in execution time obtained with the use of GPU. By using only the data around the relevant targets, each data transfer to the GPU is moving only the data that is strictly necessary.

5.4.2 Obtaining target data stamps

For the specific case of light curve obtention through aperture photometry, the use of the complete astronomical images is not necessary. Aperture photometry requires only the area of the image that contains the target star, and a border around it to obtain the measurement of the sky background. Given that the coordinates of the targets must be introduced by the user to do aperture photometry, images can be pre-processed to obtain only the relevant “stamps” around the desired targets. This way the reduction and photometry procedures deal only with the strict amount of data necessary. This decrease in the amount of data to be read and analyzed is highly significant for GPU processing. The data transfer rates between

43 host and device can be very slow, therefore moving the least amount of data or doing it more efficiently is optimal. Using only the data from the stamps around the needed targets is a way to optimize the GPU computations implemented in this thesis.

Initially, the user has to input the coordinates corresponding to the desired target, as well as other reference stars for differential aperture photometry (section 3.4.3). In an ideal setup, these initial coordinates would be enough to obtain the targets’ stamps for all the other images in the observation run. However, telescopes are not perfect instruments, and many times there are shifts in the positions of the targets. Most of the time these shifts are only a few pixels total, but in the case of photometry, we must be assured that the target will always be centered on the corresponding stamp and inside the given aperture radius. If, for example, a big enough shift happens causing part of the target to be out of the aperture radius, the photometry measurement will be incorrect.

To deal with this problem, the initial coordinates given by the user are used only as a starting point. The first stamp is calculated using the said coordinates. The centroid of the first stamp is calculated. For the next stamps, the coordinates to use will be the coordinates of the centroid. The process follows not the given coordinates, but the centroid of the target on each image. This way, even if there are pixel shifts between images, the aperture radius and sky annulus will always be centered on the target.

Figure 5.4: Series of data stamps following the centroids of two different targets

As mentioned in section 3.4.3, aperture photometry requires the definition of a sky annulus around the desired target. Sufficient space for the sky annulus must be considered when obtaining the stamps. The user must define not only the coordinate where the initial stamp will be centered, but also the “square radius” of the stamp, which will be the space left between the center of the stamp and each one of its borders. This radius must be enough so that the sky annulus fits completely inside the stamp.

Before doing the data reduction and photometry, the pipeline obtains the stamps for every target through all of the image frames. Each target generates the same number of stamps, and on the same time stamp measurements. If there are n targets and m total images, n data-cubes are then returned, where each cube has m elements, each one of shape (2 ∗ stamp rad, 2 ∗ stamp rad).

44 Figure 5.5: Parameters of the data stamp for aperture photometry

5.4.3 Reduction process using stamps

As was explained in section 3.3, all astronomical images must be reduced before carrying out scientific analyses over them. Since the reduction is a pixel-wise operation, it is critical that each one of the stamps is reduced with the exact corresponding stamps of the calibration files.

For this, the coordinates used as center of the stamps obtained in the previous step (through following the centroid) are stored in a list. To reduce an individual stamp, a stamp of the same size and centered in the exact same position is obtained from the calibration fields. These calibration stamps are then used for the reduction of the corresponding data stamps.

The reduction process is carried out right before the photometry calculation. This way, if the user decides a stamp or target is not to be used for some reason, such stamps will not be unnecessarily reduced. The reduction process is executed only when it is certain that the corresponding stamp will be used for the light curve to be obtained.

5.4.4 Aperture photometry

Aperture photometry is then carried out over the reduced stamps, in the same way that it would be done if a full image was used. Slightly different processes are implemented for CPU and GPU photometry.

45 CPU Photometry

The first step is executing the data reduction, with the corresponding stamps from the MasterDark and MasterFlat calibration files.

After a stamp is reduced, the photometry measurement inside the aperture radius is obtained. To obtain an estimation of the sky background, a polynomial fit is calculated inside the sky annulus. The least squares method is used to fit a polynomial in the annulus, of a degree given by the user, although the default degree is 1. The obtention of this fit is implemented using SciPy’s optimize module. Once the sky background has been estimated, this value is subtracted for the photometry measurement obtained inside the aperture radius, as a means to obtain only the amount of luminous flux coming from the target object.

The implementation developed to obtain the aperture photometry with the CPU algorithm was part of the previous work developed by Professor Patricio Rojo, as commented in section 1.3.4. The changes made to this previous implementation correspond to the adaption to work with the data stamps instead of full images, which included adding a specific reduction process for each stamp (since for each stamp, corresponding stamps from the calibration images are obtained, as explained in section 5.4.3), and the integration of the algorithm to be part of the Photometry module designed and implemented for this thesis.

GPU Photometry

All the stamps for the corresponding target, along with one MasterDark file and one Master- Flat file, are given as input to the GPU kernel. This kernel also receives the desired aperture for the photometry, the radii for the sky annulus, and the size of the stamp. Passing data to the GPU is done in the exact same way as for the data reduction explained in section 5.3.2: the number of stamps given to the GPU in each iteration is calculated depending on the global memory of the device. The data stamps and calibration files are then flattened into 1-dimesional arrays and passed to the GPU.

Inside the kernel, the photometry measurement is calculated by adding the counts of the pixels inside the aperture radius. A pixel is said to be inside the aperture radius if its distance to the center of the stamp is less than the said radius. The value of the sky is calculated as the average count number inside the sky annulus. This average result, multiplied by the number of pixels inside the aperture radius, is subtracted from the photometry measurement as a means to subtract the effect of the sky background.

X Photometry value = Counts inside aperture radius  P Counts inside sky annulus  Number of pixels inside (5.1) − ∗ Number of Pixels in sky annulus aperture radius

The output of this GPU kernel corresponds to a 4-element vector where the values of interest are saved to each element: the photometry calculated inside the aperture radius, the

46 number of pixels inside the aperture radius, the total photometry calculated inside the sky annulus, and the number of pixels inside the sky annulus. These four values are returned for every stamp, and then equation 5.1 is carried out on the CPU once the results are copied back. However, since many work-items will be writing to the output buffer at the same time, synchronization between work-items is necessary to avoid data race conditions during the calculations. In this case, since the operations performed by the kernel correspond only to subtraction, division (for the reduction part of the process) and addition to calculate the photometry values, atomic functions5 were used inside the kernel. OpenCL’s atomic functions provide synchronization and avoid data race conditions. The only drawback is that OpenCL only supports atomic functions for 32-bit integers. Because of this, the photometry measurements calculated in the GPU are integer values.

5.4.5 Light curve data handling and visualization: the TimeSeries object

After aperture photometry is carried out for a series of targets and images, and the light curves for the different targets are obtained, the light curve is visualized. As explained in section 3.4.3, differential aperture photometry contemplates performing operations between light curves for different targets, as a means to reduce atmospheric effects over the curves.

In order to easily store and access the results of the light curves, and to allow for operations between different target light curves, a separate class for the handling of aperture photometry results, TimeSeries, was implemented.

Figure 5.6: The TimeSeries class

A TimeSeries object can contain several channels, where each channel is the result of aperture photometry carried out on one target over a period of time. The number of channels

5https://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/atomicFunctions.html

47 corresponds to the number of targets in the image over which aperture photometry was carried out, and the number of elements in one channel corresponds to the number of images in the light curve. All channels within one TimeSeries object must have the same length.

Besides having data channels, a TimeSeries object can also contain a group of error chan- nels, where each element of an error channel corresponds to the error on the corresponding photometry measurement. Each data channel has its own, corresponding error channel. Both kinds of channels are implemented simply as SciPy arrays. A TimeSeries object also receives an optional labels parameter, which should be a list with the names or tags of the targets to be referenced. There should be as many names in the labels list as data channels in the TimeSeries .

Data channels within a TimeSeries can be accessed as items on a list. For example, if we have the TimeSeries object ts, calling ts[0] would return the first data channel of the TimeSeries as a SciPy array. If the labels parameter is given, the data channel can also be called using the target name, for example ts[’target1’].

The data channels on a TimeSeries can be divided into two groups. This, since most of the time the main target will be one of the data channels, and the other targets will be used to perform differential aperture photometry, as explained in section 3.4.3. By default, a newly initialized TimeSeries comes with the first data channel (assumed to be the first target) as the first group, and the rest of the channels together as the second group. The user can assign the groups to their own liking by using a mask. For example, if ts is a TimeSeries with five channels, the expression: ts.set_group([1,1,1,0,0])

...asigns the first three channels to the first group, and the other two channels to the second group. The 1s in the mask will always correspond to the first group. set group also sets the grouping for the corresponding error channels. Groups in a TimeSeries can be accessed with ts.group1() and ts.group2(), and the error groups with ts.errors group1() and ts.errors group2(), correspondingly.

Mathematical operations can be carried out between the channels of one group. This thesis implements the calculation of the mean and the median of the channels of the group. The results are stored in two “hidden” channels, ts[-1] and ts[-2], corresponding to the results of the operations on the first and the second group, respectively. The corresponding “hidden” error channels store the error regarding the operation. The mean and median implemented functions receive the group id (1 or 2) as input. The data and error channels on the groups are not modified with these operations, however, corresponding error “hidden” channels with the errors of the operations are also obtained.

Operations are also allowed between channels. For example, ts[0]/ts[1] returns the division between the first and second channels of the TimeSeries . These results, however, are not stored in hidden channels as the group operations. These operations allow for the removal of atmospheric effects by the use of differential photometry, as explained in section 3.4.3.

48 5.5 Graphical User Interface

The FADRA framework also provides a wrapper class to access the light curve obtention process through an interactive GUI. The GUI allows the user to choose the raw and calibration files to be used, as well as the aperture radius and other parameters relevant to light curve obtention explained in previous sections. When starting from scratch (the case when no working directories have yet been created or loaded), the user begins by creating:

ˆ An AstroDir object with the science image files ˆ A Masterdark and a Masterflat field files, as AstroFiles ˆ A TimeSeries object, initialized as empty ˆ A path to store the work environment files described above

When initializing a work environment, the user is prompted to select the corresponding path for science, dark, and flat files. The Master calibration files will be obtained from the corresponding dark and flat files contained in the given paths. The user can then select the method to combine the calibration files and obtain the Masters. A drop-down menu contains all the combination options for the used to choose. For now, the default combination modes are mean and median functions. However, if the user creates their own functions and adds them to the CPUMath package, they will be shown in the menu as well. These functions and how calibration files are combined and Master calibration images obtained is further explained in section 5.2.

Figure 5.7: GUI for AstroDir creation

In the case of Masterdark obtention, the exposure time of the images to be analyzed is needed, as explained in section 3.3. For this, the exposure time of the first file on the science images folder will be obtained and used for the calculation.

If the Master calibration files have already been generated, the user can select the files instead of paths. The selection of an output path to save the reduced astronomical images is also optional, and only needed is the user wants to reduce the complete set of astronomical

49 images, as was explained in section 3.3. If the user wishes only to obtain a light curve from the images, giving this path is not necessary.

After an AstroDir has been created or loaded, the window shows a list of the current open AstroDir objects. Next to each AstroDir file, three different buttons are shown: one to view the TimeSeries (if the corresponding TimeSeries object has already been calculated), one to obtain TimeSeries , and one to delete the selected AstroDir.

Figure 5.8: GUI showing loaded AstroDir objects

When the user chooses to obtain the TimeSeries from a given AstroDir , a new window opens showing the first image from the given science images path. This window gives the user the option to show the image in different scales. In this GUI, the user can click on as many target points as they wish. Every time a point is selected, the list of points to the right is updated with the coordinates of the point and a text box, where the user can assign a name for the corresponding target. The user can also delete points through the interface.

Figure 5.9: GUI for photometry targets selection

50 The first point on the list will be considered as the target, and the rest of the points will be considered as reference stars. After all the desired targets have been selected, pressing the ‘CONTINUE’ button opens up a new window which shows the selected target. This GUI lets the user select the photometry and sky annulus radii for the aperture photometry (as explained in section 3.4.3) as well as the size of the stamp to be used in the aperture photometry algorithm. The radii and stamp sizes selected here will be used for every other target in the image.

Figure 5.10: GUI for aperture photometry parameters selection

After parameters have been selected, pressing the ‘Obtain light curve’ button starts the calculations. After aperture photometry has been performed and the corresponding light curve obtained, a plot of the curve is shown, and the values are saved in a file associated with the current AstroDir. The light curve itself is handled by the TimeSeries class.

Figure 5.11: An example of the visualization of the light curves obtained for one set of images with one target star and one reference star.

51 Chapter 6

Experimental settings

The experiments carried out in this thesis serve three different purposes. The first one is to validate that the results obtained with FADRA’s implementation of algorithms are correct. The second one is to compare the light curves obtained using FADRA’s CPU and GPU implementations, to make sure that the algorithm for GPU light curve obtention described in section 5.4.4 yields correct results. Finally, the third purpose of the experiments is to compare the execution times between the CPU and GPU implementations of FADRA algorithms. These experiments address the research questions laid out in section 1.3.2.

The different settings for the experiments are detailed in the following sections, as well as the metrics used to compare the results in the different cases and the details of the datasets used. Results of the experiments carried out within these settings are presented in Chapter 7.

6.1 Validation of results

The first stage of the experimental part of this thesis corresponds to the validation of re- sults obtained with FADRA. This stage is composed of three different experiments: the first one deals with the validation of the results obtained in the reduction process (section 3.3). The second experiment deals exclusively with light curves, and encompasses the comparison of the FADRA light curves against curves obtained with established astronomical software. The third and last experiment compares light curves obtained using FADRA’s CPU imple- mentation with the ones obtained using FADRA’s GPU photometry implementation. The following sections describe three experimental stages as well as the metrics used to compare the results.

52 Dataset ID Number of images Image size (pixels) Image size (MB) Exposure time (s) 1 73 1024 x 1024 2.3 200 2 140 1024 x 1024 2.3 20 3 162 1024 x 1024 2.3 30 4 172 1024 x 1024 2.3 25 5 254 1024 x 1024 2.1 25 6 297 1024 x 1024 2.1 10

Table 6.1: Datasets used for experiments

6.1.1 Experiment 1: Validation of reduction results

To confirm that the results obtained with the algorithms implemented in FADRA are correct, they must be compared against results obtained with established astronomical software. The algorithms tested in this stage correspond to the reduction algorithms, both in CPU and GPU implementations.

To obtain a gold standard for comparison against FADRA’s results, the processes were first carried out using AstroPy’s ccdproc module (section 2.1.2). The ccdproc1 module is designed specifically to perform basic processes over astronomical images, such as reduction and image combination for Master calibration file obtention. The validation experiments were carried out over 6 datasets of real astronomical images. The details of each dataset can be found in Table 6.1.

The results from FADRA’s CPU reduction implementation were compared against the reduction results obtained with ccdproc and the results obtained with FADRA’s GPU re- duction algorithm.

Similarity metrics

To test if the results obtained with FADRA are correct according to the ones obtained with AstroPy, the similarity between the resulting images in both cases must be measured. For this purpose, the Root Mean Square Error (RMSE) was used.

The RMSE value measures the difference between a predicted value and a real, observed value. In the case of comparing FADRA results against established software, the results obtained with AstroPy were considered as the predicted value or gold standard for the com- parison, and the results obtained with FADRA were considered as the observed values. When comparing FADRA’s CPU and GPU implementations, the CPU results were used as the pre- dicted value, and the GPU results were considered as the observed values. The RMSE is calculated as follows: 1http://ccdproc.readthedocs.io/en/latest/

53 r n P (ˆy − y )2 RMSE = i=1 i i (6.1) n

wherey ˆi corresponds to the predicted value and yi corresponds to the observed value.

However, this definition of the RMSE yields values that are scale-dependent. Since the intent behind these experiments is not to measure the specific value of the RMSE for each different dataset, but to comprehend the general behavior of the FADRA implementation, the normalized version of the RMSE (NRMSE) was used. For each frame, the NRMSE is calculated as follows:

RMSE NRMSE = (6.2) ymax − ymin

This way, the values obtained for the similarity of the images within the same dataset will not depend on differences between the datasets themselves, providing a broader view of FADRA’s performance. The NRMSE is scale-independent and expressed as a percentage where low values indicate less residual variance.

The NRMSE between each pair of images to be compared was calculated. First, between the corresponding images of the results of reduction obtained with ccdproc and FADRA CPU; then, between the corresponding images obtained with FADRA’s CPU and GPU im- plementations. For each dataset, the NRMSE values obtained for each pair of images was averaged.

6.1.2 Experiment 2: Light curve evaluation

The first experiment regarding light curves consists in their evaluation again results obtained with established astronomical software. In this case, again AstroPy was used to obtain the photometry measurements, through its package photutils2. The photutils package is an in-development module associated to AstroPy which provides source extraction3 and aperture photometry tools. Their aperture photometry function was used within a Python script, since it only allows for photometry calculation of one image at a time, for which aperture and coordinates must be given in every iteration.

The datasets used for this experiment are the same as for experiment 1, and the details can be found in Table 6.1. 2http://photutils.readthedocs.io/en/latest/index.html 3Source extraction corresponds to the process of identifying the astronomical objects before performing aperture photometry. This must be done when the image field is very crowded and stars can not be easily identified or separated from their neighboring stars.

54 Similarity metrics

When evaluating the similarity of two light curves, what matters the most is not that the numerical difference between the curves is small, but also that the variations between the points forming each curve are consistent. Since time series analysis deals with the variations inside the curve, it is crucial that the differences between points belonging to each curve are the same.

As a first approach to this, the standard deviation would seem like a good way to mea- sure the similarity between the curves. However, two curves could have the same standard deviation and still be very different. A better way to prove that the differences between the points of the two curves are consistent is to show that one curve simply presents an offset displacement from the other one. If all the points in the second curve turn out to be an additive or multiplicative offset of the first curve, then the two curves can be considered to be the similar enough in terms of internal behavior for the same astronomical analyses to be carried out over them.

This means that what should be confirmed is the following relationship:

(yi =y ˆi + α) ∨ (yi = βyˆi) (6.3)

wherey ˆi are the points in the first curve (in this case, the one obtained with AstroPy) and yi are the points in the second curve (the one obtained with FADRA’s CPU implementation). The values α and β correspond to the additive or multiplicative offsets, respectively. It is important to mention that the α or β values must be the same for all the points inside the curves being compared, but can be different between different pairs of curves from other comparisons. A dataset must have a consistent α or β value all through its two light curves, but said values can change between different datasets.

If an α or β offset parameter can be found to be the difference between them, then the two curves are said to be the same in terms of what astronomers need.

6.1.3 Experiment 3: Comparison between FADRA’s CPU and GPU photometry implementations

Once the results obtained with FADRA’s CPU photometry implementation are proven to be similar to AstroPy’s, the next step is to compare the said results against FADRA’s GPU implementation to confirm that the aperture photometry approximation explained in section 5.4.4 also yields correct results. For this, the same datasets from the previous experiments (Table 6.1), but now considering all the image frames, were used to obtain their corresponding light curves, both with the CPU and the GPU algorithms. These results were then compared with each other.

55 Similarity metrics

The similarity metrics for the curves in this experiment are exactly the same as presented for experiment 2. The only change is that, instead of comparing AstroPy results to FADRA’s CPU results, the results from FADRA’s both CPU and GPU implementations of the light curve obtention algorithm will be compared against each other. An additive or multiplicative offset is to be found between the curves to prove that they have the exact same behavior. This is a good enough indicator that the same astronomical analyses can be carried out over the curves.

6.2 Execution time comparison

Once the results are validated, the speedup provided by the GPU implementation of the algorithms is to be calculated. For this, the execution time of the reduction and light curve obtention procedures will be measured for FADRA’s CPU and GPU implementations.

The execution times will be measured using Python’s function clock from the time mod- ule. The clock function returns processor time and is recommended in Python’s documen- tation as the function to use when benchmarking Python or timing algorithms4.

6.3 Platforms

The experiments carried out on this thesis were performed on an Intel Core i5-3337U CPU @ 1.80GHz x 2 with 3.6 GB memory, and an Intel 3rd Gen core GPU running Intel HD Graphics 4000 with 2048 MB memory. OpenCL was run on the GPU by using the drivers provided by the Beignet project5.

4https://docs.python.org/2/library/time.html#time.clock 5https://01.org/beignet

56 Chapter 7

Results

This chapter introduces the results of the experiments detailed in Chapter 6. The first stage of the experimental part of this thesis corresponded to the validation of the results obtained with FADRA’s implementation. For this, experiments were carried out to compare reduction results obtained with FADRA against reduction results obtained with established astronomi- cal software. The results of FADRA’s photometry and light curve obtention algorithms were also evaluated. The results of FADRA’s CPU photometry implementation were compared against light curves obtained with other astronomical software. Then, FADRA’s CPU and GPU light curve obtention algorithms were compared against each other to make sure that the photometry approximation given in section 5.4.4 is correct.

Once the results from the FADRA implementation were proven to be correct, experiments were run to compare the execution times between FADRA’s CPU and GPU algorithms. This tells us if the implementation of GPU procedures for reduction, photometry, and light curve obtention for astronomy algorithms is justified, and takes into account the intensive data transfer between host and device that working with astronomical data signifies.

The conclusions and analyses of the results here presented are further expanded and commented on Chapter 8.

7.1 Validation of FADRA results

7.1.1 Experiment 1: Validation of reduction results

As was detailed in section 3.3, reduction of astronomical images is a vital step for any kind of scientific analysis to be performed over said data. Because of this, it is necessary that FADRA reduction functions return very exact results when compared to established astronomical software, to make sure that the further processes to be carried out in the framework are run on a correct base.

57 The software used to evaluate FADRA’s reduction results, as mentioned in section 6.1.1, was AstroPy’s ccdproc package. The Normalized Root Mean Square Error (NRMSE) de- tailed in section 6.1.1 was used as the metric to compare the images. The results from FADRA’s CPU reduction implementation were also compared against FADRA’s GPU re- duction results, to make sure that both algorithms provide correct outcomes.

The calculated NRMSE for the comparison between ccdproc results and FADRA CPU re- sults is presented in Figure 7.1. The comparison between FADRA’s CPU and GPU reduction results is presented in Figure 7.2. The NRMSE was calculated between each corresponding pair of images in the datasets being compared, and the average of the said value for each dataset is presented in the mentioned figures. The detailed results used to obtain the figures can be found in Appendix A.

Figure 7.1: Normalized Root Mean Squared Error between the reduction results obtained with AstroPy’s ccdproc package and FADRA’s CPU reduction algorithm. The datasets on the x-axis are arranged from lower (left) to higher (right) number of images.

As can be seen in Figure 7.1, the NRMSE between AstroPy’s ccdproc and FADRA CPU results is below 1% for every dataset, meaning that the average difference between the com- pared images in each dataset is less than 1%. Considering that the astronomical image reduction process is very straightforward and does not allow for really different implementa- tions (section 3.3), such small differences were expected due only to the precision differences between calculations. It can be seen, however, that only datasets 2, 4, and 6 present NRMSE values that could be explained only by precision differences, while datasets 1, 3, and 5 present higher NRMSE values. To make sure that the reduction process works properly, and that those higher NRMSE values are because of properties intrinsic to the images, the mean, median, and standard deviation values for each image were calculated and averaged for each

58 dataset. The results are presented in Table 7.1.

FADRA CPU (pixel flux counts) Dataset Mean Median Standard deviation 1 320.711 ± 62.208 305.555 ± 59.887 695.251 ± 108.873 2 511.098 ± 72.426 514.768 ± 79.218 268.098 ± 191.583 3 4,064.732 ± 1,574.698 4,183.901 ± 1,625.461 680.334 ± 247.617 4 256.025 ± 80.558 291.836 ± 82.051 3,354.797 ± 11.696 5 37.689 ± 13.208 30.001 ± 11.075 291.861 ± 76.142 6 2.529 ± 4.458 1.977 ± 7.234 104.480 ± 42.192 AstroPy (pixel flux counts) Dataset Mean Median Standard deviation 1 NaN 301.805 ± 58.583 NaN 2 531.575 ± 26.033 514.490 ± 80.094 221.245 ± 116.328 3 NaN 4,062.611 ± 1,577.868 NaN 4 256.029 ± 80.558 291.836 ± 82.051 3,358.125 ± 11.579 5 NaN 31.921 ± 10.723 NaN 6 2.528 ± 4.457 1.977 ± 7.234 104.659 ± 42.243

Table 7.1: Mean, median, and standard deviation for reduction results for all datasets. The values calculated for each image were averaged for each dataset.

Table 7.1 shows that the datasets that present NRMSE values higher than expected due to precision differences are the datasets in which AstroPy’s reduction process leaves NaN values in the images. As explained in section 5.3.1, reduction results obtained with FADRA algorithms are run through a sigma-clipping function to delete abnormal values, a process that apparently is not directly handled by AstroPy’s ccdproc package. However, looking at the median values for the datasets where this happens, we see that AstroPy and FADRA results are close, with AstroPy results probably being influenced by the presence of incorrect values in the images.

The next comparison corresponds to the results obtained with FADRA’s CPU and GPU reduction implementations, shown in Figure 7.2. Here, the very small NRMSE between the images reflects only the differences in precision that occur when transferring data between CPU and GPU and executing GPU kernels, as was discussed in section 4.2. In this case, no big dissimilarities between NRMSE results were found between datasets, because of the fact that both the results of CPU and GPU reduction implementations in FADRA go through the sigma-clipping process, unlike what happens in the previous case.

7.1.2 Experiment 2: Light curve evaluation

An important validation step in this thesis corresponds not only to the evaluation of the reduction results, but also of the light curves obtained from the different datasets. To do this, as was explained in section 6.1.2, the light curves obtained with AstroPy’s photutils

59 Figure 7.2: Normalized Root Mean Squared Error between the reduction results obtained with FADRA’s CPU reduction algorithm and FADRA’s GPU reduction algorithm. The datasets on the x-axis are arranged from lower (left) to higher (right) number of images. package and FADRA’s CPU photometry implementation were compared for similarity. An additive or multiplicative offset between the curves shows that they are the same in terms of the astronomical information that can be obtained from them. The process to compare the different lightcurves was the following:

For each dataset:

ˆ Two light curves were obtained: one with AstroPy’s photutils and one with FADRA’s CPU light curve obtention algorithm. ˆ The difference (subtraction) between the two curves was calculated. The result is a vector of the same length as the light curves. If a direct additive offset is present, all the values of this resulting vector should be equal. ˆ The photutils curve was divided by FADRA’s CPU curve. The result is a vector of the same length as the light curves. If a direct multiplicative offset is present, all the values of this resulting vector should be equal. ˆ The mean and standard deviation of the resulting difference and division vectors was calculated, to see if the values are all the same.

The final results of this calculation for each dataset are presented in Table 7.2.

60 Subtraction Division Dataset Mean Standard deviation Mean Standard deviation 1 6,445.370 4,707.175 1.001 0.001 2 -26,917.033 2,503.898 0.975 0.002 3 6,086.900 7,070.096 1.032 0.096 4 -7,851.717 876.498 0.957 0.001 5 2,772.740 0.05 1.003 0.0002 6 716.289 0.18 0.953 0.0007

Table 7.2: Results of the subtraction and division of the two light curves calculated for each dataset: one with the AstroPy’s photutils package, and one with FADRA’s CPU algorithm. The mean of the subtraction and division resulting vectors are shown, as well as the standard deviation of the said resulting vectors.

From the results shown in Table 7.2 it can be noted that a direct additive offset is not present between the photutils and FADRA CPU curves. This can be seen in the fact that the standard deviation values on the subtraction result vector are very high, in some cases (such as datasets 1 and 3) they are even close to the mean. This means that there are some big differences in the points resulting from the subtraction of one curve from the other, so the differences between them cannot be represented simply as an additive offset.

The results from the division of the two curves, however, seem to point in the direction of a multiplicative offset setting the differences between the curves. Even though the mean values of the result of dividing the curves are small, what is more important here is that the standard deviation values are also small, meaning that dividing the two curves results in a vector of values that are very similar to each other, in almost all cases up to the third decimal. This strongly suggests the presence of a multiplicative offset between the curves.

7.1.3 Experiment 3: Comparison between FADRA’s CPU and GPU photometry implementations

As was explained in section 6.1.3, the light curves obtained with FADRA’s CPU and GPU photometry implementations were compared for similarity. The presence of an additive or multiplicative offset shows that the shapes of the curves are the same. The process to obtain these results was the following:

For each dataset:

ˆ Two light curves were obtained: one with the CPU algorithm, and one with the GPU algorithm. ˆ The difference (subtraction) between the two curves was calculated. The result is a vector of the same length as the light curves. If a direct additive offset is present, all the values of this resulting vector should be equal. ˆ The GPU curve was divided by the CPU curve. The result is a vector of the same length as the light curves. If a direct multiplicative offset is present, all the values of

61 this resulting vector should be equal. ˆ The mean and standard deviation of the resulting difference and division vectors was calculated to see if the values are all the same.

The final results of this calculation for each dataset are presented in Table 7.3.

Subtraction Division Dataset ID Mean Standard deviation Mean Standard deviation 1 4.999 3.522 1.011 0.007 2 11.273 5.373 1.921 0.035 3 35.385 1.680 1.423 0.006 4 -17.951 1.286 0.846 0.003 5 2.624 3.957 1.038 1.021 6 -4.025 1.180 1.843 0.016

Table 7.3: Results of the subtraction and division of the two light curves calculated for each dataset: one with the CPU algorithm, and one with the GPU algorithm. The mean of the subtraction and division resulting vectors are shown, as well as the standard deviation of said resulting vectors.

Just as in the previous experiment, results suggest that an additive offset is not present between FADRA’s CPU and GPU curves, mainly because of the big standard deviation values of the results of subtracting one curve from the other. Also as in the previous experiment, a multiplicative offset seems to be present between the two curves. Even if the mean values show that the GPU curves almost doubles the CPU curve in some cases (datasets 2 and 6), the standard deviation values show that the differences between the points inside the curves are similar. Dataset 5 shows a slightly higher standard deviation value for this experiment, which might indicate the existence of an outlier point in one of the light curves. Considering that it is the only dataset that presents a higher standard deviation value, the effect is probably due to variations inside the dataset’s image, and not a reflection of the global functioning of the algorithm.

7.2 Execution time comparison

To measure execution times, each algorithm was run four times under the same conditions. The final running time for the results was calculated as the average of the results of the four runs. The results are presented below. The detailed execution times obtained for each dataset on each experimental run can be found in Appendix A.

7.2.1 Reduction

The execution time of the reduction algorithms on CPU and GPU are presented in Figure 7.3.

62 Figure 7.3: Execution times for astronomical image reduction algorithms in their CPU and GPU implementations. The datasets on the x-axis are arranged from lower (left) to higher (right) number of images.

These results demonstrate directly that the GPU implementation of the reduction algo- rithm takes longer to execute than the CPU implementation for all datasets, coming close to being equal for dataset 3, but never below the CPU execution times. This means that the astronomical image reduction process does not benefit from this GPU implementation, as was expected and commented in section 4.3.1. This is likely due to the fact that reduc- ing complete astronomical images requires intensive data transfer between the host and the device.

Something useful to note from these results is that the GPU execution time does not grow along with the number of images in the dataset. It would be expected that, as the number of images on each dataset increases, so would the execution times, considering that in this case the datasets used contain images of around the same size. However, this is only seen in the CPU execution times, but not in those of the GPU, as can be specifically seen in the results for datasets 3 and 5. This suggests that there might be other parameters in play on the timing of the GPU reduction process, besides the number of images. It is possible that some datasets exhibit internal properties, such as the standard deviation within images themselves, that might make them better or worse for being reduced on the GPU. Dataset 5 presents a decrease in reduction time compared to the previous dataset in both CPU and GPU implementations of the algorithm, also suggesting the presence of intrinsic properties of the datasets that might affect execution times.

63 7.2.2 Light curve generation

The execution time of the light curve obtention procedures on CPU and GPU implementa- tions are presented on Figure 7.4.

Figure 7.4: Execution times for light curve obtention algorithms in their CPU and GPU imple- mentations. The datasets on the x-axis are arranged from lower (left) to higher (right) number of images.

Unlike the previous case, from these results we see that the light curve obtention process highly benefits from the GPU implementation. There are differences of several seconds in the execution times for all datasets. Though in the case of light curve obtention this outcome was hoped for, it was not necessarily expected. These execution times show that the data stamp approach described in section 5.4 does work as a way to significantly reduce data transfer between host and device, enough so that the time taken on this data transfer does not overshadow the speedup gains obtained by the GPU implementation of the photometry algorithm, obtaining significant acceleration in all cases.

Dataset 3 exhibits an odd behavior seen as an inflation in execution time for this exper- iment, which is evident in the CPU implementation and slight, but still noticeable, in the GPU implementation. Together with the previous results of image reduction execution times, where dataset 3 also shows an unexpected behavior on the GPU reduction times, again we can draw the conclusion that there are properties intrinsic to this dataset that affect the execution times of the algorithms run over its images.

64 Chapter 8

Conclusions

The following chapter aims to, first, review the goals stated for this thesis in section 1.3.1, to then relate the said goals to the results obtained and presented in Chapter 7. The answers found to the research questions stated in section 1.3.2 are also presented and discussed. From this inspection of the goals of this thesis and the obtained results, conclusions about the performance of the algorithms implemented in this thesis for the FADRA framework, as well as about its applicability for use in astronomical data processing pipelines, are derived.

Along with the conclusions obtained from the work developed in this thesis, this chapter presents a discussion regarding FADRA’s future advancements and research aspects, both in the scope of the experiments and implementations developed within this thesis, as well as for the future new capabilities to be added to the framework.

8.1 Development of basic algorithms for astronomical data analysis

The first goal of this thesis corresponds to the implementation of the very basic algorithms necessary for astronomical image analysis: algorithms for image reduction and, as a part of that process, algorithms to combine images and obtain the Master calibration files needed for the reduction process. All of this promotes as little user intervention as possible, making it simple to quickly setup all the needed parameters to swiftly perform the reduction of great amounts of astronomical images.

Given the fact that the reduction process is the base for every further astronomical analysis to be performed over the images, it is of great importance not only that the algorithms run quickly and without needing input from the user through the process, but also that the results are proven to be correct. In the case of astronomical image reduction, the validation of the results is a vital step before using the algorithms to obtain scientific information. As stated in section 5.3, only the reduction algorithms themselves were tested on the performed experiments, since the image combination processes are based on SciPy’s implementations.

65 The details of the comparison carried out between the different results can be found in the description of Experiment 1, section 6.1.1.

In this regard, the FADRA implementation of reduction algorithms developed on this thesis matches the standard of established astronomical software such as AstroPy, which was used for the comparison. As can be seen in section 7.1 for the first experiment, the compari- son of FADRA’s CPU reduction algorithm with AstroPy’s ccdproc reduction process shows a very close match between the results. Three out of six datasets show differences that cor- respond only to precision errors between the results. This was expected, since the reduction process is standard and very different results would accuse an incorrect implementation of one of the algorithms.

In the cases where the NRMSE value was somewhat higher than just differences in pre- cision, detailed inspection of the datasets shows that the reduction results obtained with ccdproc present NaN values in some of the images, while the results obtained with FADRA do not. Invalid values are common occurrences in astronomical images, and can be caused by defective pixels on the detector or by cosmic rays hitting the detector while the image was being acquired. The differences in the values of the two reduced datasets are probably evidence of the different ways that FADRA and AstroPy handle these bad pixels. In the case of FADRA, bad pixels are sigma-clipped until they reach a certain acceptable value defined by the user, as was explained in section 5.3.1. AstroPy’s documentation shows that the package does not automatically deal with NaN values, like FADRA does. The user can provide masks for AstroPy arrays to deal with NaN values1, which was not explicitly done in this experiment. However, the differences obtained between the reduction results of the two procedures are still well below 1%, and thus can be considered acceptable in the context of this work.

Regarding the comparison of the reduction results obtained with FADRA’s CPU and GPU implementations, it is clear that the differences here are only due to precision changes when transfering and computing data to the GPU, as was commented on section 4.2. The very low NRMSE values between the results for every dataset show that choosing one of these implementations over the other does not yield significant differences, other than precision di- vergences that show up from the third decimal. This outcome was expected and is acceptable within the context of this work.

Overall, the results obtained with FADRA implementation of reduction algorithms are correct, in terms of being very similar to the ones obtained with AstroPy, both for the CPU and GPU implementations. This shows that the basic process of astronomical image analysis is well performed by the FADRA framework and that the coming processes to be carried out over the data are set on correct calibrated data.

Considering this, the reduction process implementation, along with the image combination algorithms used for Master files obtention, accomplish the first goal stated in section 1.3.1 of this thesis: to develop a framework that provides the basic algorithms necessary for astro- nomical data analysis, corresponding to data reduction algorithms and image combination algorithms for the obtention of calibration files.

1http://docs.astropy.org/en/stable/table/masking.html

66 8.2 Implementation of algorithms for light curve obten- tion

The next step regarding validation of FADRA results consisted in analyzing if the photom- etry and eventually light curve obtention algorithms yielded correct results. For this, two experiments were implemented: one to compare FADRA’s CPU light curve obtention results against the ones obtained with AstroPy’s photutils package (Experiment 2, section 6.1.2), and one to compare the results between FADRA’s CPU and GPU implementations for light curve obtention (Experiment 3, section 6.1.3). In both cases, the curves were compared against each other to find a fixed offset between the points of each one of them, as is further detailed in section 6.1.2.

It is important to note that in most cases of light curve analysis in astronomy the most important characteristic of the curves is not the actual numerical values, but the difference between points of the curve in different observation times. Even though extreme differences in the values of the curves are not desired in this context, small numerical differences along with the certainty that the shape of the two curves being compared is the same is a perfectly acceptable result for astronomical analysis of the variations of observations through time.

From the results of Experiment 2, shown in section 7.1.2, we see that a multiplicative offset exists between the results obtained with AstroPy and the ones obtained with FADRA’s CPU implementation. This means that, even though the actual values of the points of the curves are different, both curves have the exact same shape. Given the fact that the standard deviation values of the vectors resulting from dividing the two curves are very small, it can be concluded from these results that the points inside each curve have extremely similar behaviors. This means that the characteristics intrinsic to the curves are maintained between the light curves obtained with AstroPy and the ones obtained with FADRA. Even though there are small differences in the photometry measurement values of the curves, the internal behavior of the points being the same allows for the same time series analyses to be carried out. These results show that FADRA’s CPU algorithm for light curve obtention provides results that are up to the standards of established astronomical software, and thus can be used confidently in scientific applications.

It is interesting to see, in the results of Experiment 2, that the mean values obtained for the division of the curves oscillate around 1, with very small deviations from said value. This is a good result, since it shows that the actual numerical differences between the points of the two curves is not excessive. This also gives a hint about what could be causing the differences. Lets remember how aperture photometry is performed (detailed in section 3.4.3): an aperture radius is defined to cover the target object completely. An annulus is then defined around the object. It is important that the aperture radius envelops only the target, with as little as sky as possible. As well, the annulus has to envelop only background sky, and contain no other stars or objects. In case this is not possible, it must encompass the lowest possible area of different objects. After these shapes have been defined, the sum of luminous flux inside the aperture radius is calculated and, in most cases, a polynomial fit of the background sky inside the annulus is obtained, which is then used to estimate the amount of background sky present inside the aperture radius. This value is then subtracted from the flux inside the

67 aperture, obtaining the estimated value of the luminous flux coming only from the target astronomical object.

There are, however, many different ways to estimate the sky background inside the an- nulus. In the case of FADRA’s CPU implementation, and as is further detailed in section 5.4.4, the fit was obtained using a polynomial of the degree defined by the user (1 is the default). Different implementations of the aperture photometry algorithm can implement many different ways to model the sky background of the images. Because of this, it is likely that the small numerical differences between the points in the two curves is due to the fact that AstroPy’s implementation uses a different way to model the sky background that is subtracted from the flux inside the aperture radius.

The same analysis can be performed for the comparison between the results obtained with FADRA’s CPU and GPU implementations on Experiment 3 (section 7.1.3). Again, an additive offset does not seem to be present between the curves, but the results suggest the existence of a multiplicative one. In this case, the numerical differences of the values inside the curves (the average values of the division result vectors) are higher than in the previous case. A bigger numerical difference was expected to be found between the results obtained with CPU and GPU, given the fact that the GPU photometry measurements are done through the approximation presented in equation 5.1. The approximation used to estimate the sky background in the GPU photometry algorithm is expected to yield results much less exact than the ones obtained in the CPU algorithm. Also, as was explained in section 5.4.4, the use of atomic operations in the GPU photometry kernel generates precision errors as well. The case of determining if a pixel is inside the aperture radius or sky annulus is based, in the GPU version, only in integer operations, which could bring about small variations between the CPU and the CPU results.

In general, the light curves obtained with the GPU photometry implemented in FADRA are well within the acceptable range to perform scientific analyses. The small standard deviations in the results of dividing the two curves mean the CPU and GPU curves are of the same shape.

Taking this into consideration, the light curve obtention algorithms implemented in FADRA fulfill the second goal established for this thesis, that is, to provide algorithms for automated light curve generation, with as minimal user intervention as possible, but also to be efficient in execution time and provide good results.

8.3 GPU implementation of algorithms

After the results obtained with FADRA’s different implementations were proven to be correct, the next step was to evaluate the GPU algorithms to analyze if there are significant speedups of the execution times. For this, two research questions to be answered with the work of this thesis were established:

68 Q1: Is it possible to obtain significant GPU speedup in astronomical algorithms that deal with a large amount of data transfers between CPU and GPU? Q2: Are these speedups justified? In other words, is the obtained acceleration worth it considering the extra implementation that GPU algorithms convey?

Looking at the execution time results obtained from the reduction algorithms, we see that this process does not benefit from a direct GPU implementation. Reducing complete astronomical images for big datasets requires an intensive amount of data transfers between host and devices, which overshadows any gains in execution time that might be obtained by performing the operations on the GPU. However, it is interesting to note that some datasets show lower execution times than previous datasets containing less images, as is the case with datasets 3 and 5 (Figure 7.3). The expected outcome would be that as the number of images on each dataset increases, so would the execution times, especially in this case were the images from all datasets are about the same size. This suggests the presence of certain characteristics within each dataset that might make them better or worse for being processed on the GPU. This is also supported by the fact that a slight decrease in execution time can be seen for this datasets in the CPU results as well. However, considering the intensive data used due to the nature of the reduction process, bad execution times were expected for the GPU implementation of the algorithm.

For the case of the reduction algorithms, slower execution times for the GPU version were expected, because of the large amount of data transfer between host and device that must be carried out for this process. The light curve obtention process, however, was different, and initially no guesses could really be made about the outcome regarding execution times. While it was true that the amount of data used for the light curve obtention algorithms was significantly reduced compared to the amount of data used for the reduction process, there were no guarantees that the data stamp approach would work faster on the GPU than on the CPU. The data transfer process could still overshadow the computational gains.

However, as can be seen in the results (Figure 7.4), in this case there are important gains in execution time when using the GPU version of the light curve obtention algorithm. This shows that the stamp approach designed to reduce the amount of data used for light curve obtention does turn out to be an efficient way to reduce data transfer between host and device and, as such, it takes advantage of the acceleration provided by GPU parallelization.

In terms of the second research question, the case of the light curve obtention algorithm shows a strong decrease in execution time. This demonstrates that the development of a GPU version of the algorithm results convenient, in terms of speed gains, over the extra implementation. Using the aperture photometry approximation presented in section 5.4.4, the implementation of the GPU kernel turns out to be straightforward, therefore developing a GPU version of this algorithm is worth considering.

In combination with the comments about the results yielded with the GPU light curve obtention algorithm discussed in the the previous section, this implementation successfully fulfills the second and third goals established for this thesis, which were: to provide algorithms for automated light curve generation with as minimal user intervention as possible but also to be efficient in execution time and which generate good results, and to provide GPU

69 accelerated versions of reduction and light curve obtention algorithms.

8.4 Future work

It is important to keep in mind that the work carried out in this thesis aims to set the bases for the FADRA framework, but this one must keep being developed, implemented, and improved. The work presented here does not represent the full scope of the FADRA framework, but only the first, basic and vital implementations needed to start this scheme for GPU-powered analysis of astronomical data.

With this said, this thesis should be considered as the starting point for the development of the FADRA framework, but there is still plenty to be done. Future endeavors with FADRA not only encompass enhancing the algorithms developed for the scope of this thesis, but also adding new functionalities to the framework. These new additions should hopefully be designed and implemented within the careful experimental method developed for the present project. This, as a means to make sure that the expansions are correct and that the results yielded by FADRA are always maintained up to the standards of established astronomical software.

Future work is separated in these two scopes: first, work to be developed over the imple- mentations carried out and presented in the context of this thesis, and second, the future developments to be added to FADRA and the expectations for the framework in the short and the long term.

8.4.1 Within the scope of this thesis

One of the priorities for the future work in the algorithms implemented for this thesis relates to fixing the precision differences that are obtained between CPU and GPU results. Even though these differences are still acceptable in the context of the analyses to be carried out over these results, it is critical that in the future FADRA can offer the certainty that the results obtained with the framework are exact, in all its different implementations.

While it is true that there are differences in precision which are inherent to the use of the GPU to perform calculations, the use of atomic operations for the photometry approximation adds even more precision problems by being only available for use with integers. Designing both new approximations for photometry calculation and/or new implementations of the cur- rent kernel could bring about more exact approximations and, consequently, results that are more similar to the ones obtained with the CPU implementation of photometry algorithms. Also concerning GPU implementations, a next step in the development of FADRA would be to design GPU algorithms for image combination and the obtention of Master calibration files, as well as for filter application over images.

Another useful feature to develop in relation to the implementation of GPU algorithms is to determine certain features of the datasets that might make them better or worse candidates

70 for processing on the GPU. For example, in the execution times for the reduction process (Figure 7.3) some datasets yielded lower execution times than other datasets containing less images. Considering only the number of images as a distinctive characteristic of the dataset, and considering that all images of all datasets are similar to each other, then the number of images should be the only influence in the execution time. However, as can be seen from the results, this is not always the case. The different execution times are not the only result that demonstrates the differences in the images between datasets: for example, the results of the NRMSE values and even the standard deviation results obtained in the comparison of light curves could represent characteristics intrinsic to each dataset.

Studying these features that characterize each dataset could make it possible to implement a test that determines, for example, if a dataset will process faster with the CPU reduction algorithm or with the GPU reduction algorithm. This, considering that for some datapoints the GPU reduction time gets very close to the CPU reduction times. It would be very useful to analyze if a feature exists which makes some datasets faster to be transfered and operated on the GPU. Some characteristics worth analyzing correspond to, for example, the internal standard deviation of each image on the dataset, the standard deviation of the dataset as a whole, how crowded with stars each image of the dataset is, among others. Studying the execution times not only in terms of dataset size but also in terms of these characteristics would bring a different vision on what makes a dataset more fit for the GPU. In the future, the FADRA implementation may be capable of automatically deciding if it is going to execute the CPU or GPU implementation of a certain algorithm, making the process even more automatized and thus more suitable to be executed within larger scripts for astronomical data processing.

Regarding light curves, the natural step that should come after the obtention procedure is the implementation of algorithms to find fits and perform statistical analysis over the said curves. Time series analysis requires the application of statistical methods over a series of data in order to be able to obtain information and make predictions about it. Correlations, trends, and seasonal variations, are just some of the internal structures that scientists look for in their curves when performing said analyses. This would be the next development step in relation to FADRA’s light curve procedures.

Even though the main aim of the FADRA framework is to be able to smoothly perform inside bigger scripts for data analysis, a wrapper class was developed to provide a Graphical User Interface (GUI) for the determination of photometry parameters and the obtention of light curves. The idea of this is to allow the user to get a visual feel of the data that is being analyzed, and to help them select the proper parameters for each dataset. Considering this, an attractive addition to this GUI would be the presentation of quality checks along different milestones of the process. For example, after the Master calibration files have been obtained, the images themselves in different visualizations, besides statistical information about them, could be shown to the user to help them spot any possible problems along the way. If one of the images used to obtain the Masters had bad pixels, for example, this would reflect on the final result and the user would be able to see it before continuing the scientific processes.

Another addition that could help make sure that the data and parameters to be used are correct is to show the user not only the image to select the target star and the aperture

71 photometry parameters, but also the radial profile of the selected star. The radial profile corresponds to a “sliced” visualization of the star, shown as a Gaussian curve, which makes it easy to determine at which point from the center the luminous flux stops corresponding to the star and begins showing only background sky.

8.4.2 The FADRA framework

FADRA is expected to encompass not only the basic algorithms for astronomical data pro- cessing, but also implementations of more complicated and detailed procedures to be carried out over different types of astronomical data. Today, the FADRA framework provides the basic tools for the analysis of astronomical images, but the framework was conceived to be easily expanded by the users. In terms of this, the FADRA framework is expected to be publicly released soon, both to receive feedback from real users and to begin adding new functionalities.

The new modules added to the FADRA framework are expected to maintain the focus in developing new approaches to the known astronomical algorithms, as a means to provide GPU implementations for common processes in astronomical data analysis. This is because with the survey era in astronomy approaching, faster ways to analyze data are going to become more necessary as the years go by. In the future, the astronomer will not go to the observatory to obtain data and then reduce it at home: the survey telescopes will observe the complete night sky, and the astronomer will have access to an online database in which the data of interest will simply be downloaded, already calibrated and ready to perform scientific analyses. The process will possibly evolve even more, and the astronomer will not have access to the images themselves, but to the light curves or the relevant data already calculated. Because of this, and in order to become a tool that is useful for decades in astronomy, the developments added to FADRA should be designed always keeping in mind that fast ways of handling big amounts of data must be a priority.

The previous comment also relates to the scalability of GPU systems, as was commented in Chapter 4. To add more computing power to a GPU cluster, all that has to be done is to add more GPUs to the machine. Only minimal interventions to the code are needed, if any. The implementation of GPU algorithms not only have the benefit of being many times faster (when the dataset is appropriate and the algorithm is well implemented), but also that their benefits can be experienced from the user level with just a few images to the big clusters processing hundreds of astronomical images from survey telescopes per minute.

Astronomy is evolving, and so should be the software used to perform it. If this is kept in mind and considered when developing new additions for FADRA, or for any other astro- nomical software, the tools used by astronomers will evolve in the same direction to which data and technology lead.

72 Bibliography

[1] K. Akeley and T. Jermoluk. High-performance polygon rendering. In ACM SIGGRAPH Computer Graphics, volume 22, pages 239–246, 1988.

[2] M. A. Albrecht, A. Brighton, T. Herlin, P. Biereichel, and D. Durand. Access to Data Sources and the ESO SkyCat Tool. In Astronomical Data Analysis Software and Systems VI, volume 125 of Astronomical Society of the Pacific Conference Series, page 333, 1997.

[3] M. G. Allen, F. Ochsenbein, S. Derriere, T. Boch, P. Fernique, and G. Landais. Extract- ing Photometry Measurements from VizieR Catalogs. In Astronomical Data Analysis Software and Systems XXIII, volume 485 of Astronomical Society of the Pacific Confer- ence Series, page 219, May 2014.

[4] Astropy Collaboration. Current Status of Astropy Sub-packages. https://astropy. readthedocs.org/en/stable/stability.html, May 2016.

[5] Astropy Collaboration, T. Robitaille, E. Tollerud, et al. Astropy: A community Python package for astronomy. A&A, 558:A33, Oct. 2013.

[6] K. Banse, P. Crane, P. Grosbol, F. Middleburg, C. Ounnas, D. Ponz, and H. Waldthausen. MIDAS - ESO’s new image processing system. The Messenger, 31:26– 28, Mar. 1983.

[7] B. R. Barsdell, D. G. Barnes, and C. J. Fluke. Analysing astronomy algorithms for graphics processing units and beyond. MNRAS, 408:1936–1944, Nov. 2010.

[8] A. J. Barth. ATV: An Image-Display Tool for IDL. In Astronomical Data Analysis Software and Systems X, volume 238, page 385, 2001.

[9] R. Berry and J. Burnell. The handbook of astronomical image processing. Willmann-Bell, Inc., 2nd edition, 2006.

[10] T. Boch and P. Fernique. Aladin Lite: Embed your Sky in the Browser. In Astronomical Data Analysis Software and Systems XXIII, volume 485 of Astronomical Society of the Pacific Conference Series, page 277, May 2014.

[11] F. Bonnarel, H. Ziaeepour, J. G. Bartlett, O. B. M. Creze, D. Egret, J. Florsch, F. Gen- ova, F. Ochsenbein, V. Raclot, M. Louys, and P. Paillou. The ALADIN Interactive Sky Atlas. In New Horizons from Multi-Wavelength Sky Surveys, volume 179 of IAU

73 Symposium, page 469, 1998.

[12] Brian D. Warner, Palmer Divide Observatory. Basic Instructions for Putting Data onto a Standard System. Used with permission of the author. http://www.minorplanet. info/ObsGuides/Misc/StandardizingData.htm.

[13] P. J. Brockwell and R. A. Davis. Introduction to time series and forecasting. Springer, 2nd edition, 2002.

[14] C. Buil. IRIS: An astronomical images processing software. http://www.astrosurf. com/buil/us/iris/iris.htm, Sept. 2014.

[15] H. Bushouse and B. Simon. The IRAF/STSDAS Synthetic Photometry Package. In Astronomical Data Analysis Software and Systems III, volume 61 of Astronomical Society of the Pacific Conference Series, page 339, 1994.

[16] J. B´edorf. The gravitational billion body problem: Het miljard deeltjes probleem. In Doctoral dissertation, Leiden Observatory, Faculty of Science, Leiden University, 2014.

[17] S. Cavuoti, M. Garofalo, M. Brescia, M. Paolillo, A. Pescape’, G. Longo, and G. Ventre. Astrophysical data mining with GPU. A case study: Genetic classification of globular clusters. New A, 26:12–22, Jan. 2014.

[18] M. A. Clark, P. C. La Plante, and L. J. Greenhill. Accelerating Radio Astronomy Cross-Correlation with Graphics Processing Units. ArXiv e-prints, 2011.

[19] F. Cohen, P. Decaudin, and F. Neyret. GPU-based lighting and shadowing of complex natural scenes. In ACM SIGGRAPH 2004 Posters, page 91, 2004.

[20] M. J. Currie, D. S. Berry, T. Jenness, A. G. Gibb, G. S. Bell, and P. W. Draper. Starlink Software in 2013. In Astronomical Data Analysis Software and Systems XXIII, volume 485 of Astronomical Society of the Pacific Conference Series, page 391, May 2014.

[21] L. E. Davis. New Software For the IRAF Stellar Photometry Package. In Astronomical Data Analysis Software and Systems II, volume 52 of Astronomical Society of the Pacific Conference Series, page 420, Jan. 1993.

[22] L. E. Davis. A reference guide to the iraf/daophot package. IRAF Programming Group, NOAO, 1994.

[23] M. D. de La Pe˜naand P. Greenfield. A Survey of Python Plotting Packages for PyRAF. In Astronomical Data Analysis Software and Systems XI, volume 281 of Astronomical Society of the Pacific Conference Series, page 193, 2002.

[24] M. D. de La Pe˜na,R. L. White, and P. Greenfield. The PyRAF Graphics System. In Astronomical Data Analysis Software and Systems X, volume 238 of Astronomical Society of the Pacific Conference Series, page 59, 2001.

[25] P. W. Draper. GAIA: Recent Developments. In Astronomical Data Analysis Software

74 and Systems IX, volume 216 of Astronomical Society of the Pacific Conference Series, page 615, 2000.

[26] E. Elsen, V. Vishal, M. Houston, V. Pande, P. Hanrahan, and E. Darve. N-Body Simulations on GPUs. ArXiv e-prints, 2007.

[27] K. Fatahalian, J. Sugerman, and P. Hanrahan. Understanding the Efficiency of GPU Algorithms for Matrix-Matrix Multiplication. In Proceedings of the ACM SIG- GRAPH/EUROGRAPHICS conference on Graphics hardware, pages 133 – 137, 2004.

[28] C. J. Fluke. Accelerating the Rate of Astronomical Discovery with GPU-Powered Clus- ters. In Astronomical Data Analysis Software and Systems XXI, volume 461 of Astro- nomical Society of the Pacific Conference Series, 2012.

[29] C. J. Fluke, D. G. Barnes, B. R. Barsdell, and A. H. Hassan. Astrophysical Supercom- puting with GPUs: Critical Decisions for Early Adopters. PASA, 28:15–27, 2011.

[30] C. J. Fluke, D. G. Barnes, and A. H. Hassan. Visualisation and Analysis Challenges for WALLABY. ArXiv e-prints, 2010.

[31] M. R. Garey, D. S. Johnson, F. P. Preparata, and R. E. Tarjan. Triangulating a simple polygon. Information Processing Letters, 7:175–179, 1978.

[32] C. Gheller, P. Wang, F. Vazza, and R. Teyssier. Numerical cosmology on the GPU with Enzo and Ramses. ArXiv e-prints, Dec. 2014.

[33] P. Greenfield and R. L. White. A New CL for IRAF Based On Python. In Astronomical Data Analysis Software and Systems IX, volume 216 of Astronomical Society of the Pacific Conference Series, page 59, 2000.

[34] S. Hartung and H. Shukla. Fast Image Subtraction Using Multi-cores and GPUs. In American Astronomical Society Meeting Abstracts #221, volume 221 of American As- tronomical Society Meeting Abstracts, page 240.06, Jan. 2013.

[35] S. Hasinoff. Computer Vision: a reference guide, page 608. Springer, 2014.

[36] J. Hensley. What is OpenCL? In ACM SIGGRAPH ASIA 2010 Courses, pages 9:1–9:61, 2010.

[37] High Energy Astrophysics Science Archive Research Center, at NASA. A primer on the FITS data format. http://fits.gsfc.nasa.gov/fits_primer.html, 2014.

[38] K. Igor. A new GPU-accelerated hydrodynamical code for numerical simulation of interacting galaxies. ArXiv e-prints, Nov. 2013.

[39] H. Johnson and W. Morgan. The UBV photometric system. ApJ, 117:313, 1953.

[40] W. A. Joye and E. Mandel. New Features of SAOImage DS9. In Astronomical Data Analysis Software and Systems XII, volume 295 of Astronomical Society of the Pacific

75 Conference Series, page 489, 2003.

[41] W. A. Joye and E. Mandel. The Development of SAOImage DS9: Lessons Learned from a Small but Successful Software Project. In Astronomical Data Analysis Software and Systems XIV, volume 347 of Astronomical Society of the Pacific Conference Series, page 110, Dec. 2005.

[42] Khronos OpenCL Working Group. Khronos Group OpenCL 2.0 Specifications v.29. https://www.khronos.org/registry/cl/specs/opencl-2.0.pdf, July 2015.

[43] P. Klages, K. Bandura, N. Denman, A. Recnik, J. Sievers, and K. Vanderlinde. GPU Kernels for High-Speed 4-Bit Astrophysical Data Processing. ArXiv e-prints, Mar. 2015.

[44] Krishnavedala. Diagram of the lightpath through a Newtonian telescope. Own work. Dis- tributed via Wikimedia Commons under CC BY-SA 4.0 license. http://en.wikipedia. org/wiki/File:Newtonian_telescope2.svg.

[45] C. A. Kuehn, J. Drury, D. Stello, and T. R. Bedding. Photometry Using Kepler “Su- perstamps” of Open Clusters NGC 6791 and NGC 6819. In International Astronomical Union Symposium No. 301, pages 445–446, 2014.

[46] W. B. Landsman. The IDL Astronomy User’s Library. In Astronomical Data Analysis Software and Systems II, volume 52 of Astronomical Society of the Pacific Conference Series, page 246, Jan. 1993.

[47] W. B. Landsman. The IDL Astronomy User’s Library. In Astronomical Data Analysis Software and Systems IV, volume 77 of Astronomical Society of the Pacific Conference Series, page 437, 1995.

[48] M. D. Lawden. The STARLINK Project. Starlink General Paper, 31, 1990.

[49] A. Lefohn. GPU memory model overview. SIGGRAPH’05: ACM SIGGRAPH 2005 Courses, page 127, 2005.

[50] H. Li, D. Hestenes, and A. Rockwood. Generalized homogeneous coordinates for com- putational geometry. In Geometric Computing with Clifford Algebras, pages 27–59. Springer, 2001.

[51] J. Li, C. Yu, J. Sun, and J. Xiao. A GPU-based algorithm for astronomical image subtraction photometry. In Mechatronic Sciences, Electric Engineering and Computer (MEC), International Conference on, IEEE, pages 1937–1942, 2013.

[52] D. Luebke. CUDA: Scalable parallel programming for high-performance scientific com- puting. In 5th IEEE International Symposium on Biomedical Imaging, pages 836 – 838, 2008.

[53] D. Luebke and G. Humphreys. How GPUs Work. Computer, 40(2):96–100, 2007.

[54] O. Maitre, L. A. Baumes, N. Lachiche, A. Corma, and P. Collet. Coarse Grain Paral-

76 lelization of Evolutionary Algorithms on GPGPU Cards with EASEA. In Proceedings of the 11th Annual Conference on Genetic and Evolutionary Computation, GECCO ’09, pages 1403–1410, 2009.

[55] D. Makovoz, T. Roby, I. Khan, and H. Booth. MOPEX: a software package for astrono- mical image processing and visualization. In Society of Photo-Optical Instrumentation Engineers (SPIE) Conference Series, volume 6274 of Society of Photo-Optical Instru- mentation Engineers (SPIE) Conference Series, June 2006.

[56] A. Mammen. Transparency and antialiasing algorithms implemented with the virtual pixel maps technique. Computer Graphics and Applications, IEEE, 9:43–55, 1989.

[57] M. Mobberley. Supernovae: and How to Observe Them, chapter 7, page 85. Springer, 2007.

[58] NVIDIA. CUDA Parallel Computing Platform. http://www.nvidia.com/object/ cuda_home_new.html, 2006.

[59] A. Papadopoulos, I. Kirmitzoglou, V. J. Promponas, and T. Theocharides. GPU tech- nology as a platform for accelerating local complexity analysis of protein sequences. In Engineering in Medicine and Biology Society (EMBC), 35th Annual International Conference of the IEEE, pages 2684–2687. IEEE, 2013.

[60] J. Perdang and T. Serre. What can we learn from observational stellar time series? A&A, 334:976–986, June 1998.

[61] J. Pineda. A parallel algorithm for polygon rasterization. In ACM SIGGRAPH Com- puter Graphics, volume 22, pages 17–20, 1988.

[62] M. Prato, R. Cavicchioli, L. Zanni, P. Boccacci, and M. Bertero. Efficient deconvolution methods for astronomical imaging: algorithms and IDL-GPU codes. A&A, 539, 2012.

[63] H. Qiu and G. Memmi. Fast selective encryption method for bitmaps based on GPU acceleration. In Multimedia (ISM), IEEE International Symposium on, pages 155–158. IEEE, 2014.

[64] M. Rivi, C. Gheller, T. Dykes, M. Krokos, and K. Dolag. GPU accelerated particle visualization with Splotch. Astronomy and Computing, 5:9–18, July 2014.

[65] J. Sainio. CUDAEASY - a GPU accelerated cosmological lattice program. Computer Physics Communications, 181:906–912, 2010.

[66] SBIG Astronomical Instruments. Ten things you never knew you could do with CCDOps. http://www.phys.vt.edu/~jhs/phys3154/TenThingsCCDOps.pdf, 2011. [67] K. Schaaf, C. Broekema, G. Diepen, and E. Meijeren. The Lofar Central Processing Facility Architecture. Experimental Astronomy, 17:43–58, 2004.

[68] K. Schaaf and R. Overeem. Cots Correlator Platform. Experimental Astronomy, 17:287–

77 297, 2004.

[69] K. V. D. Schaaf. Efficient usage of HPC horsepower for the LOFAR telescope. In Astro- nomical Data Analysis Software and Systems (ADASS) XIII, volume 314 of Astronomical Society of the Pacific Conference Series, page 682, 2004.

[70] M. Schirmer. THELI GUI – Convenient reduction of optical, near- and mid-infrared imaging data. The Astrophysical Journal Supplement Series (ApJS), 209:21, 2013.

[71] M. Segal, C. Korobkin, R. Van Widenfelt, J. Foran, and P. Haeberli. Fast shadows and lighting effects using texture mapping. In ACM SIGGRAPH Computer Graphics, volume 26, pages 249–252, 1992.

[72] Smithsonian Astrophysical Observatory. SAOImage DS9: A utility for displaying as- tronomical images in the X11 window environment. Astrophysics Source Code Library, Mar. 2000.

[73] J. Stone, D. Gohara, and G. Shi. OpenCL: A parallel programming standard for het- erogeneous computing systems. Computing in science and engineering, 12:66, 2010.

[74] M. Templeton. Time-Series Analysis of Variable Star Data. Journal of the American Association of Variable Star Observers (JAAVSO), 32:41–54, June 2004.

[75] S. Tomov, R. Nath, H. Ltaief, and J. Dongarra. Dense linear algebra solvers for multicore with GPU accelerators. In Parallel & Distributed Processing, Workshops and Phd Forum (IPDPSW), IEEE International Symposium on, pages 1–8. IEEE, 2010.

[76] C. Trapnell and M. Schatz. Optimizing data intensive {GPGPU} computations for {DNA} sequence alignment. Parallel Computing, 35:429–440, 2009.

[77] F. Valdes. The Interactive Data Reduction and Analysis Facility (IRAF). In Bulletin of the American Astronomical Society, volume 16 of Bulletin of the American Astronomical Society, page 497, Mar. 1984.

[78] F. Varosi, W. B. Landsman, and B. Pfarr. The IDL Astronomy User’s Library. In Bulletin of the American Astronomical Society, volume 22 of Bulletin of the American Astronomical Society, page 829, Mar. 1990.

[79] S. V´ıtek, J. Svihl´ık,L.ˇ Krasula, K. Fliegel, and P. P´ata.GPU accelerated processing of astronomical high frame-rate videosequences. In Applications of Digital Image Processing XXXVIII, volume 9599 of Proc. SPIE, page 95992L, 2015.

[80] C. Warner, S. S. Eikenberry, A. H. Gonzalez, and C. Packham. Redefining the Data Pipeline Using GPUs. In Astronomical Data Analysis Software and Systems XXII, volume 475 of Astronomical Society of the Pacific Conference Series, page 79, Oct. 2013.

[81] B. Weiner, M. R. Blanton, A. L. Coil, M. C. Cooper, R. Dav´e,D. W. Hogg, B. P. Holden, P. Jonsson, S. A. Kassin, J. M. Lotz, J. Moustakas, J. A. Newman, J. X. Prochaska,

78 P. J. Teuben, C. A. Tremonti, and C. N. A. Willmer. Astronomical Software Wants To Be Free: A Manifesto. In astro2010: The Astronomy and Astrophysics Decadal Survey, 2010.

[82] D. C. Wells and E. W. Greisen. FITS - a Flexible Image Transport System. In Image Processing in Astronomy, page 445, 1979.

[83] M. Xiao, H. Deng, F. Wang, , and K. Ji. A Survey on GPU Techniques in Astronomical Data Processing. In Computer Sciences and Applications (CSA), 2013 International Conference on, IEEE, pages 206–209, 2013.

[84] N. Zacharias, C. T. Finch, T. M. Girard, A. Henden, J. L. Bartlett, D. G. Monet, and M. I. Zacharias. The Fourth US Naval Observatory CCD Astrograph Catalog (UCAC4). AJ, 145:44, Feb. 2013.

[85] Y. Zhang and J. Owens. A quantitative performance analysis model for GPU architec- tures. In High Performance Computer Architecture (HPCA), 17th International Sym- posium on, pages 382–393. IEEE, 2011.

[86] B. Zhao, Q. Luo, and C. Wu. Parallelizing Astronomical Source Extraction on the GPU. In eScience, 9th International Conference on, IEEE, pages 88–97, 2013.

[87] K. Zhao, G. Mei, N. Xu, and J. Zhang. On the Accelerating of Two-dimensional Smart Laplacian Smoothing on the GPU. ArXiv e-prints, Feb. 2015.

79 Appendix A

Details of results

A.1 Validation of reduction results

Table A.1 presents the values of the Normalized Root Mean Square Error (NRMSE) obtained after averaging the NRMSE for all the images on each dataset. The first two columns show the NRMSE between AstroPy results using ccdproc and FADRA’s CPU reduction results. The next two columns show the NRMSE between FADRA’s CPU and GPU reduction results.

NRMSE (%) NRMSE(%) AstroPy vs. FADRA FADRA CPU vs. FADRA GPU Dataset Average Standard deviation Average Standard deviation 1 0.0348 0.0005 0.0031 0.0002 2 2.562E-9 2.022E-9 3.132E-9 2.383E-9 3 0.5801 0.3293 0.0057 0.0010 4 8.471E-9 7.106E-11 1.190E-8 2.314E-10 5 0.0380 0.0187 0.0046 0.0006 6 1.026E-9 3.27E-10 1.157E-9 4.303E-10

Table A.1: Normalized Root Mean Square Error (%) for validation of reduction results using AstroPy’s ccdproc package and FADRA’s CPU and GPU implementations.

A.2 Execution time results

The following tables correspond to the results of running the timing experiments. Each experiment was run four times. The results from each independent run are shown in Table A.2 for timing of the reduction process, and in Table A.3 for timing of light curve obtention. The values finally plotted and shown in section 7.2 correspond to the mean and standard deviation obtained from the experimental runs. Said values can be found in Table A.4 for the reduction algorithms, and in Table A.5 for light curve obtention.

80 Run 1 Run 2 Run 3 Run 4 Dataset CPU (s) GPU (s) CPU (s) GPU (s) CPU (s) GPU (s) CPU (s) GPU (s) 1 1.58 1.74 1.61 1.81 1.58 1.79 1.59 1.71 2 2.42 3.80 2.47 3.82 2.63 3.88 2.69 4.58 3 2.93 3.13 3.30 3.38 3.00 3.22 3.21 3.42 4 4.06 6.15 4.04 6.18 4.10 6.09 3.99 6.04 5 4.00 4.27 3.94 4.23 3.94 4.60 3.87 4.39 6 6.36 9.73 6.50 9.90 6.80 11.02 6.65 10.85

Table A.2: Execution times for four runs of the astronomical image reduction algorithms.

Run 1 Run 2 Run 3 Run 4 Dataset CPU (s) GPU (s) CPU (s) GPU (s) CPU (s) GPU (s) CPU (s) GPU (s) 1 4.66 0.52 4.66 0.47 4.65 0.53 4.66 0.53 2 1.66 0.50 1.68 0.42 1.68 0.51 1.66 0.51 3 11.97 0.98 12.04 0.85 12.06 0.97 12.32 1.01 4 5.44 0.78 5.51 0.83 5.46 0.75 5.57 0.81 5 5.43 1.06 5.44 0.86 5.48 1.01 5.45 1.01 6 14.88 1.93 15.09 1.72 15.04 1.87 11.64 1.73

Table A.3: Execution times for four runs of the light curve obtention algorithms.

CPU (s) GPU (s) Dataset Average Standard deviation Average Standard deviation 1 1.59 0.01 1.76 0.04 2 2.55 0.12 4.02 0.37 3 3.11 0.17 3.29 0.13 4 4.05 0.04 6.11 0.06 5 3.94 0.05 4.37 0.16 6 6.58 0.18 10.38 0.65

Table A.4: Average execution time for the astronomical image reduction algorithms.

CPU (s) GPU (s) Dataset Average Standard deviation Average Standard deviation 1 4.65 0.01 0.51 0.02 2 1.67 0.01 0.48 0.04 3 12.09 0.15 0.95 0.07 4 5.49 0.05 0.79 0.03 5 5.45 0.02 0.98 0.08 6 14.16 1.68 1.81 0.10

Table A.5: Average execution time for the light curve obtention algorithms.

81