update of grammar using grammarly and updating American English to British English

Author: apmechev

background/background.tex

@@ -31,7 +31,7 @@ \subsection{Astronomy and Computing}
 
 Photons provide us with rather few independent properties. We can use them to record the wavelength, the direction, the intensity, and the polarization of a distant source. We can, moreover, record the change of those properties with time. Astronomers need to measure properties accurately and use the data to model distant sources better and validate or reject astronomical theories. The accuracy of these models, or the rejection power of our observations, depends critically on how accurately we can measure the four properties listed above. 
 
-Astronomical observations in the long-wavelength regime have always been at the mercy of the diffraction limit, an effect that relates the wavelength of light, the diameter of the aperture, and angular resolution obtained with that aperture. The angular resolution of a telescope determines how accurately the direction of an incoming photon can be determined. Unfortunately, the diffraction limit dictates that the angular resolution of a telescope with a fixed aperture decreases inversely proportional to the wavelength observed. For example, if one takes a telescope at 100MHz and one at 10GHz, the 100MHz telescope would need to have 100 times the radius of its higher frequency counterpart in order to reach the same angular resolution. In other words, for a low-frequency telescope (at 100 MHz) to match the 100-m Effelsberg telescope (at 10GHz), it would need a dish with a diameter of 10 kilometers. Constructing, and operating a telescope of that size is currently outside our engineering capabilities, and thus low-frequency astronomers have developed a method to synthesize a telescope aperture of arbitrary size, termed `Aperture Synthesis.' 
+Astronomical observations in the long-wavelength regime have always been at the mercy of the diffraction limit, an effect that relates the wavelength of light, the diameter of the aperture, and angular resolution obtained with that aperture. The angular resolution of a telescope determines how accurately the direction of an incoming photon can be determined. Unfortunately, the diffraction limit dictates that the angular resolution of a telescope with a fixed aperture decreases inversely proportional to the wavelength observed. For example, if one takes a telescope at 100MHz and one at 10GHz, the 100MHz telescope would need to have 100 times the radius of its higher frequency counterpart in order to reach the same angular resolution. In other words, for a low-frequency telescope (at 100 MHz) to match the 100-m Effelsberg telescope (at 10GHz), it would need a dish with a diameter of 10 kilometres. Constructing, and operating a telescope of that size is currently outside our engineering capabilities, and thus low-frequency astronomers have developed a method to synthesize a telescope aperture of arbitrary size, termed `Aperture Synthesis.' 
 
 \begin{figure}[h]
     \centering

ch2

@@ -1,7 +1,7 @@
 \section[Measuring LOFAR Pipeline performance with pipeline\_collector]{Measuring LOFAR Pipeline performance with \\pipeline\_collector}\label{sec:ch4_methods}
 We developed the package \textit{pipeline\_collector} as an extension of  the performance collection package \textit{tcollector}. \textit{pipeline\_collector} makes it possible to collect performance data for complex multi-step pipelines. Additionally, it makes it easy to record performance data from other utilities. A performance monitoring utility that we plan to integrate in the future are the PAPI tools described in section \ref{sec:ch4_related}. The resulting performance data was recorded in a database and analyzed. For our tests, we used the LOFAR \textit{prefactor} pipeline, however with minor modifications, any multi-step pipeline can be profiled. 
 
-\textit{tcollector} is a software package that automatically launches 'collector' scripts. These scripts are  sample the specific system resource and send the data to the main tcollector process. This process then sends the data to the dedicated time series database. We created custom scripts to monitor processes launched by the \textit{prefactor} pipeline (\ref{sec:ch4_customcollectors}). 
+\textit{tcollector} is a software package that automatically launches 'collector' scripts. These scripts sample the specific system resource and send the data to the main tcollector process. This process then sends the data to the dedicated time series database. We created custom scripts to monitor processes launched by the \textit{prefactor} pipeline (\ref{sec:ch4_customcollectors}). 
 
 In this work, we use a sample LOFAR SKSP data set as a test case. A particular focus was to understand the effect of hardware on the bottlenecks of the LOFAR data reduction. To gain insight into the effect of hardware on \textit{prefactor} performance, the data was processed on four different hardware configurations (Table \ref{tab:ch4_nodes}). As typical upgrade cycle for cluster hardware is five years, our results will be used to select optimal hardware for future clusters tasked with LOFAR processing.  
 
