# On the question of the analysis of
$J/\psi\rightarrow\rho\pi\rightarrow\pi^{+}\pi^{-}\pi^{0}$

K.Yu. Todyshev  1,2  1 Budker Institute of Nuclear Physics, 11, akademika
Lavrentieva prospect, Novosibirsk, 630090, Russia  2 Novosibirsk State
University, 1, Pirogova street, Novosibirsk, 630090, Russia

###### Abstract

This paper presents a method for the analysis of process
$J/\psi\rightarrow\rho\pi\rightarrow\pi^{+}\pi^{-}\pi^{0}$ based on the
consideration of the angles of expansion of finite pion pairs. The proposed
approach makes it possible to effectively carry out selection of events in
both neutral and charge-conjugate modes of the decay of
$J/\psi\rightarrow\rho\pi$. Application of the method for the analysis of
similar three-body decays in some cases will simplify the analysis and refine
current results.

###### keywords:

charmonium$J/\psi$ $\rho\pi$

##  1 Introduction

The interest in the issue of effective separation of the
$J/\psi\rightarrow\rho\pi$ decay modes arose from considering the experimental
results of the analysis of the $J/\psi$ decay into three pions. The main
contribution to this process is determined by the decay of
$J/\psi\rightarrow\rho\pi$ followed by the decay $\rho$ meson into two pions.
The probability of this process was measured in a number of experiments
MRK1:1976 ; CNTR:1976 ; DASP:1978 ; PLUT:1978 ; MRK2:1983 ; MRK3:1988 ;
BES:1996 ; BES:2004 ; BABAR:2004  and is the highest among $J/\psi$ decays
with an intermediate hadron resonance $\mathcal{B}_{\rho\pi}(J/\psi)=1.69\pm
0.15\%$ PDG:2022 . In addition, the ratio of partial widths
$\Gamma_{\rho^{0}\pi^{0}}/\Gamma_{\rho\pi}$ was measured in MRK1:1976 ;
CNTR:1976 ; DASP:1978 ; PLUT:1978 ; MRK3:1988 , whence, taking into account
the result of the latest experiment MRK3:1988 , the PDG PDG:2022  gives the
value $\mathcal{B}_{\rho^{0}\pi^{0}}(J/\psi)=(5.6\pm 0.7)\times 10^{-3}$. A
feature of the available experimental measurements of the
$\mathcal{B}_{\rho\pi}(J/\psi)$ value is a significant discrepancy between the
results of early experiments MRK1:1976 ; CNTR:1976 ; DASP:1978 ; PLUT:1978 ;
MRK2:1983 ; MRK3:1988 ; BES:1996  and later measurements by the collaborations
BES BES:2004  and BABAR BABAR:2004 . Resulting error scaling factor, according
to PDGPDG:2022  is 2.4. These reasons make it interesting to continue the
study both the $J/\psi\rightarrow\rho\pi$ process and the entire set of
$J/\psi$ decay processes leading to a three-pion final state.

The distribution of squared invariant masses of pion pairs $\pi^{+}\pi^{0}$,
$\pi^{-}\pi^{0}$, $\pi^{+}\pi^{-}$ is shown in three dimensions in the figure
1. Any of the three 2D projections of a 3D distribution is a Dalitz plot
Dalitz:1954 . Plots of this kind are widely used in the analysis of various
processes, including those for the three-pion $J/\psi$ meson decay. Complexity
of measuring the partial probabilities of modes
$J/\psi\rightarrow\rho^{+}\pi^{-}$, $J/\psi\rightarrow\rho^{-}\pi^{+}$,
$J/\psi\rightarrow\rho^{0}\pi^{0}$ in such an approach is associated with a
significant overlap of distributions of squared invariant masses of pions
pairs, as well as the need for a reliable description of the resolution
function for a two-dimensional distribution over invariant masses. The
inaccuracies of this function, as a rule, introduce a noticeable systematic
uncertainty into the result.

Figure 1: The distribution of events over the squares of the invariant masses
of pion pairs
$m^{2}_{\pi^{+}\pi^{0}},m^{2}_{\pi^{-}\pi^{0}},m^{2}_{\pi^{+}\pi^{-}}$
obtained by MC simulation of the process $J/\psi\rightarrow\rho\pi$. The
simulation was performed within the framework of the KEDR experiment software
KEDR:2013 . The red, blue and green regions correspond to the conditions that
select the $J/\psi$ decay modes $\rho^{+}\pi^{-}$, $\rho^{-}\pi^{+}$ and
$\rho^{0}\pi^{0}$, respectively, as described in the text of the article.

##  2 The main idea of analysis of the process $J/\psi\rightarrow\rho\pi$

As an alternative to the two-dimensional fitting of Dalitz plots, one can
propose the following analysis procedure. At the initial stage, three subsets
of events are selected in accordance with the following conditions:
$\cos{\theta_{\pi^{+}\pi^{0}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{+}\pi^{-}}}\wedge\cos{\theta_{\pi^{+}\pi^{0}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{-}\pi^{0}}}$,
$\cos{\theta_{\pi^{-}\pi^{0}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{+}\pi^{-}}}\wedge\cos{\theta_{\pi^{-}\pi^{0}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{+}\pi^{0}}}$,
and
$\cos{\theta_{\pi^{+}\pi^{-}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{-}\pi^{0}}}\wedge\cos{\theta_{\pi^{+}\pi^{-}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{+}\pi^{0}}}$.
Here and further, $\theta_{\pi^{+}\pi^{0}}$, $\theta_{\pi^{+}\pi^{-}}$ and
$\theta_{\pi^{-}\pi^{+}}$ are the angles between the momentum vectors of the
corresponding $\pi$ mesons.

Figure 2 shows the distribution of events over the values of the cosines of
the angles of expansion of pion pairs in a three-dimensional form. The
criteria listed above determine the boundaries of the regions of three subsets
of events, where one or another mode of the process under study predominates.

Figure 2: Simulation data of the process $J/\psi\rightarrow\rho\pi$. The
distribution of events over the cosines of the angles
$\cos{\theta_{\pi^{+}\pi^{0}}},\cos{\theta_{\pi^{-}\pi^{0}}},\cos{\theta_{\pi^{+}\pi^{-}}}$
is given. The red, blue, and green regions correspond to the conditions that
single out, respectively, the $J/\psi$ meson decay modes $\rho^{+}\pi^{-}$,
$\rho^{-}\pi^{+}$ and $\rho^{0}\pi^{0}$.

The next stage of the analysis consists in constructing the distributions of
the invariant mass of the positively and negatively charged $\rho$ meson
according to the first and the second subset of events, as well as the
distribution of the invariant mass $\rho^{0}$ meson over the events of the
third subset. The simultaneous fitting of the three resulting distributions
involves the calculation of all necessary parameters, as in the case of
fitting two-dimensional Dalitz plot. Let us discuss the advantages of the
proposed approach.

