diff options
Diffstat (limited to 'paper.tex')
| -rw-r--r-- | paper.tex | 828 |
1 files changed, 562 insertions, 266 deletions
@@ -1,76 +1,45 @@ -%% Copyright (C) 2018-2020 Mohammad Akhlaghi <mohammad@akhlaghi.org> -%% See the end of the file for license conditions. -\documentclass[10pt, twocolumn]{article} - -%% (OPTIONAL) CONVENIENCE VARIABLE: Only relevant when you use Maneage's -%% '\includetikz' macro to build plots/figures within LaTeX using TikZ or -%% PGFPlots. If so, when the Figure files (PDFs) are already built, you can -%% avoid TikZ or PGFPlots completely by commenting/removing the definition -%% of '\makepdf' below. This is useful when you don't want to slow-down a -%% LaTeX-only build of the project (for example this happens when you run -%% './project make dist'). See the definition of '\includetikz' in -%% `tex/preamble-pgfplots.tex' for more. +%% Main LaTeX source of project's paper, license is printed in the end. +% +%% Copyright (C) 2020 Mohammad Akhlaghi <mohammad@akhlaghi.org> +%% Copyright (C) 2020 Raúl Infante-Sainz <infantesainz@gmail.com> +%% Copyright (C) 2020 Boudewijn F. Roukema <boud@astro.uni.torun.pl> +%% Copyright (C) 2020 David Valls-Gabaud <david.valls-gabaud@obspm.fr> +%% Copyright (C) 2020 Roberto Baena-Gallé <roberto.baena@gmail.com> +\documentclass[journal]{IEEEtran} + +%% This is a convenience variable if you are using PGFPlots to build plots +%% within LaTeX. If you want to import PDF files for figures directly, you +%% can use the standard `\includegraphics' command. See the definition of +%% `\includetikz' in `tex/preamble-pgfplots.tex' for where the files are +%% assumed to be if you use `\includetikz' when `\makepdf' is not defined. \newcommand{\makepdf}{} -%% (OPTIONAL) CONVENIENCE VARIABLE: Only relevant when -%% 'tex/src/preamble-necessary.tex' is included (in particular the small -%% patch relating to '\highlightchanges'). In there, Maneage defines two -%% macros: `\tonote' and `\new'. When '\highlightchanges' is defined (value -%% is irrelevant), the text in those two macros becomes colored (in the -%% former, the text becomes dark red, in the latter it becomes dark -%% green). When not defined, text in the former isn't printed in the output -%% at all, and text in the latter becomes the same color as the rest of the -%% text. This is useful in cases that you need to distribute drafts and you -%% want to hightlight the new parts and add notes in the middle of the text -%% only for discussion, and build a clean PDF without any such highlights -%% without modifying the text. -\newcommand{\highlightchanges}{} - -%% VALUES FROM ANALYSIS (NUMBERS AND STRINGS): these are automatically -%% generated by the analysis phase of the project. The files loaded by -%% 'project.tex' only contain macro definitions (with '\newcommand') and -%% nothing else. So they won't interfere with any LaTeX style and can be -%% safely used in any pre-defined style. -\input{tex/build/macros/project.tex} +%% When defined (value is irrelevant), `\highlightchanges' will cause text +%% in `\tonote' and `\new' to become colored. This is useful in cases that +%% you need to distribute drafts that is undergoing revision and you want +%% to highlight to your colleagues which parts are new and which parts are +%% only for discussion. +%\newcommand{\highlightchanges}{} -%% CUSTOM PREAMBLES FOR DEMO: You can remove them if you are using a -%% specific journal style, or don't need features like BibLaTeX (advanced -%% bibliography management) or PGFPlots (for drawing plots within LaTeX -%% directly from tables of data). If you don't need them, you can also -%% delete their files from your branch to keep the 'tex/src' directory on -%% your branch clean. -\input{tex/src/preamble-style.tex} -\input{tex/src/preamble-header.tex} -\input{tex/src/preamble-biblatex.tex} +%% Import necessary packages +\input{tex/build/macros/project.tex} +\input{tex/src/preamble-project.tex} \input{tex/src/preamble-pgfplots.tex} -\input{tex/src/preamble-necessary.tex} -%% PROJECT TITLE: The project title should also be printed as metadata in -%% all output files. To avoid inconsistancy caused by manually typing it, -%% the title is defined with other core project metadata in -%% 'reproduce/analysis/config/metadata.conf'. That value is then written in -%% the '\projectitle' LaTeX macro by -%% 'reproduce/analysis/make/initialize.mk' and is directly used here. So -%% please set your project's title in 'metadata.conf' (ideally with other -%% basic project information) and re-run the project to have your new -%% title. If you later use a different LaTeX style, please use the same -%% '\projectitle' in it (after importing 'tex/build/macros/project.tex' -%% like above), don't type it by hand. -\title{\large \uppercase{\projecttitle}} +%% Title and author names. +\title{\projecttitle} +\author{ + Mohammad~Akhlaghi, + Ra\'ul Infante-Sainz, + Boudewijn F. Roukema, + David Valls-Gabaud, + Roberto Baena-Gall\'e + \thanks{Manuscript received MM DD, YYYY; revised MM DD, YYYY.} +} -%% AUTHOR INFORMATION: For a more fine-grained control of the headers -%% including author name, or paper info, see -%% `tex/src/preamble-header.tex'. Note that if you plan to use a journal's -%% LaTeX style file, you will probably set the authors in a different way, -%% feel free to change them here, this part is not related to the analysis. -\author[1]{Your name} -\author[2]{Coauthor one} -\author[1,3]{Coauthor two} -\affil[1]{The first affiliation in the list.; \url{your@email.address}} -\affil[2]{Another affilation can be put here.} -\affil[3]{And generally as many affiliations as you like. -\par \emph{Received YYYY MM DD; accepted YYYY MM DD; published YYYY MM DD}} -\date{} +%% The paper headers +\markboth{Computing in Science and Engineering, Vol. X, No. X, MM YYYY}% +{Akhlaghi \MakeLowercase{\textit{et al.}}: Towards Long-term and Archivable Reproducibility} @@ -81,205 +50,535 @@ -%% Start creating the paper. +%% Start the paper. \begin{document} -%% Project abstract and keywords. -\includeabstract{ - - Welcome to Maneage (\emph{Man}aging data lin\emph{eage}) and reproducible - papers/projects, for a review of the basics of this system, please see - \citet{maneage}. You are now ready to configure Maneage and implement - your own research in this framework. Maneage contains almost all the - elements that you will need in a research project, and adding any missing - parts is very easy once you become familiar with it. For example it - already has steps to downloading of raw data and necessary software - (while verifying them with their checksums), building the software, and - processing the data with the software in a highly-controlled - environment. But Maneage is not just for the analysis of your project, - you will also write your paper in it (by replacing this text in - \texttt{paper.tex}): including this abstract, figures and - bibliography. If you design your project with Maneage's infra-structure, - don't forget to add a notice and clearly let the readers know that your - work is reproducible, we should spread the word and show the world how - useful reproducible research is for the sciences, also don't forget to - cite and acknowledge it so we can continue developing it. This PDF was - made with Maneage, commit \projectversion{}. - - \vspace{0.25cm} - - \textsl{Keywords}: Add some keywords for your research here. - - \textsl{Reproducible paper}: All quantitave results (numbers and plots) - in this paper are exactly reproducible with Maneage - (\url{https://maneage.org}). } - -%% To add the first page's headers. -\thispagestyle{firststyle} - - - - - -%% Start of main body. -\section{Congratulations!} -Congratulations on running the raw template project! You can now follow the -``Customization checklist'' in the \texttt{README-hacking.md} file, -customize this template and start your exciting research project over -it. You can always merge Maneage back into your project to improve its -infra-structure and leaving your own project intact. If you haven't already -read \citet{maneage}, please do so before continuing, it isn't long -(just 7 pages). - -While you are writing your paper, just don't forget to \emph{not} use -numbers or fixed strings (for example database urls like \url{\wfpctwourl}) -directly within your \LaTeX{} source. Put them in configuration files and -after using them in the analysis, pass them into the \LaTeX{} source -through macros in the same subMakefile that used them. For some already -published examples, please see -\citet{maneage}\footnote{\url{https://gitlab.com/makhlaghi/maneage-paper}}, -\citet{infantesainz20}\footnote{\url{https://gitlab.com/infantesainz/sdss-extended-psfs-paper}} -and -\citet{akhlaghi19}\footnote{\url{https://gitlab.com/makhlaghi/iau-symposium-355}}. Working -in this way, will let you focus clearly on your science and not have to -worry about fixing this or that number/name in the text. - -Once your project is ready for publication, there is also a ``Publication -checklist'' in \texttt{README-hacking.md} that will guide you in the steps -to do for making your project as FAIR as possible (Findable, Accessibile, -Interoperable, and Reusable). - -The default \LaTeX{} structure within Maneage also has two \LaTeX{} macros -for easy marking of text within your document as \emph{new} and -\emph{notes}. For example, \new{this text has been marked as \texttt{new}.} -\tonote{While this one is marked as \texttt{tonote}.} Please try commenting -the line that defines \texttt{highlightchanges} in \texttt{paper.tex} (by -adding a `\texttt{\%}' at the start of the line or simply deleting the -line). You will then notice that the line that was marked as \texttt{new} -will become black (totally blend in with the rest of the text) and the one -marked \texttt{tonote} will not be in the final PDF. You can thus use -\texttt{highlightchanges} to easily make copies of your research for -existing coauthors (who are just interested in the new parts or notes) and -new co-authors (who don't want to be distracted by these issues in their -first time reading). - -Figure \ref{squared} shows a simple plot as a demonstration of creating -plots within \LaTeX{} (using the {\small PGFP}lots package). The minimum -value in this distribution is $\deletememin$, and $\deletememax$ is the -maximum. Take a look into the \LaTeX{} source and you'll see these numbers -are actually macros that were calculated from the same dataset (they will -change if the dataset, or function that produced it, changes). - -The individual {\small PDF} file of Figure \ref{squared} is available under -the \texttt{tex/tikz/} directory of your build directory. You can use this -PDF file in other contexts (for example in slides showing your progress or -after publishing the work). If you want to directly use the {\small PDF} -file in the figure without having to let {\small T}i{\small KZ} decide if -it should be remade or not, you can also comment the \texttt{makepdf} macro -at the top of this \LaTeX{} source file. - -\begin{figure}[t] - \includetikz{delete-me-squared}{width=\linewidth} - - \captionof{figure}{\label{squared} A very basic $X^2$ plot for - demonstration.} -\end{figure} - -Figure \ref{image-histogram} is another demonstration of showing images -(datasets) using PGFPlots. It shows a small crop of an image from the -Wide-Field Planetary Camera 2 (that was installed on the Hubble Space -Telescope from 1993 to 2009). As another more realistic demonstration of -reporting results with Maneage, here we report that the mean pixel value in -that image is $\deletemewfpctwomean$ and the median is -$\deletemewfpctwomedian$. The skewness in the histogram of Figure -\ref{image-histogram}(b) explains this difference between the mean and -median. The dataset is visualized here as a black and white image using the -\textsf{Convert\-Type} program of GNU Astronomy Utilities (Gnuastro). The -histogram and basic statstics were generated with Gnuastro's -\textsf{Statistics} program. - -{\small PGFP}lots\footnote{\url{https://ctan.org/pkg/pgfplots}} is a great -tool to build the plots within \LaTeX{} and removes the necessity to add -further dependencies, just to create the plots. There are high-level -libraries like Matplotlib which also generate plots. However, the problem -is that they require \emph{many} dependencies, for example see Figure 1 of -\citet{alliez19}. Installing these dependencies from source, is not easy -and will harm the reproducibility of your paper in the future. - -Furthermore, since {\small PGFP}lots builds the plots within \LaTeX{}, it -respects all the properties of your text (for example line width and fonts -and etc). Therefore the final plot blends in your paper much more -nicely. It also has a wonderful -manual\footnote{\url{http://mirrors.ctan.org/graphics/pgf/contrib/pgfplots/doc/pgfplots.pdf}}. - -\begin{figure}[t] - \includetikz{delete-me-image-histogram}{width=\linewidth} - - \captionof{figure}{\label{image-histogram} (a) An example image - of the Wide-Field Planetary Camera 2, on board the Hubble Space - Telescope from 1993 to 2009. This is one of the sample images from the - FITS standard webpage, kept as examples for this file format. (b) - Histogram of pixel values in (a).} -\end{figure} - - - -\section{Notice and citations} -To encourage other scientists to publish similarly reproducible papers, -please add a notice close to the start of your paper or in the end of the -abstract clearly mentioning that your work is fully reproducible. One -convention we have adopted until now is to put the Git checkum of the -project as the last word of the abstract, for example see -\citet{akhlaghi19}, \citet{infantesainz20} and \citet{maneage} - -Finally, don't forget to cite \citet{maneage} and acknowledge the -funders mentioned below. Otherwise we won't be able to continue working on -Maneage. Also, just as another reminder, before publication, don't forget -to follow the ``Publication checklist'' of \texttt{README-hacking.md}. -%% End of main body. - - - - - -\section{Acknowledgments} -\new{Please include the following two paragraphs in the Acknowledgement - section of your paper. Maneage was developed in parallel with Gnuastro, - so it benefited from the same grants. If you don't use Gnuastro in your - final/customized project, please remove it from the paragraph below, only - mentioning the reproducible paper template.} - -This project was developed in the reproducible framework of Maneage -\citep[\emph{Man}aging data lin\emph{eage},][latest Maneage commit of - \maneageversion, and built on an {\machinearchitecture} machine with - {\machinebyteorder} byte-order]{maneage}. Maneage has been -funded partially by the following grants: Japanese Ministry of Education, -Culture, Sports, Science, and Technology (MEXT) PhD scholarship to -M. Akhlaghi and its Grant-in-Aid for Scientific Research (21244012, -24253003). The European Research Council (ERC) advanced grant -339659-MUSICOS. The European Union (EU) Horizon 2020 (H2020) research and -innovation programmes No 777388 under RDA EU 4.0 project, and Marie -Sk\l{}odowska-Curie grant agreement No 721463 to the SUNDIAL ITN. The State -Research Agency (AEI) of the Spanish Ministry of Science, Innovation and -Universities (MCIU) and the European Regional Development Fund (ERDF) under -the grant AYA2016-76219-P. The IAC project P/300724, financed by the MCIU, -through the Canary Islands Department of Economy, Knowledge and Employment. - -%% Tell BibLaTeX to put the bibliography list here. -\printbibliography - -%% Start appendix. -\appendix - -%% Mention all used software in an appendix. -\section{Software acknowledgement} -\input{tex/build/macros/dependencies.tex} - -%% Finish LaTeX -\end{document} +% make the title area +\maketitle + +% As a general rule, do not put math, special symbols or citations +% in the abstract or keywords. +\begin{abstract} + %% CONTEXT + Analysis pipelines commonly use high-level technologies that are popular when created, but are unlikely to be sustainable in the long term. + %% AIM + We therefore aim to introduce a set of criteria to address this problem. + %% METHOD + These criteria have been tested in several research publications and have the following features: completeness (no dependency beyond POSIX, no administrator privileges, no network connection, and storage primarily in plain text); modular design; minimal complexity; scalability; verifiable inputs and outputs; version control; linking analysis with narrative; and free software. + %% RESULTS + As a proof of concept, ``Maneage'' is introduced for storing projects in machine-actionable and human-readable + plain text, enabling cheap archiving, provenance extraction, and peer verification. + %% CONCLUSION + We show that longevity is a realistic requirement that does not sacrifice immediate or short-term reproducibility. + We then discuss the caveats (with proposed solutions) and conclude with the benefits for the various stakeholders. + This paper is itself written with Maneage (project commit \projectversion). + + \vspace{3mm} + \emph{Reproducible supplement} --- All products in \href{https://doi.org/10.5281/zenodo.\projectzenodoid}{\texttt{zenodo.\projectzenodoid}}, + Git history of source at \href{https://gitlab.com/makhlaghi/maneage-paper}{\texttt{gitlab.com/makhlaghi/maneage-paper}}, + which is also archived on \href{https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://gitlab.com/makhlaghi/maneage-paper.git}{SoftwareHeritage}. +\end{abstract} + +% Note that keywords are not normally used for peer-review papers. +\begin{IEEEkeywords} +Data Lineage, Provenance, Reproducibility, Scientific Pipelines, Workflows +\end{IEEEkeywords} + + + + + + -%% This file is part of Maneage (https://maneage.org). +% For peer review papers, you can put extra information on the cover +% page as needed: +% \ifCLASSOPTIONpeerreview +% \begin{center} \bfseries EDICS Category: 3-BBND \end{center} +% \fi % +% For peerreview papers, this IEEEtran command inserts a page break and +% creates the second title. It will be ignored for other modes. +\IEEEpeerreviewmaketitle + + + +\section{Introduction} +% The very first letter is a 2 line initial drop letter followed +% by the rest of the first word in caps. +%\IEEEPARstart{F}{irst} word + +Reproducible research has been discussed in the sciences for at least 30 years \cite{claerbout1992, fineberg19}. +Many reproducible workflow solutions (hereafter, ``solutions'') have been proposed that mostly rely on the common technology of the day, +starting with Make and Matlab libraries in the 1990s, Java in the 2000s, and mostly shifting to Python during the last decade. + +However, these technologies develop fast, e.g., Python 2 code often cannot run with Python 3. +The cost of staying up to date within this rapidly-evolving landscape is high. +Scientific projects, in particular, suffer the most: scientists have to focus on their own research domain, but to some degree +they need to understand the technology of their tools because it determines their results and interpretations. +Decades later, scientists are still held accountable for their results and therefore the evolving technology landscape +creates generational gaps in the scientific community, preventing previous generations from sharing valuable experience. + + + + + +\section{Commonly used tools and their longevity} +Longevity is as important in science as in some fields of industry, but this ideal is not always necessary; e.g., fast-evolving tools can be appropriate in short-term commercial projects. +To highlight the necessity, some of the most commonly-used tools are reviewed here from this perspective. +A set of third-party tools that are commonly used in solutions are reviewed here. +They can be categorized as: +(1) environment isolators -- virtual machines (VMs) or containers; +(2) package managers (PMs) -- Conda, Nix, or Spack; +(3) job management -- shell scripts, Make, SCons, or CGAT-core; +(4) notebooks -- Jupyter. + +To isolate the environment, VMs have sometimes been used, e.g., in \href{https://is.ieis.tue.nl/staff/pvgorp/share}{SHARE} (which was awarded second prize in the Elsevier Executable Paper Grand Challenge of 2011 but was discontinued in 2019). +However, containers (in particular, Docker, and to a lesser degree, Singularity) are currently the most widely-used solution. +We will thus focus on Docker here. + +Ideally, it is possible to precisely identify the Docker ``images'' that are imported with their checksums, but that is rarely practiced in most solutions that we have surveyed. +Usually, images are imported with generic operating system (OS) names; e.g., \cite{mesnard20} uses `\inlinecode{FROM ubuntu:16.04}'. +The extracted tarball (from \url{https://partner-images.canonical.com/core/xenial}) is updated almost monthly and only the most recent five are archived. +Hence, if the Dockerfile is run in different months, its output image will contain different OS components. +In the year 2024, when long-term support for this version of Ubuntu expires, the image will be unavailable at the expected URL. +Generally, Pre-built binary files (like Docker images) are large and expensive to maintain and archive. +%% This URL: https://www.docker.com/blog/scaling-dockers-business-to-serve-millions-more-developers-storage/} +This prompted DockerHub (an online service to host Docker images, including many reproducible workflows) to delete images that have not been used for over 6 months. +Furthermore, Docker requires root permissions, and only supports recent (``long-term-support'') versions of the host kernel, so older Docker images may not be executable. + +Once the host OS is ready, PMs are used to install the software or environment. +Usually the OS's PM, such as `\inlinecode{apt}' or `\inlinecode{yum}', is used first and higher-level software are built with generic PMs. +The former suffers from the same longevity problem as the OS, while some of the latter (such as Conda and Spack) are written in high-level languages like Python, so the PM itself depends on the host's Python installation. +Nix and GNU Guix produce bit-wise identical programs, but they need root permissions and are primarily targeted at the Linux kernel. +Generally, the exact version of each software's dependencies is not precisely identified in the PM build instructions (although this could be implemented). +Therefore, unless precise version identifiers of \emph{every software package} are stored by project authors, a PM will use the most recent version. +Furthermore, because third-party PMs introduce their own language, framework, and version history (the PM itself may evolve) and are maintained by an external team, they increase a project's complexity. + +With the software environment built, job management is the next component of a workflow. +Visual workflow tools like Apache Taverna, GenePattern, Kepler or VisTrails (mostly introduced in the 2000s and using Java) encourage modularity and robust job management, but the more recent tools (mostly in Python) leave this to the authors of the project. +Designing a modular project needs to be encouraged and facilitated because scientists (who are not usually trained in project or data management) will rarely apply best practices. +This includes automatic verification, which is possible in many solutions, but is rarely practiced. +Weak project management leads to many inefficiencies in project cost and/or scientific accuracy (reusing, expanding, or validating will be expensive). + +Finally, to add narrative, computational notebooks \cite{rule18}, such as Jupyter, are currently gaining popularity. +However, because of their complex dependency trees, they are vulnerable to the passage of time; e.g., see Figure 1 of \cite{alliez19} for the dependencies of Matplotlib, one of the simpler Jupyter dependencies. +It is important to remember that the longevity of a project is determined by its shortest-lived dependency. +Further, as with job management, computational notebooks do not actively encourage good practices in programming or project management, hence they can rarely deliver their promised potential \cite{rule18} and may even hamper reproducibility \cite{pimentel19}. + +An exceptional solution we encountered was the Image Processing Online Journal (IPOL, \href{https://www.ipol.im}{ipol.im}). +Submitted papers must be accompanied by an ISO C implementation of their algorithm (which is buildable on any widely used OS) with example images/data that can also be executed on their webpage. +This is possible owing to the focus on low-level algorithms with no dependencies beyond an ISO C compiler. +However, many data-intensive projects commonly involve dozens of high-level dependencies, with large and complex data formats and analysis, and hence this solution is not scalable. + + + + + +\section{Proposed criteria for longevity} +The main premise is that starting a project with a robust data management strategy (or tools that provide it) is much more effective, for researchers and the community, than imposing it at the end \cite{austin17,fineberg19}. +In this context, researchers play a critical role \cite{austin17} in making their research more Findable, Accessible, +Interoperable, and Reusable (the FAIR principles). +Simply archiving a project workflow in a repository after the project is finished is, on its own, insufficient, and maintaining it by repository staff is often either practically unfeasible or unscalable. +We argue and propose that workflows satisfying the following criteria can not only improve researcher flexibility during a research project, but can also increase the FAIRness of the deliverables for future researchers: + +\textbf{Criterion 1: Completeness.} +A project that is complete (self-contained) has the following properties. +(1) No dependency beyond the Portable Operating System Interface: POSIX (a minimal Unix-like environment). +POSIX has been developed by the Austin Group (which includes IEEE) since 1988 and many OSes have complied. +(2) Primarily stored as plain text, not needing specialized software to open, parse, or execute. +(3) No affect on the host OS libraries, programs or environment. +(4) Does not require root privileges to run (during development or post-publication). +(5) Builds its own controlled software for an independent environment. +(6) Can run locally (without an internet connection). +(7) Contains the full project's analysis, visualization \emph{and} narrative: including instructions to automatically access/download raw inputs, build necessary software, do the analysis, produce final data products \emph{and} final published report with figures \emph{as output}, e.g., PDF or HTML. +(8) It can run automatically, with no human interaction. + +\textbf{Criterion 2: Modularity.} +A modular project enables and encourages the analysis to be broken into independent modules with well-defined inputs/outputs and minimal side effects. +Explicit communication between various modules enables optimizations on many levels: +(1) Execution in parallel and avoiding redundancies (when a dependency of a module has not changed, it will not be re-run). +(2) Usage in other projects. +(3) Easy debugging and improvements. +(4) Modular citation of specific parts. +(5) Provenance extraction. + +\textbf{Criterion 3: Minimal complexity.} +Minimal complexity can be interpreted as: +(1) Avoiding the language or framework that is currently in vogue (for the workflow, not necessarily the high-level analysis). +A popular framework typically falls out of fashion and requires significant resources to translate or rewrite every few years. +More stable/basic tools can be used with less long-term maintenance. +(2) Avoiding too many different languages and frameworks; e.g., when the workflow's PM and analysis are orchestrated in the same framework, it becomes easier to adopt and encourages good practices. + +\textbf{Criterion 4: Scalability.} +A scalable project can easily be used in arbitrarily large and/or complex projects. +On a small scale, the criteria here are trivial to implement, but can rapidly become unsustainable. + +\textbf{Criterion 5: Verifiable inputs and outputs.} +The project should automatically verify its inputs (software source code and data) \emph{and} outputs, not needing any expert knowledge. + +\textbf{Criterion 6: Recorded history.} +No exploratory research is done in a single, first attempt. +Projects evolve as they are being completed. +It is natural that earlier phases of a project are redesigned/optimized only after later phases have been completed. +Research papers often report this with statements such as ``\emph{we [first] tried method [or parameter] X, but Y is used here because it gave lower random error}''. +The derivation ``history'' of a result is thus not any the less valuable as itself. + +\textbf{Criterion 7: Including narrative, linked to analysis.} +A project is not just its computational analysis. +A raw plot, figure or table is hardly meaningful alone, even when accompanied by the code that generated it. +A narrative description must is also a deliverable (defined as ``data article'' in \cite{austin17}): describing the purpose of the computations, and interpretations of the result, and the context in relation to other projects/papers. +This is related to longevity, because if a workflow contains only the steps to do the analysis or generate the plots, in time it may get separated from its accompanying published paper. + +\textbf{Criterion 8: Free and open source software:} +Reproducibility (defined in \cite{fineberg19}) is possible with a black box (non-free or non-open-source software); this criterion is therefore necessary because nature is already a black box. +A project that is free software (as formally defined), allows others to learn from, modify, and build upon it. +When the software used by the project is itself also free, the lineage can be traced to the core algorithms, possibly enabling optimizations on that level and it can be modified for future hardware. +In contrast, non-free tools typically cannot be distributed or modified by others, making it reliant on a single supplier (even without payments). + + + + + + + + + + +\section{Proof of concept: Maneage} + +With the longevity problems of existing tools outlined above, a proof-of-concept tool is presented here via an implementation that has been tested in published papers \cite{akhlaghi19, infante20}. +It was in fact awarded a Research Data Alliance (RDA) adoption grant for implementing the recommendations of the joint RDA and World Data System (WDS) working group on Publishing Data Workflows \cite{austin17}, from the researchers' perspective. + +The tool is called Maneage, for \emph{Man}aging data Lin\emph{eage} (the ending is pronounced as in ``lineage''), hosted at \url{https://maneage.org}. +It was developed as a parallel research project over five years of publishing reproducible workflows of our research. +The original implementation was published in \cite{akhlaghi15}, and evolved in \href{http://doi.org/10.5281/zenodo.1163746}{zenodo.1163746} and \href{http://doi.org/10.5281/zenodo.1164774}{zenodo.1164774}. + +Technically, the hardest criterion to implement was the first (completeness) and, in particular, avoiding non-POSIX dependencies). +One solution we considered was GNU Guix and Guix Workflow Language (GWL). +However, because Guix requires root access to install, and only works with the Linux kernel, it failed the completeness criterion. +Inspired by GWL+Guix, a single job management tool was implemented for both installing software \emph{and} the analysis workflow: Make. + +Make is not an analysis language, it is a job manager, deciding when and how to call analysis programs (in any language like Python, R, Julia, Shell, or C). +Make is standardized in POSIX and is used in almost all core OS components. +It is thus mature, actively maintained, highly optimized, efficient in managing exact provenance, and even recommended by the pioneers of reproducible research \cite{claerbout1992,schwab2000}. +Researchers using free software tools have also already had some exposure to it. +%However, because they didn't attempt to build the software environment, in 2006 they moved to SCons (Make-simulator in Python which also attempts to manage software dependencies) in a project called Madagascar (\url{http://ahay.org}), which is highly tailored to Geophysics. + +Linking the analysis and narrative (criterion 7) was historically our first design element. +To avoid the problems with computational notebooks mentioned above, our implementation follows a more abstract linkage, providing a more direct and precise, yet modular, connection. +Assuming that the narrative is typeset in \LaTeX{}, the connection between the analysis and narrative (usually as numbers) is through automatically-created \LaTeX{} macros, during the analysis. +For example, \cite{akhlaghi19} writes `\emph{... detect the outer wings of M51 down to S/N of 0.25 ...}'. +The \LaTeX{} source of the quote above is: `\inlinecode{\small detect the outer wings of M51 down to S/N of \$\textbackslash{}demo\-sf\-optimized\-sn\$}'. +The macro `\inlinecode{\small\textbackslash{}demosfoptimizedsn}' is generated during the analysis and expands to the value `\inlinecode{0.25}' when the PDF output is built. +Since values like this depend on the analysis, they should \emph{also} be reproducible, along with figures and tables. + +These macros act as a quantifiable link between the narrative and analysis, with the granularity of a word in a sentence and a particular analysis command. +This allows accurate post-publication provenance \emph{and} automatic updates to the embedded numbers during a project. +Through the latter, manual updates by authors are by-passed, which are prone to errors, thus discouraging improvements after writing the first draft. + +Acting as a link, the macro files build the core skeleton of Maneage. +For example, during the software building phase, each software package is identified by a \LaTeX{} file, containing its official name, version and possible citation. +These are combined at the end to generate precise software acknowledgment and citation (see \cite{akhlaghi19, infante20}), which are excluded here because of the strict word limit. +The macro files also act as Make \emph{targets} and \emph{prerequisites} to allow accurate dependency tracking and optimized execution (in parallel, no redundancies), for any level of complexity (e.g., Maneage builds Matplotlib if requested; see Figure~1 of \cite{alliez19}). +All software dependencies are built down to precise versions of every tool, including the shell, POSIX tools (e.g., GNU Coreutils) and ofcourse, the high-level science software. +On GNU/Linux distributions, even the GNU Compiler Collection (GCC) and GNU Binutils are built from source and the GNU C library (glibc) is being added (task \href{http://savannah.nongnu.org/task/?15390}{15390}). +Currently {\TeX}Live is also being added (task \href{http://savannah.nongnu.org/task/?15267}{15267}), but that is only for building the final PDF, not affecting the analysis or verification. +Temporary relocation of a built project, without building from source, can be done by building the project in a container or VM (\inlinecode{README.md} has recommendations on building a \inlinecode{Dockerfile}). + +The analysis phase of the project however is naturally different from one project to another at a low-level. +It was thus necessary to design a generic framework to comfortably host any project, while still satisfying the criteria of modularity, scalability, and minimal complexity. +We demonstrate this design by replicating Figure 1C of \cite{menke20} in Figure \ref{fig:datalineage} (top). +Figure \ref{fig:datalineage} (bottom) is the data lineage graph that produced it (including this complete paper). + +\begin{figure*}[t] + \begin{center} + \includetikz{figure-tools-per-year}{width=0.95\linewidth} +% \includetikz{figure-data-lineage}{width=0.85\linewidth} + \end{center} + \vspace{-3mm} + \caption{\label{fig:datalineage} + Left: an enhanced replica of Figure 1C in \cite{menke20}, shown here for demonstrating Maneage. + It shows the ratio of the number of papers mentioning software tools (green line, left vertical axis) to the total number of papers studied in that year (light red bars, right vertical axis on a log scale). + Right: Schematic representation of the data lineage, or workflow, to generate the plot above. + Each colored box is a file in the project and the arrows show the dependencies between them. + Green files/boxes are plain-text files that are under version control and in the project source directory. + Blue files/boxes are output files in the build directory, shown within the Makefile (\inlinecode{*.mk}) where they are defined as a \emph{target}. + For example, \inlinecode{paper.pdf} depends on \inlinecode{project.tex} (in the build directory; generated automatically) and \inlinecode{paper.tex} (in the source directory; written manually). + The solid arrows and full-opacity built boxes correspond to this paper. + The dotted arrows and built boxes show the scalability by adding hypothetical steps to the project. + The underlying data of the top plot is available at + \href{https://zenodo.org/record/\projectzenodoid/files/tools-per-year.txt}{zenodo.\projectzenodoid/tools-per-year.txt}. + } +\end{figure*} + +The analysis is orchestrated through a single point of entry (\inlinecode{top-make.mk}, which is a Makefile; see Listing \ref{code:topmake}). +It is only responsible for \inlinecode{include}-ing the modular \emph{subMakefiles} of the analysis, in the desired order, without doing any analysis itself. +This is visualized in Figure \ref{fig:datalineage} (bottom) where no built (blue) file is placed directly over \inlinecode{top-make.mk} (they are produced by the subMakefiles under them). +A visual inspection of this file is sufficient for a non-expert to understand the high-level steps of the project (irrespective of the low-level implementation details), provided that the subMakefile names are descriptive (thus encouraging good practice). +A human-friendly design that is also optimized for execution is a critical component for the FAIRness of reproducible research. + +\begin{lstlisting}[ + label=code:topmake, + caption={This project's simplified \inlinecode{top-make.mk}, also see Figure \ref{fig:datalineage}} + ] +# Default target/goal of project. +all: paper.pdf + +# Define subMakefiles to load in order. +makesrc = initialize \ # General + download \ # General + format \ # Project-specific + demo-plot \ # Project-specific + verify \ # General + paper # General + +# Load all the configuration files. +include reproduce/analysis/config/*.conf + +# Load the subMakefiles in the defined order +include $(foreach s,$(makesrc), \ + reproduce/analysis/make/$(s).mk) +\end{lstlisting} + +All projects first load \inlinecode{initialize.mk} and \inlinecode{download.mk}, and finish with \inlinecode{verify.mk} and \inlinecode{paper.mk} (Listing \ref{code:topmake}). +Project authors add their modular subMakefiles in between. +Except for \inlinecode{paper.mk} (which builds the ultimate target: \inlinecode{paper.pdf}), all subMakefiles build a macro file with the same base-name (the \inlinecode{.tex} file in each subMakefile of Figure \ref{fig:datalineage}). +Other built files (intermediate analysis steps) cascade down in the lineage to one of these macro files, possibly through other files. + +Just before reaching the ultimate target (\inlinecode{paper.pdf}), the lineage reaches a bottleneck in \inlinecode{verify.mk} to satisfy the verification criteria (this step was not yet available in \cite{akhlaghi19, infante20}). +All project deliverables (macro files, plot or table data and other datasets) are verified at this stage, with their checksums, to automatically ensure exact reproducibility. +Where exact reproducibility is not possible, values can be verified by any statistical means, specified by the project authors. + +\begin{figure*}[t] + \begin{center} \includetikz{figure-branching}{scale=1}\end{center} + \vspace{-3mm} + \caption{\label{fig:branching} Maneage is a Git branch. + Projects using Maneage are branched off it and apply their customizations. + (a) A hypothetical project's history prior to publication. + The low-level structure (in Maneage, shared between all projects) can be updated by merging with Maneage. + (b) A finished/published project can be revitalized for new technologies by merging with the core branch. + Each Git ``commit'' is shown on its branch as a colored ellipse, with its commit hash shown and colored to identify the team that is/was working on the branch. + Briefly, Git is a version control system, allowing a structured backup of project files. + Each Git ``commit'' effectively contains a copy all the project's files at the moment it was made. + The upward arrows at the branch-tops are therefore in the direction of time. + } +\end{figure*} + +To further minimize complexity, the low-level implementation can be further separated from the high-level execution through configuration files. +By convention in Maneage, the subMakefiles (and the programs they call for number crunching) do not contain any fixed numbers, settings, or parameters. +Parameters are set as Make variables in ``configuration files'' (with a \inlinecode{.conf} suffix) and passed to the respective program by Make. +For example, in Figure \ref{fig:datalineage} (bottom), \inlinecode{INPUTS.conf} contains URLs and checksums for all imported datasets, thereby enabling exact verification before usage. +To illustrate this, we report that \cite{menke20} studied $\menkenumpapersdemocount$ papers in $\menkenumpapersdemoyear$ (which is not in their original plot). +The number \inlinecode{\menkenumpapersdemoyear} is stored in \inlinecode{demo-year.conf} and the result (\inlinecode{\menkenumpapersdemocount}) was calculated after generating \inlinecode{tools-per-year.txt}. +Both numbers are expanded as \LaTeX{} macros when creating this PDF file. +An interested reader can change the value in \inlinecode{demo-year.conf} to automatically update the result in the PDF, without knowing the underlying low-level implementation. +Furthermore, the configuration files are a prerequisite of the targets that use them. +If changed, Make will \emph{only} re-execute the dependent recipe and all its descendants, with no modification to the project's source or other built products. +This fast and cheap testing encourages experimentation (without necessarily knowing the implementation details; e.g., by co-authors or future readers), and ensures self-consistency. + +Finally, to satisfy the recorded history criterion, version control (currently implemented in Git) is another component of Maneage (see Figure \ref{fig:branching}). +Maneage is a Git branch that contains the shared components (infrastructure) of all projects (e.g., software tarball URLs, build recipes, common subMakefiles, and interface script). +Derived projects start by branching off and customizing it (e.g., adding a title, data links, narrative, and subMakefiles for its particular analysis, see Listing \ref{code:branching}, there is customization checklist in \inlinecode{README-hacking.md}). + +The branch-based design of Figure \ref{fig:branching} allows projects to re-import Maneage at a later time (technically: \emph{merge}), thus improving its low-level infrastructure: in (a) authors do the merge during an ongoing project; +in (b) readers do it after publication; e.g., the project remains reproducible but the infrastructure is outdated, or a bug is fixed in Maneage. +Low-level improvements in Maneage can thus propagate to all projects, greatly reducing the cost of curation and maintenance of each individual project, before \emph{and} after publication. + +Finally, the complete project source is usually $\sim100$ kilo-bytes. +It can thus easily be published or archived in many servers, for example it can be uploaded to arXiv (with the \LaTeX{} source, see the arXiv source in \cite{akhlaghi19, infante20, akhlaghi15}), published on Zenodo and archived in SoftwareHeritage. + +\begin{lstlisting}[ + label=code:branching, + caption={Starting a new project with Maneage, and building it}, + ] +# Cloning main Maneage branch and branching off it. +$ git clone https://git.maneage.org/project.git +$ cd project +$ git remote rename origin origin-maneage +$ git checkout -b master + +# Build the raw Maneage skeleton in two phases. +$ ./project configure # Build software environment. +$ ./project make # Do analysis, build PDF paper. + +# Start editing, test-building and committing +$ emacs paper.tex # Set your name as author. +$ ./project make # Re-build to see effect. +$ git add -u && git commit # Commit changes. +\end{lstlisting} + + + + + + + + + + +\section{Discussion} + +%% It should provide some insight or 'lessons learned', where 'lessons learned' is jargon for 'informal hypotheses motivated by experience', reworded to make the hypotheses sound more scientific (if it's a 'lesson', then it sounds like knowledge, when in fact it's really only a hypothesis). +%% What is the message we should take from the experience? +%% Are there clear demonstrated design principles that can be reapplied elsewhere? +%% Are there roadblocks or bottlenecks that others might avoid? +%% Are there suggested community or work practices that can make things smoother? +%% Attempt to generalise the significance. +%% should not just present a solution or an enquiry into a unitary problem but make an effort to demonstrate wider significance and application and say something more about the ‘science of data’ more generally. + +We have shown that it is possible to build workflows satisfying all the proposed criteria, and we comment here on our experience in testing them through this proof-of-concept tool. +Maneage user-base grew with the support of RDA, underscoring some difficulties for a widespread adoption. + +Firstly, while most researchers are generally familiar with them, the necessary low-level tools (e.g., Git, \LaTeX, the command-line and Make) are not widely used. +Fortunately, we have noticed that after witnessing the improvements in their research, many, especially early-career researchers, have started mastering these tools. +Scientists are rarely trained sufficiently in data management or software development, and the plethora of high-level tools that change every few years discourages them. +Indeed the fast-evolving tools are primarily targeted at software developers, who are paid to learn and use them effectively for short-term projects before moving on to the next technology. + +Scientists, on the other hand, need to focus on their own research fields, and need to consider longevity. +Hence, arguably the most important feature of these criteria (as implemented in Maneage) is that they provide a fully working template, using mature and time-tested tools, for blending version control, the research paper's narrative, the software management \emph{and} a robust data carpentry. +We have noticed that providing a complete \emph{and} customizable template with a clear checklist of the initial steps is much more effective in encouraging mastery of these modern scientific tools than having abstract, isolated tutorials on each tool individually. + +Secondly, to satisfy the completeness criterion, all the required software of the project must be built on various POSIX-compatible systems (Maneage is actively tested on different GNU/Linux distributions, macOS, and is being ported to FreeBSD also). +This requires maintenance by our core team and consumes time and energy. +However, because the PM and analysis components share the same job manager (Make) and design principles, we have already noticed some early users adding, or fixing, their required software alone. +They later share their low-level commits on the core branch, thus propagating it to all derived projects. + +A related caveat is that, POSIX is a fuzzy standard, not guaranteeing the bit-wise reproducibility of programs. +It has been chosen here, however, as the underlying platform because our focus is on reproducing the results (data), which does not necessarily need bit-wise reproducible software. +POSIX is ubiquitous and low-level software (e.g., core GNU tools) are install-able on most; each internally corrects for differences affecting its functionality (partly as part of the GNU portability library). +On GNU/Linux hosts, Maneage builds precise versions of the compilation tool chain. +However, glibc is not install-able on some POSIX OSs (e.g., macOS). +All programs link with the C library, and this may hypothetically hinder the exact reproducibility \emph{of results} on non-GNU/Linux systems, but we have not encountered this in our research so far. +With everything else under precise control, the effect of differing Kernel and C libraries on high-level science can now be systematically studied with Maneage in follow-up research. + +% DVG: It is a pity that the following paragraph cannot be included, as it is really important but perhaps goes beyond the intended goal. +%Thirdly, publishing a project's reproducible data lineage immediately after publication enables others to continue with follow-up papers, which may provide unwanted competition against the original authors. +%We propose these solutions: +%1) Through the Git history, the work added by another team at any phase of the project can be quantified, contributing to a new concept of authorship in scientific projects and helping to quantify Newton's famous ``\emph{standing on the shoulders of giants}'' quote. +%This is a long-term goal and would require major changes to academic value systems. +%2) Authors can be given a grace period where the journal or a third party embargoes the source, keeping it private for the embargo period and then publishing it. + +Other implementations of the criteria, or future improvements in Maneage, may solve some of the caveats, but this proof of concept already shows their many advantages. +For example, publication of projects meeting these criteria on a wide scale will allow automatic workflow generation, optimized for desired characteristics of the results (e.g., via machine learning). +The completeness criterion implies that algorithms and data selection can be included in the optimizations. + +Furthermore, through elements like the macros, natural language processing can also be included, automatically analyzing the connection between an analysis with the resulting narrative \emph{and} the history of that analysis+narrative. +Parsers can be written over projects for meta-research and provenance studies, e.g., to generate ``research objects''. +Likewise, when a bug is found in one science software, affected projects can be detected and the scale of the effect can be measured. +Combined with SoftwareHeritage, precise high-level science components of the analysis can be accurately cited (e.g., even failed/abandoned tests at any historical point). +Many components of ``machine-actionable'' data management plans can also be automatically completed as a byproduct, useful for project PIs and grant funders. + +From the data repository perspective, these criteria can also be useful, e.g., the challenges mentioned in \cite{austin17}: +(1) The burden of curation is shared among all project authors and readers (the latter may find a bug and fix it), not just by database curators, thereby improving sustainability. +(2) Automated and persistent bidirectional linking of data and publication can be established through the published \emph{and complete} data lineage that is under version control. +(3) Software management: with these criteria, each project comes with its unique and complete software management. +It does not use a third-party PM that needs to be maintained by the data center (and the many versions of the PM), hence enabling robust software management, preservation, publishing, and citation. +For example, see \href{https://doi.org/10.5281/zenodo.3524937}{zenodo.3524937}, \href{https://doi.org/10.5281/zenodo.3408481}{zenodo.3408481}, \href{https://doi.org/10.5281/zenodo.1163746}{zenodo.1163746}, where we have exploited the free-software criterion to distribute the tarballs of all the software used with each project's source as deliverables. +(4) ``Linkages between documentation, code, data, and journal articles in an integrated environment'', which effectively summarizes the whole purpose of these criteria. + + + + + +% use section* for acknowledgment +\section*{Acknowledgment} + +The authors wish to thank (sorted alphabetically) +Julia Aguilar-Cabello, +Marjan Akbari, +Alice Allen, +Pedram Ashofteh Ardakani, +Roland Bacon, +Michael R. Crusoe, +Antonio D\'iaz D\'iaz, +Surena Fatemi, +Fabrizio Gagliardi, +Konrad Hinsen, +Marios Karouzos, +Mohammad-reza Khellat, +Johan Knapen, +Tamara Kovazh, +Terry Mahoney, +Ryan O'Connor, +Mervyn O'Luing, +Simon Portegies Zwart, +Idafen Santana-P\'erez, +Elham Saremi, +Yahya Sefidbakht, +Zahra Sharbaf, +Nadia Tonello, +Ignacio Trujillo and +the AMIGA team at the Instituto de Astrof\'isica de Andaluc\'ia +for their useful help, suggestions, and feedback on Maneage and this paper. + +Work on Maneage, and this paper, has been partially funded/supported by the following institutions: +The Japanese Ministry of Education, Culture, Sports, Science, and Technology (MEXT) PhD scholarship to +M. Akhlaghi and its Grant-in-Aid for Scientific Research (21244012, 24253003). +The European Research Council (ERC) advanced grant 339659-MUSICOS. +The European Union (EU) Horizon 2020 (H2020) research and innovation programmes No 777388 under RDA EU 4.0 project, and Marie +Sk\l{}odowska-Curie grant agreement No 721463 to the SUNDIAL ITN. +The State Research Agency (AEI) of the Spanish Ministry of Science, Innovation and Universities (MCIU) and the European +Regional Development Fund (ERDF) under the grant AYA2016-76219-P. +The IAC project P/300724, financed by the MCIU, through the Canary Islands Department of Economy, Knowledge and Employment. +The Fundaci\'on BBVA under its 2017 programme of assistance to scientific research groups, for the project ``Using machine-learning techniques to drag galaxies from the noise in deep imaging''. +The ``A next-generation worldwide quantum sensor network with optical atomic clocks'' project of the TEAM IV programme of the +Foundation for Polish Science co-financed by the EU under ERDF. +The Polish MNiSW grant DIR/WK/2018/12. +The Pozna\'n Supercomputing and Networking Center (PSNC) computational grant 314. + + + + + + + + + +%% Bibliography +\bibliographystyle{IEEEtran_openaccess} +\bibliography{IEEEabrv,references} + +%% Biography +\begin{IEEEbiographynophoto}{Mohammad Akhlaghi} + is a postdoctoral researcher at the Instituto de Astrof\'isica de Canarias, Tenerife, Spain. + His main scientific interest is in early galaxy evolution, but to extract information from the modern complex datasets, he has been involved in image processing and reproducible workflow management, where he has founded GNU Astronomy Utilities (Gnuastro) and Maneage (introduced here). + He received his PhD in astronomy from Tohoku University, Sendai Japan, and before coming to Tenerife, held a CNRS postdoc position at the Centre de Recherche Astrophysique de Lyon (CRAL), France. + Contact him at mohammad@akhlaghi.org and find his website at \url{https://akhlaghi.org}. +\end{IEEEbiographynophoto} + +\begin{IEEEbiographynophoto}{Ra\'ul Infante-Sainz} + is a doctoral student at the Instituto de Astrof\'isica de Canarias, Tenerife, Spain. + He has been concerned about the ability of reproducing scientific results since the start of his research and has thus been actively involved in development and testing of Maneage. + His main scientific interests are galaxy formation and evolution, studying the low-surface-brightness Universe through reproducible methods. + Contact him at infantesainz@gmail.com and find his website at \url{https://infantesainz.org}. +\end{IEEEbiographynophoto} + +\begin{IEEEbiographynophoto}{Boudewijn F. Roukema} + is a professor at the Institute of Astronomy in the Faculty of Physics, Astronomy and Informatics at Nicolaus Copernicus University in Toru\'n, Grudziadzka 5, Poland. + His research includes galaxy formation, large scale structure of the Universe, cosmic topology and inhomogeneous cosmology. + He is involved in experimental research aimed at improving standards in research reproducibility. + Roukema obtained his PhD in astronomy and astrophysics at the Australian National University. + Contact him at boud@astro.uni.torun.pl. +\end{IEEEbiographynophoto} + +\begin{IEEEbiographynophoto}{David Valls-Gabaud} + is a CNRS Research Director at the Observatoire de Paris, France. + His research interests span from cosmology and galaxy evolution to stellar physics and instrumentation. + He is adamant about ensuring that scientific results are fully reproducible. + Educated at the universities of Madrid (Complutense), Paris, and Cambridge, he obtained his PhD in astrophysics in 1991. + Contact him at david.valls-gabaud@obspm.fr. +\end{IEEEbiographynophoto} + +\begin{IEEEbiographynophoto}{Roberto Baena-Gall\'e} + is a postdoctoral researcher at the Instituto de Astrof\'isica de Canarias, Spain. + He previously worked at University of Barcelona, and ONERA-The French Aerospace Lab. + His research interests are image processing and resolution of inverse problems, following reproducibility standards. + Baena-Gall\'e has both MS in Telecommunication and Electronic Engineering from University of Seville (Spain) and received a PhD in astronomy from University of Barcelona (Spain). + Contact him at rbaena@iac.es. +\end{IEEEbiographynophoto} +\vfill +\end{document} + %% This file is free software: you can redistribute it and/or modify it %% under the terms of the GNU General Public License as published by the %% Free Software Foundation, either version 3 of the License, or (at your @@ -288,7 +587,4 @@ through the Canary Islands Department of Economy, Knowledge and Employment. %% This file is distributed in the hope that it will be useful, but WITHOUT %% ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or %% FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -%% for more details. -% -%% You should have received a copy of the GNU General Public License along -%% with this file. If not, see <http://www.gnu.org/licenses/>. +%% for more details. See <http://www.gnu.org/licenses/>. |