@@ -19,14 +19,14 @@ \subsection{\textit{Prefactor} Pipeline}
 \begin{figure}[H]
     \centering
     \includegraphics[width=0.5\linewidth]{ch4/figures/fig1/fig1.pdf}
-      \caption[The four processing stages that make up the prefactor pipeline.]{The four processing stages that make up the prefactor pipeline. The Calibrator stages (top) process a known bright calibrator to obtain the gain for the LOFAR antennas. The Target stages (bottom) process the scientific observation to remove Direction Independent effects. The \textit{pref\_cal1} and \textit{pref\_targ1} stages are massively parallelized across nodes without the need of an interconnect. The \textit{pref\_cal2} step runs only on one node, while \textit{pref\_targ2} is parallelized on 25 nodes. As the LOFAR software does not use MPI, we can run each processing job in isolation. }
+      \caption[The four processing stages that make up the prefactor pipeline.]{The four processing stages that make up the prefactor pipeline. The Calibrator stages (top) process a known bright calibrator to obtain the gain for the LOFAR antennas. The Target stages (bottom) process the scientific observation to remove Direction Independent effects. The \textit{pref\_cal1} and \textit{pref\_targ1} stages are massively parallelized across nodes without the need for an interconnect. The \textit{pref\_cal2} step runs only on one node, while \textit{pref\_targ2} is parallelized on 25 nodes. As the LOFAR software does not use MPI, we can run each processing job in isolation. }
 	\label{fig:ch4_four_steps_box}
 \end{figure}
 
 \begin{figure}[H]
     \centering
     \includegraphics[width=0.5\linewidth]{ch4/figures/fig2/4pies_thesis.png}
-      \caption[Portion of processing time taken by each step for the four prefactor stages.]{Portion of processing time taken by each step for the four prefactor stages, as reported by the Prefactor software. For each stage, the majority of processing time is spent during one or two steps. This is due to the fact that each prefactor stage also has intermediate book-keeping steps explicitly included in the pipeline. For each pipeline stage, the mean processing time for the longest running steps at SURFsara is also indicated. It should be noted that while faster, pref\_cal1 runs 10 times as many jobs as pref\_targ2. }
+      \caption[Portion of processing time taken by each step for the four prefactor stages.]{Portion of processing time taken by each step for the four prefactor stages, as reported by the Prefactor software. For each stage, the majority of processing time is spent during one or two steps. This is due to the fact that each prefactor stage also has intermediate book-keeping steps explicitly included in the pipeline. For each pipeline stage, the mean processing time for the longest-running steps at SURFsara is also indicated. It should be noted that while faster, pref\_cal1 runs ten times as many jobs as pref\_targ2. }
 	\label{fig:ch4_4_steps_pies}
 \end{figure}
 

ch3/chapter3.tex

@@ -134,7 +134,7 @@ \section{Introduction}\label{sec:ch5_intro}
 \end{itemize}
 
 \textbf{Outline:}