Consider the events corresponding to the selection conditions
$\cos{\theta_{\pi^{+}\pi^{-}}}<\cos{\theta_{\pi^{-}\pi^{0}}}\vee\cos{\theta_{\pi^{+}\pi^{-}}}<\cos{\theta_{\pi^{+}\pi^{0}}}$.
These criteria allow to reject most of the $J/\psi\rightarrow\rho^{0}\pi^{0}$
events, which makes it possible to single out the
$J/\psi\rightarrow\rho^{+}\pi^{-}$ and $J/\psi\rightarrow\rho^{-}\pi^{+}$
”conditional” in its purest form.

Figure 3 shows the distribution of the invariant mass for the $\pi^{-}\pi^{0}$
pair for events that meet the above criteria. The resulting histogram is
marked with a dotted line. The area with horizontal blue hatching meets the
condition $\cos{\theta_{\pi^{-}\pi^{0}}}\\!>\\!\cos{\theta_{\pi^{+}\pi^{0}}}$,
and the part shaded with vertical red lines is the inverse relation
$\cos{\theta_{\pi^{-}\pi^{0}}}\\!<\\!\cos{\theta_{\pi^{+}\pi^{0}}}$. The area
of the intersection of the distributions determined by this condition is
approximately $7.4\%$ of all events in the histogram.

Figure 3:  The invariant mass distribution of the pair $\pi^{-}$ and $\pi^{0}$
under the conditions
$\cos{\theta_{\pi^{+}\pi^{-}}}<\cos{\theta_{\pi^{-}\pi^{0}}}\vee\cos{\theta_{\pi^{+}\pi^{-}}}<\cos{\theta_{\pi^{+}\pi^{0}}}$.

Consider now the distribution of the cosine of the angle between the momentum
vectors of $\pi^{-}$ and $\pi^{0}$ under the same conditions in the figure 4.
The overlap area of the event subset for one-dimensional distributions in
magnitude $\cos{\theta_{\pi^{-}\pi^{0}}}$ in this case is $2.3\%$. The
resulting value characterizes the overlap of subsets of events
$J/\psi\rightarrow\rho^{+}\pi^{-}$ and $J/\psi\rightarrow\rho^{-}\pi^{+}$ on
the three-dimensional plot of the angles of expansion of $\pi$ meson pairs.

Figure 4:  Distributions of the cosine of the angle between $\pi^{-}$ and
$\pi^{0}$ under the conditions
$\cos{\theta_{\pi^{+}\pi^{-}}}<\cos{\theta_{\pi^{-}\pi^{0}}}\vee\cos{\theta_{\pi^{+}\pi^{-}}}<\cos{\theta_{\pi^{+}\pi^{0}}}$.

A similar parameter at the boundaries of the intersection of charged modes
with a subset of events neutral mode is around $2.5\%$. In all possible
variants of intersections, approximately a threefold advantage remains
compared to the values of overlapping distributions of invariant masses.

The event compaction effect of the “corners” area in figure 2 is a consequence
of a simple fact. The shell or boundary of the area occupied by the Dalitz
plot for a three-pion decay corresponds to ”collinear” events, when the
momenta of two particles are directed against the direction of motion of the
third particle. In this case, the events of each of the
$J/\psi\rightarrow\rho\pi$ decay modes are located in the region close to the
corresponding side of the triangle in the figure 1, and on the cosine plot of
the expansion angles of $\pi$ meson pairs in the corresponding part of the 3D
drawing in figure 2.

It is possible to find a relation between the observed angle of expansion of a
pair of charged pions and their invariant mass, in an approximation where pion
masses can be neglected. In this case,
$2E_{1}E_{2}(1-\cos{\theta_{12}})=m_{12}^{2}$, where $E_{1}$ and $E_{2}$ are
energies of the corresponding pions. Consider the $\pi^{-}\pi^{0}$ pair. Under
the condition
$\cos{\theta_{\pi^{-}\pi^{0}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{+}\pi^{-}}}\wedge\cos{\theta_{\pi^{-}\pi^{0}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{+}\pi^{0}}}$,
the observable value is $\cos{\theta_{\pi^{-}\pi^{0}}}>-0.5$ (Fig. 4), from
here one can determine that $m^{2}_{12}<3E_{1}E_{2}$. The maximum of the
product $E_{1}E_{2}$ is reached at
$E_{1}=E_{2}=\frac{s-m_{\pi}^{2}+m_{12}^{2}}{4\sqrt{s}}$, hence
$m^{2}_{12}<\frac{3s}{10}$, holding the next order of smallness in pion mass
leads to $m^{2}_{12}<\frac{8}{5}(\frac{3s}{16}+4m_{\pi}^{2})$. In numerical
form, this corresponds to the condition $m_{12}<1.73$ GeV$/c^{2}$ (for
$s=M_{J/\psi}^{2}$).

Using the above conditions on the cosines of the pion pair expansion angles,
it is possible to represent the entire set of events in the form of one-
dimensional distributions of invariant masses for pion pairs, which is
demonstrated in the figures 5, 6 and 7. The upper bound of each of the
distributions agrees well with the constraint found above.

Figure 5:  Distribution of the invariant mass of the pair $\pi^{-}\pi^{0}$
under the conditions
$\cos{\theta_{\pi^{-}\pi^{0}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{+}\pi^{-}}}\\!\wedge\\!\cos{\theta_{\pi^{-}\pi^{0}}}\\!>\\!\cos{\theta_{\pi^{+}\pi^{0}}}$.
Figure 6:  Distribution of the invariant mass of the pair $\pi^{+}\pi^{0}$
under the conditions
$\cos{\theta_{\pi^{+}\pi^{0}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{+}\pi^{-}}}\\!\wedge\\!\cos{\theta_{\pi^{+}\pi^{0}}}\\!>\\!\cos{\theta_{\pi^{-}\pi^{0}}}$.
Figure 7:  Distribution of the invariant mass of the pair $\pi^{+}\pi^{-}$
under the conditions
$\cos{\theta_{\pi^{+}\pi^{-}}}\\!\\!>\\!\\!\cos{\theta_{\pi^{-}\pi^{0}}}\wedge\cos{\theta_{\pi^{+}\pi^{-}}}\\!\\!>\cos{\theta_{\pi^{+}\pi^{0}}}$.
Figure 8:  Dependence of the sum of overlaps of subsets of distinguished
events $\varepsilon$ on the value $\delta$, which sets the shift to the value
$\cos{\theta_{\pi^{+}\pi^{-}}}$ under the conditions that determine the
boundaries of the regions of the $J/\psi$ decay modes under study.

