Fix multiply defined labels

This commit fixes the labels alliez19, claerbout1992, schwab2000
which were multiply defined. The problem was using \citeappendix
instead of \cite for these in the appendix, even though they
are first used in the official part of the article.

You must do './project make clean' before recreating the pdf
in order for this to compile correctly. (Otherwise you'll waste
time re-using old files; this means that one of our 'make'
dependencies could in principle be improved.)

With this change, these references in the pdf are (for me)
correct clickable links back to [5], [1], [11], respectively.
[If you use xpdf (poppler library), remember the 'b' key for
navigate back from a clicked internal link quickly.]
This way you can quickly navigate between the appendix text
and the references used, and you avoid LaTeX warning about
'multiply defined labels'.

1 files changed, 5 insertions, 5 deletions

diff --git a/paper.tex b/paper.tex
index 0a47096..20b463a 100644
--- a/paper.tex
+++ b/paper.tex
@@ -165,7 +165,7 @@ Usually images are imported with generic operating system (OS) names; e.g., \cit
 . The extracted tarball (from \url{https://partner-images.canonical.com/core/xenial}) is updated almost monthly, and only the most recent five are archived there.
   Hence, if the image is built in different months, its output image will contain different OS components.
 % CentOS announcement: https://blog.centos.org/2020/12/future-is-centos-stream
-In the year 2024, when long-term support (LTS) for this version of Ubuntu expires, the image will be unavailable at the expected URL \new{(if not abruptly aborted ealier, like CentOS 8 which will be terminated 8 years early).}
+In the year 2024, when long-term support (LTS) for this version of Ubuntu expires, the image will be unavailable at the expected URL \new{(if not abruptly aborted earlier, like CentOS 8 which will be terminated 8 years early).}
 Generally, \new{pre-built} binary files (like Docker images) are large and expensive to maintain and archive.
 %% This URL: https://www.docker.com/blog/docker-hub-image-retention-policy-delayed-and-subscription-updates}
 \new{Because of this, DockerHub (where many reproducible workflows are archived) announced that inactive images (older than 6 months) will be deleted in free accounts from mid 2021.}
@@ -999,7 +999,7 @@ Moreover, when two source files do not depend on each other, and both need to be
 This was found to greatly help in debugging software projects, and in speeding up test builds, giving Make a core place in software development over the last 40 years.
 
 The most common implementation of Make, since the early 1990s, is GNU Make.
-Make was also the framework used in the first attempts at reproducible scientific papers \citeappendix{claerbout1992,schwab2000}.
+Make was also the framework used in the first attempts at reproducible scientific papers \cite{claerbout1992,schwab2000}.
 Our proof-of-concept (Maneage) also uses Make to organize its workflow.
 Here, we'll complement that section with more technical details on Make.
 
@@ -1181,7 +1181,7 @@ This is not just limited to the core language, much faster changes occur in thei
 For example version 1.9 of Numpy (Python's numerical analysis module) discontinued support for Numpy's predecessor (called Numeric), causing many problems for scientific users \citeappendix{hinsen15}.
 
 On the other hand, the dependency graph of tools written in high-level languages is often extremely complex.
-For example see Figure 1 of \citeappendix{alliez19}, it shows the dependencies and their inter-dependencies for Matplotlib (a popular plotting module in Python).
+For example see Figure 1 of \cite{alliez19}, it shows the dependencies and their inter-dependencies for Matplotlib (a popular plotting module in Python).
 Acceptable version intervals between the dependencies will cause incompatibilities in a year or two, when a robust package manager is not used (see Appendix \ref{appendix:packagemanagement}).
 
 Since a domain scientist does not always have the resources/knowledge to modify the conflicting part(s), many are forced to create complex environments with different versions of Python and pass the data between them (for example just to use the work of a previous PhD student in the team).
@@ -1269,14 +1269,14 @@ Furthermore, in their proof-of-concept Dockerfile (listing 1), \inlinecode{rocke
 \subsection{Reproducible Electronic Documents, RED (1992)}
 \label{appendix:red}
 
-RED\footnote{\inlinecode{\url{http://sep.stanford.edu/doku.php?id=sep:research:reproducible}}} is the first attempt that we could find on doing reproducible research, see \citeappendix{claerbout1992,schwab2000}.
+RED\footnote{\inlinecode{\url{http://sep.stanford.edu/doku.php?id=sep:research:reproducible}}} is the first attempt that we could find on doing reproducible research, see \cite{claerbout1992,schwab2000}.
 It was developed within the Stanford Exploration Project (SEP) for Geophysics publications.
 Their introductions on the importance of reproducibility, resonate a lot with today's environment in computational sciences.
 In particular the heavy investment one has to make in order to re-do another scientist's work, even in the same team.
 RED also influenced other early reproducible works, for example \citeappendix{buckheit1995}.
 
 To orchestrate the various figures/results of a project, from 1990, they used ``Cake'' \citeappendix{somogyi87}, a dialect of Make, for more on Make, see Appendix \ref{appendix:jobmanagement}.
-As described in \citeappendix{schwab2000}, in the latter half of that decade, they moved to GNU Make, which was much more commonly used, developed and came with a complete and up-to-date manual.
+As described in \cite{schwab2000}, in the latter half of that decade, they moved to GNU Make, which was much more commonly used, developed and came with a complete and up-to-date manual.
 The basic idea behind RED's solution was to organize the analysis as independent steps, including the generation of plots, and organizing the steps through a Makefile.
 This enabled all the results to be re-executed with a single command.
 Several basic low-level Makefiles were included in the high-level/central Makefile.