-The organization of this manuscript is as follows: We provide background on data processing in radio astronomy and why LOFAR science requires complex workflows and cover workflow management algorithms and capabilities (section \ref{sec:background}). We discuss related work in workflow management (section \ref{sec:related}). In section \ref{sec:AGLOW}, we introduce our software and two use cases. Both of our use cases require acceleration at an HTC cluster and automation by a workflow orchestration software. We follow these examples with details on the integration between LOFAR software, LOFAR data and the resources at SURFsara in Amsterdam in section \ref{sec:extending}. Finally, we discuss our results (sect. \ref{sec:results}) and look ahead to the demands of future LOFAR projects and upcoming telescopes in section \ref{sec:conclusions}. 
+The organisation of this manuscript is as follows: We provide background on data processing in radio astronomy and why LOFAR science requires complex workflows and cover workflow management algorithms and capabilities (section \ref{sec:background}). We discuss related work in workflow management (section \ref{sec:related}). In section \ref{sec:AGLOW}, we introduce our software and two use cases. Both of our use cases require acceleration at an HTC cluster and automation by a workflow orchestration software. We follow these examples with details on the integration between LOFAR software, LOFAR data and the resources at SURFsara in Amsterdam in section \ref{sec:extending}. Finally, we discuss our results (sect. \ref{sec:results}) and look ahead to the demands of future LOFAR projects and upcoming telescopes in section \ref{sec:conclusions}. 
 
 \section{Background}\label{sec:background}
 

ch4/chapter4.tex

@@ -43,9 +43,9 @@ \section{Limitations}
 
 Using the software described, the LOFAR Surveys team was able to process several petabytes of archived data and produce scientific quality images. Despite the successes of the project, several issues occasionally impede data processing and prevent rapid deployment of software pipelines.
 
-High throughput processing of LOFAR data requires the initial processing steps to be performed at the data archive locations. While deploying new versions of the LOFAR software and pipelines at SUFRsara is straightforward, the same is not true for other LTA locations. LOFAR data needs to be processed at LTA locations that do not support any modern containerization software nor other software distribution methods. This makes deploying new software is difficult and time-consuming. Additionally, orchestrating jobs at these sites requires additional integration with our job monitoring tools due to lack of internet acces from some HTC clusters. Integrating locations not suited for large scale distributed processing is an ongoing challenge for the LoTSS survey and other LOFAR projects.
+High throughput processing of LOFAR data requires the initial processing steps to be performed at the data archive locations. While deploying new versions of the LOFAR software and pipelines at SUFRsara is straightforward, the same is not true for other LTA locations. LOFAR data needs to be processed at LTA locations that do not support any modern containerization software nor other software distribution methods. This makes deploying new software is difficult and time-consuming. Additionally, orchestrating jobs at these sites requires additional integration with our job monitoring tools due to lack of internet access from some HTC clusters. Integrating locations not suited for large scale distributed processing is an ongoing challenge for the LoTSS survey and other LOFAR projects.
 
-A further limitation is the authentication of our processing software and the authentication requirements for data access. Distributed processing of large data sets requires having access to the data at multiple locations, however the intermediate products produced by our workflows are not public and require an active x.509 certificate authorized by the LOFAR SKSP project. The current workaround to this limitation is to maintain active certificates at each processing location. Upcoming features of the \gls{dCache} storage system, bearer tokens called macaroons, will make it possible to overcome this limitation.
+A further limitation is the authentication of our processing software and the authentication requirements for data access. Distributed processing of large data sets requires having access to the data at multiple locations, however the intermediate products produced by our workflows are not public and require an active x.509 certificate authorised by the LOFAR SKSP project. The current workaround to this limitation is to maintain active certificates at each processing location. Upcoming features of the \gls{dCache} storage system, bearer tokens called macaroons, will make it possible to overcome this limitation.
 
 Finally, our current software distribution does not assign long-term version numbers to software images and scripts, nor is there a way to store these images or cite them in related papers. Implementing proper versioning is crucial to not only making data processing easily reproducible, but also make it possible to recognize the effort put into building and distributing software images. Overcoming these limitations will enable FAIR science with LOFAR data\citep{wilkinson2016fair}.
 