Consider the problem of optimizing the mode factorization procedure for the
process $J/\psi\rightarrow\rho\pi$, that is, we determine the possible region
of each of the modes so that the sum of the overlaps of the subsets
$\varepsilon$ is minimal. Introduce the parameter $\delta$ and change
”$\cos{\theta_{\pi^{+}\pi^{-}}}$” to ”$\cos{\theta_{\pi^{+}\pi^{-}}}+\delta$”
in all conditions listed above. Positive values of $\delta$ correspond to an
increase in the region where the events of the
$J/\psi\rightarrow\rho^{0}\pi^{0}$ mode are distinguished, and negative values
correspond to its decrease. Figure 8 shows the resulting dependence.

The optimal value of $\delta$ is found to be equal to $-0.3$. At the same
time, the region of the minimum of the chosen optimization function is rather
wide, and its difference from the value at zero $\delta$ is insignificant.
Modification of the criteria on $\cos{\theta_{\pi^{+}\pi^{0}}}$ and
$\cos{\theta_{\pi^{-}\pi^{0}}}$ by introducing additional offsets is not
required due to the symmetry selection conditions for these parameters, which
is confirmed by numerical calculation.

The observed asymmetry of the optimal boundaries of the selected events is
associated with a lower efficiency of registration of the
$J/\psi\rightarrow\rho^{0}\pi^{0}$ process compared to charged modes. When
analyzing real experimental data, the optimal criteria for mode factorization
may not correspond exactly to the conditions described in this article due to
the features of the detector, the influence of background events, and the
interference of the decay under study with other processes. Nevertheless,
selection criteria for the angles of expansion of pion pairs of registered
$\pi$ mesons in the process $J/\psi\rightarrow\rho\pi$ significantly increase
the efficiency of separation of various modes of a given decay. Such criteria
are more efficient than restrictions on the squares of the invariant masses
and the invariant masses themselves for processes of this kind, if only one-
dimensional distributions are considered. Factorization of different
$J/\psi\rightarrow\rho\pi$ decay modes can be useful for a more accurate
measurement of the partial probability this process.

##  3 Conclusion

A number of critical remarks should be made. The problem of interference of
the main $\rho\pi$ channel with the $J/\psi\rightarrow\rho(1450)\pi$ decay and
other possible processes leading to the three-pion state is not considered
here, but the corresponding analysis of one-dimensional distributions of the
constructed invariant masses preserves information about interference. Such a
one-dimensional analysis is simpler than the description of the elements of a
two-dimensional distribution on the Dalitz plot, since a reliable description
of the resolution function in a multidimensional space is quite a difficult
task. The two-dimensional approach in describing the distribution of events
over invariant masses on the Dalitz plot carries more information, but the
proposed alternative is more efficient to measure the partial probability of
the process $J/\psi\rightarrow\rho\pi$. This is due to the fact that the main
part of the events of this process is concentrated in the ”corners” of the
three-dimensional distribution of the cosines of the expansion angles of $\pi$
meson pairs. Regions where one or another mode of the
$J/\psi\rightarrow\rho\pi$ process predominates can also be distinguished by
other conditions that include the main set of events of each considered mode.
However, this does not affect the nature of the distributions over the
invariant mass for pairs of pions, which will be characterized by a ”tail”
falling to the right. This, ultimately, provides the advantage of such an
analysis in finding the systematic uncertainties associated with the
interference with resonances lying above the $\rho$ meson.

The construction of Dalitz plots and selection criteria based on the
restriction of the squares of the invariant masses, or the invariant masses
themselves, are familiar tools of modern high-energy physics used to analyze
the processes leading to three particles in final state. At the same time, for
the analysis of such processes, plots and selection criteria based on the
values of the cosines of the expansion angles between the final particles can
be considered. Application of the method described above for determining the
probabilities of various $J/\psi\rightarrow\rho\pi$ decay modes will allow us
to check more accurately the conservation of isotopic invariance for the
process under consideration. The proposed method can be useful in the study of
the charge asymmetry in the decays $J/\psi\rightarrow\rho\pi$ and the so-
called $\rho-\pi$ puzzle MRK2:1983 , if we carry out a similar analysis of
various $\psi(2S)\rightarrow\rho\pi$ decay modes. Also, the described method
of analysis can be used in the study of the decays
$\Upsilon(1S),\Upsilon(2S)\rightarrow\pi^{+}\pi^{-}\pi^{0},\phi
K^{+}K^{-},\omega\pi^{+}\pi^{-},K^{*0}(892)K^{-}\pi^{+}$ and other processes
with similar kinematic features.

## Acknowledgments

The author is grateful to Andrey Shamov and Vladimir Blinov for their interest
to this work.

## References

  * [1] B. Jean-Marie et al., Phys. Rev. Lett. 36, 291 (1976).
  * [2] W. Bartel et al., Phys. Lett. B64, 483 (1976).
  * [3] R. Brandelik et al., Phys. Lett. B74, 292 (1978).
  * [4] G. Alexander et al., Phys. Lett. B72, 493 (1978).
  * [5] M.E.B. Franklin et al., Phys. Rev. Lett. 51, 963 (1983).
  * [6] D. Coffman et al., Phys. Rev. D 38, 2695 (1988).
  * [7] J.Z.Bai et al., Phys. Rev. D 54, 1221 (1996).
  * [8] J.Z.Bai et al., Phys. Rev. D 70, 012005 (2004).
  * [9] B. Aubert et al., Phys. Rev. D 70, 072004 (2004).
  * [10] R.L. Workman et al., _Prog. Theor. Exp. Phys._ (2020) 083C01.
  * [11] R. H. Dalitz, Phys. Rev. 94, 1046 (1954).
  * [12] V.V. Anashin et al., Physics of particles and nuclei 44, 657 (2013).


# An Introduction to Rocker:
Docker Containers for R

by Carl Boettiger, Dirk Eddelbuettel

###### Abstract

We describe the Rocker project, which provides a widely-used suite of Docker
images with customized R environments for particular tasks. We discuss how
this suite is organized, and how these tools can increase portability,
scaling, reproducibility, and convenience of R users and developers.

## Introduction

The Rocker project was launched in October 2014 as a collaboration between CB
& DE to provide high-quality Docker images containing the R environment
(Boettiger and Eddelbuettel, 2014). Since that time, the project has seen both
considerable uptake in the community and substantial development and
evolution. Here we seek to document the project’s objectives and uses.

### What is Docker?

Docker is a popular open-source tool to create, distribute, deploy, and run
software applications using _containers_. Containers provide a virtual
environment (see Clark et al. (2014) for an overview of common virtual
environments) requiring all operating-system components an application needs
to run: code, runtime, system tools, system runtime. Docker containers are
lightweight as they share the operating system kernel, starting instantly
using a layered filesystem which minimizes disk footprint and download time,
are built on open standards that run on all major platforms (Linux, Mac,
Windows), and provide an added layer of security by running an application in
an isolated environment (Docker, 2015). Familiarity with a few key terms is
helpful in understanding this paper. The term “container” refers to an
isolated software environment on a computer. R users can think of running a
container as analogous to loading an R package; it makes a set of software
functions available. A Docker “image” is a binary archive of that software,
analogous to an R binary package: a given version is downloaded only once, and
can then be “run” to create a container whenever it is needed. A “Dockerfile”
is a recipe, the source-code, to create a Docker image. Development and
contributions to the Rocker project focuses on the construction, organization
and maintenance of these Dockerfiles.

## Design principles & use cases

Docker gives users very convenient access to pre-configured and pre-built
_binary_ images that “just work”. This allows R users to access a wider-
variety of ready-to-use environments than provided by either the R Project
itself or, say, their distribution which will generally focus on one (current)
release. For example, R users on Windows may run RStudio Server or Shiny
Server locally just by launching a single command (once Docker itself is
installed). Another common use-case is access to R-devel without affecting the
local system. Here, we detail some of the principle use cases motivating these
containerized versions of R environments, and the design principles that help
make them work.

### Portability: From laptop to cloud

One common use case for Rocker containers is to provide a fast and reliable
mechanism to deploy a custom R environment to a remote server, such as Amazon
Web Services Elastic Compute (AWS EC2), DigitalOcean, NSF’s Jetstream servers
(Stewart et al., 2015), or private or institutional server hardware. Rocker
containers are also easy to run locally on most modern laptops by first
installing the appropriate Docker command (or distribution) for Windows,
MacOS, and Linux-based operating systems. By sharing volumes with the local
host, users can still manipulate files with familiar, native tools while
performing computation through a reproducible, containerized environment
(Boettiger, 2015). Being able to test code in a predictable, pre-configured R
environment on a local machine and to then run the same code in an identical
environment on a remote server (_e.g._ , for access to greater RAM, more
processors, or merely to free up the local machine from a long-running
computation) is essential for low-friction scaling of analysis. Without such
containerization, getting code to run appropriately in a remote environment
can be a major undertaking, requiring both time and knowledge many would-be
users may not have.

For instance, the following bash commands install Docker on almost any Linux-
based server and then launch a Rocker container providing the RStudio-server
environment over a web interface.

    wget -qO- https://get.docker.com/ | sh
    sudo docker run -p 8787:8787 -e PASSWORD=<PICK-A-PASSWORD> rocker/rstudio

The docker run option -p sets the port on which RStudio will appear, 8787 is
the RStudio default (adding your user to the docker group to avoids the need
for a sudo command to call docker: sudo usermod -g docker $USER). Many
academic and commercial cloud providers make it possible to execute such code
snippets when a container is launched, without ever needing to ssh into the
machine. The user may log into the server merely by pasting its IP address or
DNS name (followed by the chosen port, _e.g._ , :8787) into a browser and
entering the appropriate password. This provides the user with a familiar,
interactive environment running on a remote machine while requiring a minimum
of expertise.

Deploying Docker containers on centrally administrated multi-user machines,
such as department or university clusters, has previously been more difficult,
since system adminstrators do not want to allow the elevated user permissions
the Docker runtime environment requires. To work around this problem, Lawrence
Berkeley National Labs (LBNL) has made ‘Singularity’ (LBNL, 2017): a container
runtime environment that users can both install and use to run most Docker
containers without requiring root privileges, making it easier to deploy
Rocker containers in this context as well.

This portability is also valuable in an instructional context. Requiring
students to install all necessary software on personal laptops can be
particularly challenging for short workshops, where download and installation
time and troubleshooting across heterogeneous machines can prove time
consuming and frustrating for students and instructors alike. By deploying a
Rocker image or Rocker-derived image (see _Extensibility_) on a cloud machine,
an instructor can easily provide all students access to the pre-configured
software environment using only the browser on their laptops. This strategy
has proven effective in our own experience in both workshops and semester-
length courses. Similar Docker-based cloud deployments have been scaled to
courses of 100s of students, _e.g._ , at Duke (Cetinkaya-Rundel and Rundel,
2017) and UC Berkeley (UC Berkeley, 2017).

### Interfaces

An important aspect of the Rocker project design is the ability for users to
interact with the software on the container through either an interactive
shell session (such as the R shell or a bash shell), or through a web browser
accessing the RStudio® Server integrated development environment (IDE).
Traditional remote and high-performance computing workflows for R users have
usually required the use of ssh and a terminal-only interface, posing a
challenge for interactive graphics and a barrier to users unfamiliar with
these tools and environments. Accessing an RStudio® container through the
browser removes these barriers. Rocker images include the RStudio-server
software pre-installed and configured with the explicit permission of RStudio®
Inc.

Users can access a root bash shell in a running Rocker container using

    docker exec -ti <container-id> bash

which can be useful for administrative tasks such as installing system
dependencies. All Rocker images can also be run as an interactive R, RScript
or bash shell without running RStudio, which can be useful for batch jobs or
for anyone who prefers that environment.

As with any interactive Docker container, users should specify the interactive
(-i) and terminal (-t, here combined with interactive as -ti) flags, and
specify the desired executable environment (_e.g._ , R, though other common
options may be Rscript or bash):

    docker run --rm -ti rocker/tidyverse R

This example shows the use of the \--rm flag to indicate that the container
should be removed when the interactive session is finished. Details on sharing
volumes, managing user permissions, and more can be found on the Rocker
website, https://rocker-project.org.

### Sandboxed

Another feature of Rocker containers is the ability to provide a sandboxed
environment, isolated from software and potentially from other data on the
machine. Many users are reluctant to upgrade their suite of installed
packages, which may break their existing code or even their R environment if
the installation goes poorly. However, upgrading packages and/or the R
environment is often necessary to run analysis of a colleague, or access more
recent methods. Rocker offers an easy solution. For instance, a user can run R
code requiring the most recent versions of R and related packages inside a
Rocker container without having to upgrade their local installations first.
Conversely, one could use Rocker to run code on an older R release with prior
versions of R packages, again without having to make any alteration to one’s
local R install. Another common use case is to access a container with support
for particular options such as using gcc or clang compiler sanitizers
(Eddelbuettel, 2014). These requires R itself be built with specialized
settings that may not be not available or familiar to many R users on their
native system, but can be easily deployed by pulling the Rocker images
rocker/r-devel-san or rocker/r-devel-ubsan-clang.

This sandboxing feature is also valuable in the remote computing context,
allowing system administrators to grant users freedom to install software
which requires root privileges inside a container, while not granting them
root access on the host machine. Root access is required to launch Docker
containers, though not to access containers already running and providing some
service such as RStudio. Users logging into a container through the RStudio®
interface do not by default have root privileges, though are able to install R
packages. Granting these users root privileges in the container still leaves
them sandboxed from the host container. Further, Docker images can be deployed
from a machine without root privileges through the alternate container runtime
environment, Singularity (LBNL, 2017). Unlike traditional virtual machines,
these containers do not impose a large footprint of reserved resources as a
typical host can easily support 100s of containers (Docker, 2015).

### Transparent