@@ -54,8 +54,8 @@ \section{Future Work}
 
 This work focuses on the substantial gains possible by parallelization of LOFAR data processing. We take in mind the complexity of our processing workflows, the full range of scientific pipelines and the heterogeneous nature of the underlying infrastructure. Because of these factors, a wide range of astronomical pipelines can use the software presented in this work. Future automation of the LoTSS processing requires deciding on data quality requirements at each step and automated re-processing strategies in case a data quality check fails. Implementing intelligent re-processing strategies will reduce the human supervision currently necessary to provide high-quality large-scale surveys such as LoTSS. 
 
-Scientific projects with significant data rates such as Gaia and LSST provide users with an integrated environment to efficiently process archived observations. Having such a environment is a necessary step to gain fast and easy to gain insights into LOFAR data. This work presents a method enabling scientists to incorporate processing hosted at scientific institutions and cloud providers to scale scientific processing horizontally. 
+Scientific projects with significant data rates such as Gaia and LSST provide users with an integrated environment to efficiently process archived observations. Having such an environment is a necessary step to gain fast and easy to gain insights into LOFAR data. This work presents a method enabling scientists to incorporate processing hosted at scientific institutions and cloud providers to scale scientific processing horizontally. 
 
-One application for such large scale distributed processing is the Square kilometer Array. The Square Kilometer Array, (SKA) is a planned aperture synthesis radio telescope expected to have a total collecting area of one square kilometer. It is expected to produce more than 160 TB per day \citep{johnston2017taming}, data which needs to be processed. Scaling our tools to SKA-size processing requires a federation of clusters able to handle a high throughput workload. Nevertheless, as the SKA data processing will use different software tools than LOFAR, further study is needed on the optimal processing strategy for each of the many SKA science projects.
+One application for such large scale distributed processing is the Square kilometre Array. The Square Kilometer Array, (SKA) is a planned aperture synthesis radio telescope expected to have a total collecting area of one square kilometre. It is expected to produce more than 160 TB per day \citep{johnston2017taming}, data which needs to be processed. Scaling our tools to SKA-size processing requires a federation of clusters able to handle a high throughput workload. Nevertheless, as the SKA data processing will use different software tools than LOFAR, further study is needed on the optimal processing strategy for each of the many SKA science projects.
 
-In recent years, academia has begun focusing on ease of access and reproducibility of science. Science done with cutting edge instruments, such as LOFAR, tends to be time-consuming to reproduce. Barriers such as setting up a working software environment and downloading massive data-sets prevent scientists from quickly and easily reproducing the results of their peers. These barriers make it difficult to verify the accuracy of discoveries and need to be overcome in order to make astronomy more honest and transparent. Automatically building, testing, versioning and releasing docker and singularity images is critical to making science in radio astronomy easily reproducible. Creating a LOFAR science portal and integrating our tools and software images with this portal is crucial to making radio astronomy both more accessible and more authoritative.
+In recent years, academia has begun focusing on ease of access and reproducibility of science. Science done with cutting edge instruments, such as LOFAR, tends to be time-consuming to reproduce. Barriers such as setting up a working software environment and downloading massive data-sets prevent scientists from quickly and easily reproducing the results of their peers. These barriers make it difficult to verify the accuracy of discoveries and need to be overcomed in order to make astronomy more honest and transparent. Automatically building, testing, versioning and releasing docker and singularity images is critical to making science in radio astronomy easily reproducible. Creating a LOFAR science portal and integrating our tools and software images with this portal is crucial to making radio astronomy both more accessible and more authoritative.

ch4/section_2.tex

@@ -73,7 +73,7 @@
 \newglossaryentry{VOMS}
 {
     name=VOMS,
-    description={The Virtual Organization Membership Service is a service that manages the access to data and computational resources provided to each Grid user. It handles authentication and authorization of job launching and access to data on the grid filesystem. More information can be found at \url{https://italiangrid.github.io/voms/} }
+    description={The Virtual Organization Membership Service is a service that manages the access to data and computational resources provided to each Grid user. It handles authentication and authorisation of job launching and access to data on the grid filesystem. More information can be found at \url{https://italiangrid.github.io/voms/} }
 }
 
 \newglossaryentry{CouchDB}