Users can easily determine the software stack installed on any Rocker image by
examining the associated Dockerfile recipe, which provides a concise, human-
readable record of the installation. All Rocker images use automated builds
through Docker Hub, which also acts as the central, default repository
distributing the images. Using automated builds rather than uploading pre-
built image binaries to the Docker Hub avoids the potential for the build not
to match the recipe. The corresponding Dockerfile is visible both on the
Docker Hub and in the linked GitHub repository of the Rocker project
(https://github.com/rocker-org), which provides a transparent versioned
history of all changes made to these recipes, as well as documentation, a
community wiki, and issue trackers for discussing proposed changes, bugs,
improvements to the Dockerfiles and troubleshoot any issues users may
encounter. Having these public source files built automatically by a trusted
provider (Docker Hub), rather than built locally and uploaded only in binary
form provides is also useful from a security perspective in avoiding malware.

### Community Optimized

Having a shared, transparent computational environment created by a publicly
hosted, reproducible recipe facilitates community input into configuration
details. R and many of its packages and related software can be configured
with a wide range of options, compilers, different linear-algebra libraries
and so forth. While this flexibility reflects varying needs, many users rely
on default settings which may be optimized more for simplicity of installation
than performance. The Rocker recipes reflect significant community input on
these choices, as well as the considerable experience and expertise of the R
Debian maintainer of 20 years in what configuration options to use. This helps
create a more finely tuned, optimized reference implementation of the R
environment as well as a platform for comparing and discussing these concerns
which are often overlooked elsewhere. Issues and Pull Requests on the Rocker
repositories on GitHub attest to these discussions and improvements.
Widespread use of the Rocker image helps promote both testing of these choices
and contributions further tweaking the configuration from many members of the
R community.

### Versioned

Access to specific versions of software can be important for users who need
computational reproducibility more than having the latest release of any piece
of software, since subsequent releases can alter the behavior of code,
introduce errors or otherwise alter previous results. The versioned stack
(r-ver, rstudio, tidyverse, verse, and geospatial) provides images which are
intended to build an identical software stack every time, regardless of the
release of new libraries and packages. Users should specify an R version tag
in the Docker image name to request a version stable image, _e.g._ ,
rocker/verse:3.4.0. If no tag is explicitly requested, Docker will provide the
image with the tag :latest, which will always have the latest available
versions of the software (built nightly).

Users building on the version-tagged images will by default use the MRAN
snapshot mirror (Revolution Analytics, 2017) associated with the most recent
date for which that image was current. This ensures that a Dockerfile building
FROM rocker/verse:3.4.1 will only install R package versions that were
available on CRAN on 2017-06-30, that is, the day R 3.4.1 was released. This
default can of course be overwritten in the standard R manner, _e.g._ , by
specifying a different CRAN mirror explicitly in any command to
install.packages(), or by adjusting the default CRAN mirror in
options(repo=<CRAN-MIRROR>) in an .Rprofile. Note that the MRAN date
associated with the current release (_e.g._ , 3.4.2 at the time of writing)
will continue to advance on the Docker-hub image until the next R release.
Software installed from apt-get in these images will come from the the stable
Debian release (stretch or jessie) and thus not change versions (though it
will receive security patches). Packages installed from BioConductor using the
bioclite() utility will also install the version appropriate to the version of
R found on the system (the Bioconductor semi-annual release model avoids the
need for an MRAN mirror). Users installing packages from GitHub or other
sources can request a specific git release tag or hash for a more reproducible
build, or adopt an alternative approach such as packrat (Ushey et al., 2016).
A more general discussion of the use and limitations of Docker for
computational reproducibility can be found in Boettiger (2015).

### Extensible

Any portable computational environment faces an inevitable tension between the
“kitchen sink problem” at one extreme, and the “discovery problem” on the
other. A kitchen sink image seeks to accommodate too many use cases in a
single image. Such images are inevitably very large and thus slow or difficult
to deploy, maintain and optimize. At the other extreme, providing too many
specialized images makes it more difficult for a user to discover the one they
need. The Rocker project seeks to avoid both of these problems by providing a
carefully-curated suite of images that an be easily extended by individuals
and communities.

To make extensions transparent and persistent, Rocker images can be extended
by any user by writing their own Dockerfiles based on an appropriate Rocker
image. The Dockerfiles in the Rocker stack should themselves provide a simple
of example of this. A user begins by selecting an appropriate base image for
their needs: if the RStudio® interface is desired, a user might start with
FROM rocker/rstudio; an image for testing a particular C code in an R package
might use FROM rocker/r-devel-san, an image for reproducing a data analysis
will probably select a stable version tag in addition to an appropriate base
library, _e.g._ ,: FROM rocker/tidyverse:3.4.1 Users can easily add additional
software to any running Rocker image using the standard R and Debian
mechanisms. Details on how to extend Rocker images can be found at
https://rocker-project.org.

Sharing these Dockerfiles can also facilitate the emergence of extensions
tuned to particular communities. For instance, the rocker/geospatial image
emerged from the input of a number of Rocker users all adding common
geospatial libraries and packages on top of the existing Rocker images. This
coalescence helped create a more fine-tuned image with broad support for a
wide range of commonly-used data formats and libraries. Other community images
are developed and maintained independently of the Rocker project, such as the
popgen image of population-genetics-oriented software developed by the
National Evolutionary Synthesis Center (NESCent). Rocker images are also being
used as base Docker images in the NSF sponsored Whole Tale project for
reproducible computing (Ludaescher et al., 2017), and are heavily used by the
R-Hub project in automated package testing (Csárdi, 2017).

## Rocker organization and workflow

The Rocker project consists of a suite of images built automatically by and
hosted on the Docker Hub, https://hub.docker.com/r/rocker. Source Dockerfiles,
supporting scripts and documentation are hosted on GitHub under the
organization rocker-org, https://github.com/rocker-org. The issue tracker and
pull requests are used for community input, discussions and contributions to
these images. The Rocker project wiki provides a place to synthesize
community-contributed documentation, use-cases, and other knowledge about
using the Rocker images.

### Images in the Rocker Project

The Rocker project aims to provide a small core of Docker images that serve as
convenient ‘base’ images on which other users can build custom R environments
by writing their own Dockerfiles, while also providing a ‘batteries included’
approach of images that can be used out of the box. The challenges of
balancing diverse needs driven by very different use cases against the
overarching goals of creating images that are still sufficiently light-weight,
easy to use and easy to maintain is a difficult art. The implementation in
both individual Rocker images and image stacks can never perfect that balance
for everyone, but today reflects the considerable community input and testing
over the past few years.

All Rocker images are based on the Debian Linux distribution. The Debian
platform provides a small base image, the well-known apt package management
system and rich ecosystem of software libraries, making it the base image of
choice for Docker images, including many of the “official” images maintained
by Docker’s own development team. The Debian platform is also perhaps the
best-supported Linux platform within the R community, including an active
r-sig-debian listserve. The relatively long period between stable Debian
releases (roughly two years recently) means that software in the Debian stable
(_e.g._ , debian:jessie, debian:stretch) releases can lag significantly behind
current releases of popular software, including R. More recent versions of
packages can be found in the pre-release distribution, debian:testing, while
the very latest binary builds can be found on debian:unstable. The Rocker
project can be largely divided into two stacks which address different needs,
reflected in which Debian distribution they are based on. The first stack is
based on debian:testing. The second, more recently-introduced stack, is based
only on Debian stable releases. Rocker images always point to specific stable
releases (jessie, stretch), and do not use the tag debian:stable, which is a
rolling tag that always points to the most recent stable version. The
different Rocker stacks have different aims and thus provide different images,
as shown in Tables 1 & 2 below.

### The debian:testing-based images

The debian:testing stack aims to make the most efficient use of upstream
builds: the pre-compiled .deb binaries provided by the Debian repositories. It
is both quicker and easier to install software from binaries, since the
package manager (apt) manages the necessary (binary) dependencies and bypasses
the time-consuming process of compiling from source. Basing this stack on
debian:testing means that much more recent versions of commonly-used libraries
and compilers are available as binaries than would be found in a Debian stable
release. In order to provide access to the most recent available binaries,
this stack uses apt-pinning (Debian Project, 2017) to allow the apt package
manager to also install binaries from debian:unstable, which represents the
most recent, bleeding edge of packages built for Debian when necessary. For
instance, the r-base image provided by Rocker installs the most recent version
of R as a binary from Debian unstable. Similarly, recent versions of many
popular R packages can also be installed through the package manager, _e.g._ ,
apt-get install r-cran-xml. This can be particularly helpful for packages with
external system dependencies (such as libxml2-dev in this example) which
cannot be installed from the R console as they are system dependencies rather
than R packages installed from within R. We should note, however, that only
about 500 of the over 11,000 CRAN packages are available as Debian packages.

As the names testing and unstable imply, this approach is not without
challenges. The particular version of any given package can change as packages
move from unstable into testing. New versions are sent to unstable during the
normal course of Debian development. This can occasionally break an
previously-working installation command in a Dockerfile until the maintainer
redirects the package manager to install a package from the unstable sources
that could previously be installed from testing, or vice versa (using the -t
option in apt). That said, packages only migrate from unstable to testing
after a period of several days—and if the migration and installation of the
particular version is free of interactions with other packages in their
dependency graph. That way, unstable serves as validation lab which leaves
testing reasonably stable yet current.

Relative to stable, the testing stack thus offers the following advantages:

  1. 1.

These Dockerfiles are easy to develop and extend because almost all software
can be installed through the package manager.

  2. 2.

These Dockerfiles always install the most recent available software.

  3. 3.

These Dockerfiles can almost always build relatively quickly.

and these down-sides:

  1. 1.

These Dockerfiles require occasional minor maintenance to ensure successful
builds. (_e.g._ , changing an installation directive from unstable to testing
or vice versa).

  2. 2.

The resulting images are inherently dynamic: rebuilding the same Dockerfile
months or years apart will generate images with significantly different
versions of software installed.

  3. 3.

The use of apt pinning may be unfamiliar to some users, where the user must
ultimately be responsible to ensure compatibility (Debian Project, 2017).

### Images overview

The debian:testing-based stack currently includes seven images actively
maintained by the Rocker development team (Table 1). r-base builds on
debian:testing, and the other six in the stack each build directly from
r-base. The r-base image is unique in that it is designated as the official
image for the R language by the Docker organization itself. This official
image is reviewed and then built by employees of Docker Inc based on a
Dockerfile maintained by the Rocker team. Consequently, users should refer to
this image in Docker commands without an organization namespace, _e.g._ ,
docker run -t r-base to access the official image. All other images in the
Rocker project are not individually reviewed and built by Docker Inc and must
be referenced using the rocker namespace, _e.g._ , docker run -ti
rocker/r-devel.

Several of the images in this stack are oriented towards the R development
community: r-devel, drd, r-devel-san & r-devel-ubsan-clang all add a copy of
the development version of R side-by-side the current release of R provided by
r-base. On these images, the development version is aliased to RD to
distinguish from the current release, R. As the names suggest, each provide
slightly different configurations. Of particular interest are the images
providing development R built with support for C/C++ address and undefined-
behavior sanitizers, which are somewhat more difficult to configure
(Eddelbuettel, 2014).

As these images focus on developers and/or as base images for custom uses,
this stack does not include many specific R packages. Additional dependencies
and packages can easily be installed from apt. R packages not available in the
apt repositories can be installed directly from CRAN using either R or the
littler scripts, as described in https://rocker-project.org/use.

This stack also includes the images shiny and rstudio:testing that provide
Shiny server and RStudio® server IDE from RStudio® Inc, built on the r-base
image. RStudio® and Shiny are registered trademarks of RStudio Inc, and their
use and the distribution of their software in binary form on Docker Hub has
been granted to the Rocker project by explicit permission from RStudio. Users
should review RStudio’s trademark use policy
(http://www.rstudio.com/about/trademark/) and address inquiries about further
distribution or other questions to<EMAIL_ADDRESS>The Rocker project
also provides images with RStudio® server and Shiny server in the stable
versioned stack.

Build schedule: The official r-base image is rebuilt by Docker following any
updates to the official debian images (roughly every few weeks). The rest of
the stack uses build triggers that rebuild the images either whenever r-base
is updated, or the Dockerfile sources are updated on the corresponding GitHub
repository. The only exception in this stack is the drd image, which is
rebuilt each week by a cron trigger.

Table 1: The debian:testing image stack image |  description |  size |  downloads
---|---|---|---
r-base |  official image with current version of R |  254 MB |  632,000
r-devel |  R-devel added side-by-side r-base (using alias RD) |  1 GB |  4,000
drd |  lightweight r-devel, built weekly |  571 MB |  4,000
r-devel-san |  as r-devel, but built with compiler sanitizers |  1.1 GB |  1,000
r-devel-ubsan-clang |  Sanitizers, clang c compiler (instead of gcc) |  1.1 GB |  525
rstudio:testing |  rstudio on debian:testing |  1.1 GB |  1,000
shiny |  shiny-server on r-base |  409 MB |  123,000
Table 2: The rocker-versioned stack of images image | description | size | downloads
---|---|---|---
r-ver | Version-stable base R & src build tools | 219 MB | 6,000
rstudio | Adds rstudio | 334 MB | 314,000
tidyverse | Adds tidyverse & devtools | 656 MB | 83,000 111This figure includes 49,000 downloads under the earlier name hadleyverse.
verse | Adds java, tex & publishing-related packages | 947 MB | 9,000
geospatial | Adds geospatial libraries | 1.3 GB | 4,000

### The debian:stable-based stack

This stack emphasizes stability and reproducibility of the Docker build. This
stack was introduced much more recently (November 2016) in response to
considerable user input and requests. The key feature of this stack is the
ability to run older versions of R along with the then-contemporaneous
versions of R packages. A user specifies the version desired using an image
tag, _e.g._ , rocker/r-ver:3.3.1 will refer to an image with R version 3.3.1
installed. Omitting the tag is equivalent to using the tag latest, which, as
the name implies, will always point to an image using the current R release.
Thus, users wanting to create downstream Dockerfiles which are based on the
current release at time (but will continue to reconstruct the same environment
in the future after newer R versions are released) should explicitly include
the corresponding version tag, _e.g._ , rocker/r-ver:3.4.2 at the time of
writing, and not the latest tag. Users can also run the current development
version of R using the tag devel, which is built nightly from R-devel sources
from subversion.

MRAN archives: To facilitate installation of only contemporaneous versions of
R packages on these images, the default CRAN mirror from which to install R
packages is fixed to a snapshot of CRAN corresponding to the last date for
which that version of R was the latest release. These snapshots are provided
by the MRAN archive created by Revolution Analytics (now part of Microsoft).
It archives daily snapshots of all of CRAN from which a user can install
packages with the usual install.packages() function (Revolution Analytics,
2017). Users can always override this default by passing any current CRAN
repository explicitly. Unlike CRAN, Bioconductor only updates its repositories
through bi-annual releases aligned to R’s spring release schedule. Thus,
Bioconductor packages can be installed in the usual way using bioclite, which
automatically selects the Bioconductor release corresponding to the version of
R in use.

Version tags: The version tags are propagated throughout this stack: _e.g._ ,
rocker/tidyverse:devel will provide the currently-released versions of the R
packages in the tidyverse (Wickham, 2017) installed on the nightly build of
R-devel. Developers building packages on this stack are encouraged to tag
their images accordingly as well. Table 3 indicates which versions of R are
currently available in the stack, going back to 3.1.0. While older versions
may be added to the stack at a later date, we note that the MRAN snapshots
began in 2014-09-17 and thus go back only to the R 3.1 era. Each tag must be
built from a separate Dockerfile, enabling minor differences in the build
instructions to accommodate changing dependencies. Dockerfiles for past
versions (_e.g._ , prior to 3.4.2 currently) are intended to remain static
over the long term, while the tag for the current version, latest, and devel
may be tweaked to accommodate new features or dependencies. Version tags also
obey semantics so that omitting the second or third position of the tag is
identical to asking for the most recent version: i.e. rocker/verse:3.3 is the
same as rocker/verse:3.3.3, and rocker/verse:3 is (at the time of writing),
rocker/verse:3.4.2. This is accomplished using post-build hooks in Docker Hub,
see examples at https://github.com/rocker-org/rocker-versioned/ for details.

Installation: In this stack, the desired version of R is always built directly
from source rather than the apt repositories. Compilers and dependencies are
still installed from the stable apt repositories, and thus lag behind the more
recent versions found in the testing stack. Version tags 3.3.3 and older are
based on the Debian 8.0 release, code-named jessie, while 3.4.0 \- 3.4.2,
devel, and latest are based on Debian 9.0, stretch, (released 2017-06-17,
while R was at 3.4.0), and thus have access to much newer versions of common
system dependencies and compilers. Dependencies needed to compile R that are
not required at runtime are removed once R is installed, keeping the base
images light-weight for faster download times. While most system dependencies
required by common R packages can still be installed from the apt
repositories, occasionally a more recent version must be compiled from source
(_e.g._ , the Gibbs Sampling program JAGS (Plummer, 2017), and the geospatial
toolkit GDAL, must both be compiled from source on debian:jessie images). In
this stack, users should avoid installing R packages using apt without careful
consideration as this will install a second (probably different) version of R
from the Debian repositories, and a dated version of the R package since any
r-cran-pkgname package in the Debian repositories will depend on r-base in apt
as well.

Build schedule: All images are built automatically from their corresponding
Dockerfiles (found in the GitHub repositories rocker-org/rocker-versioned and
rocker-org/geospatial). A cron job sends nightly build triggers to Docker Hub
to rebuild the latest and devel tagged images throughout the stack. To
decrease load on the hub, build triggers for the numeric version tags are sent
monthly. Although the Dockerfiles for older R versions installs an almost-
identical software environment every time, the monthly rebuilding of these
images on Docker Hub ensures they continue to receive Debian security updates
from upstream, and proves the build recipe still executes successfully. Note
that rebuilding images with software from external repositories never produces
a bit-wise identical image, and thus the image identifier hash will change at
each build.

### Images overview

In this stack, each image builds on the previous image, rather than all other
images building directly on the base image, as in the testing stack. Table 2
lists the names and descriptions of the five images in this stack, along with
image size and approximate download counts from Docker Hub. Sizes reflect
(compressed) cumulative size: a user who has already downloaded the most
recent version of r-ver and then pulls a copy of rstudio image will only need
to download the additional 115 MB in the rstudio layers and not the full 334
MB listed. This linear design limits flexibility (no option for tidyverse
without rstudio) but simplifies use and maintenance. While no single
environment will be optimal for everyone, both the packages selected in this
stack and the stack ordering reflect considerable community input and tuning.

The rstudio image includes a lightweight, easy-to-use and docker-friendly init
system, s6 (Bercot, 2017) for running persistent services, including the
RStudio® server. This system provides a convenient way for downstream
Dockerfile developers to add additional persistent services (such as an ssh
server) to a single container, or additional start-up or shutdown scripts that
should be run when a container starts up or shuts down. The rstudio image uses
such a start-up script to configure user settings such as login password and
permissions through environmental variables at run time.

The tidyverse image contains all required and suggested dependencies of the
commonly-used tidyverse and devtools R packages, including external database
libraries (_e.g._ , MariaDB and PostgreSQL). Users should consult the package
Dockerfiles or installed.packages() list directly for a complete list of
installed packages. The verse library adds commonly-used dependencies, notably
a large but not comprehensive LaTeX environment and Java development
libraries. Previously, the Rocker project provided the image hadleyverse which
was since divided into tidyverse and verse through community input.

Table 3: Available tags in the rocker-versioned stack. tag |  apt repos |  MRAN date |  Build frequency |  images with tag
---|---|---|---|---
devel |  stretch |  current date |  nightly |  r-ver, rstudio, tidyverse, verse, geospatial
latest |  stretch |  current date |  nightly |  r-ver, rstudio, tidyverse, verse, geospatial
3.4.2 |  stretch |  current date |  monthly |  r-ver, rstudio, tidyverse, verse, geospatial
3.4.1 |  stretch |  2017-09-28 |  monthly |  r-ver, rstudio, tidyverse, verse, geospatial
3.4.0 |  stretch |  2017-06-30 |  monthly |  r-ver, rstudio, tidyverse, verse, geospatial
3.3.3 |  jessie |  2017-04-21 |  monthly |  r-ver, rstudio, tidyverse, verse, geospatial
3.3.2 |  jessie |  2017-03-06 |  monthly |  r-ver, rstudio, tidyverse, verse, geospatial
3.3.1 |  jessie |  2016-10-31 |  monthly |  r-ver, rstudio, tidyverse, verse, geospatial
3.3.0 |  jessie |  2016-06-21 |  monthly |  r-ver
3.2.0 |  jessie |  2015-06-18 |  monthly |  r-ver
3.1.0 |  jessie |  2014-09-17 |  monthly |  r-ver

Several images in the rocker-versioned stack can be customized on build when
built locally (rather than pulling prebuilt images from Docker Hub) by using
the \--build-arg option of docker build. In the r-ver image, users can set
R_VERSION and BUILD_DATE (MRAN default snapshot). In the rstudio image users
can set RSTUDIO_VERSION (otherwise defaults to the most recent version), and
the PANDOC_TEMPLATES_VERSION .

This stack also makes use of Docker metadata labels defined by http://schema-
label.org, indicating image license (GPL-2.0), vcs-url (GitHub repository),
and vendor (Rocker Project). These metadata can be altered or extended in
downstream images.

## Conclusions

Over the past several years, Docker has seen immense adoption across industry
and academia. The Open Container initiative (The Linux Foundation: Projects,
2017) now provides an open standard that has further extended this container
approach to research environments through projects such as Singularity (LBNL,
2017), allowing users to deploy containerized environments such as Rocker on
machines where they do not have root access, such as clusters or private
servers. Containerization promises to solve numerous challenges such as
portability and replicability in research computing, which often relies on
complex and heterogeneous software stacks (Boettiger, 2015). Yet implementing
such environments in containers is not a trivial task, and not all
implementations provide the same usability, portability or reproducibility.
Here we have detailed the approach taken by the Rocker project in creating and
maintaining these environments through an open and community-driven process.
This structure of the Rocker project has evolved over three years of operation
while drawing in an ever-widening base of academic researchers, university
instructors and industry users. We believe this overview will be instructive
not only to users and developers interested in the Rocker project, but as a
model for similar efforts around other environments or domains.

## References

  * Bercot (2017) L. Bercot.  _s6: skarnet.org’s small and secure supervision software suite_ , 2017\.  URL https://skarnet.org/software/s6/.
  * Boettiger (2015) C. Boettiger.  An introduction to Docker for reproducible research, with examples from the R environment.  _ACM SIGOPS Operating Systems Review_ , 49(1):71–79, 2015.  doi: 10.1145/2723872.2723882.  URL https://dl.acm.org/citation.cfm?id=2723882http://arxiv.org/abs/1410.0846.
  * Boettiger and Eddelbuettel (2014) C. Boettiger and D. Eddelbuettel.  Introducing Rocker: Docker for R, 2014.  URL https://ropensci.org/blog/blog/2014/10/23/introducing-rocker.
  * Cetinkaya-Rundel and Rundel (2017) M. Cetinkaya-Rundel and C. W. Rundel.  Infrastructure and tools for teaching computing throughout the statistical curriculum.  _PeerJ Preprints_ , 5:e3181v1, Aug. 2017.  ISSN 2167-9843.  doi: 10.7287/peerj.preprints.3181v1.  URL https://doi.org/10.7287/peerj.preprints.3181v1.
  * Clark et al. (2014) D. Clark, A. Culich, B. Hamlin, and R. Lovett.  BCE: Berkeley’s Common Scientific Compute Environment for Research and Education.  _Proceedings of the 13th Python in Science Conference (SciPy 2014)_ , pages 1–8, 2014.
  * Csárdi (2017) G. Csárdi.  _rhub: Connect to ’R-hub’, from ’R’_ , 2017.  URL https://github.com/r-hub/rhub.  R package version 1.0.1.
  * Debian Project (2017) Debian Project.  Apt-preferences overview, 2017.  URL https://wiki.debian.org/AptPreferences.
  * Docker (2015) Docker.  What is Docker?, 2015.  URL https://www.docker.com/what-docker.
  * Eddelbuettel (2014) D. Eddelbuettel.  sanitizers, 2014.  URL http://dirk.eddelbuettel.com/code/sanitizers.html.
  * LBNL (2017) Lawrence Berkeley National Laboratories.  Singularity, 2017.  URL http://singularity.lbl.gov/.
  * Ludaescher et al. (2017) B. Ludaescher, K. Chard, M. Turk, V. Stodden, and N. Gaffney.  The Whole Tale: Merging science and cyberinfrastructure pathways, 2017\.  URL https://wholetale.org/.
  * Plummer (2017) M. Plummer.  JAGS: A program for analysis of Bayesian graphical models using Gibbs sampling, 2017.  URL http://mcmc-jags.sourceforge.net/.  Version 4.3.0.
  * Revolution Analytics (2017) Revolution Analytics.  Microsoft R Application Network, 2017.  URL https://mran.microsoft.com.
  * Stewart et al. (2015) C. A. Stewart, G. Turner, M. Vaughn, N. I. Gaffney, T. M. Cockerill, I. Foster, D. Hancock, N. Merchant, E. Skidmore, D. Stanzione, J. Taylor, and S. Tuecke.  Jetstream: A self-provisioned, scalable science and engineering cloud environment.  In _Proceedings of the 2015 XSEDE Conference on Scientific Advancements Enabled by Enhanced Cyberinfrastructure - XSEDE ’15_ , pages 1–8, New York, New York, USA, 2015. ACM Press.  ISBN 9781450337205.  doi: 10.1145/2792745.2792774.  URL http://dl.acm.org/citation.cfm?doid=2792745.2792774.
  * The Linux Foundation: Projects (2017) The Linux Foundation: Projects.  The Open Container Initiative, 2017.  URL https://www.opencontainers.org/.
  * UC Berkeley (2017) UC Berkeley.  Curriculum Overview | Division of Data Sciences, 2017.  URL http://data.berkeley.edu/education/curriculum-overview.
  * Ushey et al. (2016) K. Ushey, J. McPherson, J. Cheng, A. Atkins, and J. Allaire.  _packrat: A Dependency Management System for Projects and their R Package Dependencies_ , 2016.  URL https://CRAN.R-project.org/package=packrat.  R package version 0.4.8-1.
  * Wickham (2017) H. Wickham.  _tidyverse: Easily Install and Load ’Tidyverse’ Packages_ , 2017.  URL https://CRAN.R-project.org/package=tidyverse.  R package version 1.1.1.

_Carl Boettiger
UC Berkeley
ESPM Department, University of California,
130 Mulford Hall Berkeley, CA 94720-3114, USA
_<EMAIL_ADDRESS>
_Dirk Eddelbuettel
Debian and R Projects; Ketchum Trading
Chicago, IL, USA
_<EMAIL_ADDRESS>