Arvados

{{>toc}}

h1. Port a Pipeline

Like any other tool, Arvados requires time to learn. Thus, we don't encourage using Arvados for initial development of analysis pipelines or exploratory research on small subsets of data, when each quick-and-dirty iteration takes minutes on a single machine. But for any computationally-intense work, Arvados offers a lot of benefits.

Okay, cool, provenance, reproducibility, easily scaling to gigabytes of data and mucho RAM, evaluating existing pipelines like lobSTR quickly.

But what about if you want to these benefits when running your own pipelines?

In other words, how do you **port a pipeline** to Arvados?

h2. 1. Quick Way

First, do you just want to parallelize a single bash script?

Check if you can use @arv-run@. Take this arv-run example, which searches multiple FASTQ files in parallel, and saves the results to Keep through shell redirection:

    $ arv-run grep -H -n GCTACCAAGTTT \< *.fa \> output.txt

h3. 1.1 Install arv-run

See: http://doc.arvados.org/sdk/python/sdk-python.html and http://doc.arvados.org/user/reference/api-tokens.html, or in short below:

<pre>

$ sudo apt-get install python-pip python-dev libattr1-dev libfuse-dev pkg-config python-yaml

$ sudo pip install --pre arvados-python-client

</pre>

(Lost? See http://doc.arvados.org/sdk/python/sdk-python.html )

If you try to use arv run right now, it will complain about some settings your missing. To fix that,

# Go to su92l.arvadosapi.com

# Login with any Google account (you may need to click login a few times if you hit multiple redirects from Google)

# Click in the upper right on your account name -> Manage Account

# Optional: While you're here, click "send request for shell access", since that will give you shell access to a VM with all of the Arvados tools pre-installed.

# Copy the lines of text, something like

<pre>

HISTIGNORE=$HISTIGNORE:'export ARVADOS_API_TOKEN=*'

export ARVADOS_API_TOKEN=sekritlongthing

export ARVADOS_API_HOST=su92l.arvadosapi.com

unset ARVADOS_API_HOST_INSECURE

</pre>

# If you want this to persist across reboot, add this to ~/.bashrc or your ~/.bash_profile

(Lost? See http://doc.arvados.org/user/reference/api-tokens.html )

h3. 1.2 Submit job to Arvados

First, check: Does your command work locally?

    $ grep -H -n GCTACCAAGTTT *.fa

If so, then submit it to arvados using @arv run@

    $ arv-run grep -H -n GCTACCAAGTTT \< *.fa \> output.txt

* This bash command stores the results as output.txt

* Note that due to the particulars of grep, Arvados will report this pipeline as failed if grep does not find anything, and no output will appear on Arvados

Your dataset is uploaded to Arvados if it wasn't on there already (which may take a while if it's a large dataset), your "grep" job is submitted to run on the Arvados cluster, and you get the results in a few minutes (stored inside output.txt in Arvados). If you go to Workbench at su92l, you will see the pipeline running. It may take a few minutes for Arvados to spool up a node, provision it, and run your job. The robots are working hard for you, grab a cup of coffee.

(Lost? See http://doc.arvados.org/user/topics/arv-run.html )

h3. 1.3 However

If your pipeline looks more like [!image crazy graph], arv-run is not powerful enough. Here we gooooo.

h2. 2. In Short

**Estimated reading time: 1 hour.**

You must write a **pipeline template** that describes your pipeline to Arvados.

h3. 2.1 VM (Virtual Machine) Access

Note: You'll need the Arvados set of command-line tools to follow along. The easiest way to get started is to get access to a Virtual Machine (VM) with all the tools pre-installed.

# Go to su92l.arvadosapi.com

# Login with google account (you may need to click login a few times, our redirects are not working well)

# Click in the upper right on your account name -> Manage Account4. Hit the "Request shell access" button under Manage Account in workbench.

h3. 2.2 Pipeline Template Example

Here is what a simple pipeline template looks like, where the output of program A is provided as input to program B. We'll explain what it all means shortly, but first, don't worry -- you'll never be creating a pipeline template from scratch. You'll always copy and modify an existing boilerplate one (yes, a template for the pipeline template! :])

    **pipelinetemplate.json**

    {

    "name": "Tiny Bash Script",

      "components": {

        "Create Two Files": {

          "script": "run-command",

          "script_version": "master",

          "repository": "nancy",

          "script_parameters": {

            "command": [

              "$(job.srcdir)/crunch_scripts/createtwofiles.sh"

            ]

          ,

          "runtime_constraints": {

            "docker_image": "nancy/cgatools-wormtable"

        ,

        "Merge Files": {

          "script": "run-command",

          "script_version": "master",

          "repository": "nancy",

          "script_parameters": {

            "command": [

              "$(job.srcdir)/crunch_scripts/mergefiles.sh",

              "$(input)"

            ],

            "input": {

              "output_of": "Create Two Files"

          ,

          "runtime_constraints": {

            "docker_image": "nancy/cgatools-wormtable"

h2. 3. simple and sweet port-a-pipeline example

Okay, let's dig into what's going on.

h3. 3.1 the setup

We'll port an artificially simple pipeline which involves just two short bash scripts, described as "A" and "B" below:

**Script A. Create two files**

Input: nothing

Output: two files (out1.txt and out2.txt)

**Script B. Merge two files into a single file**

Input: output of step A

Output: a single file (output.txt)

Visually, this looks like [!graph image] (ignore the long strings of gibberish in the rectangles for now).

Here's what we've explained so far in the pipeline template:

    **pipelinetemplate.json**

    {

    **"name": "Tiny Bash Script",**

      "components": {

       **"Create Two Files": {**

          "script": "run-command",

          "script_version": "master",

          "repository": "arvados",

          "script_parameters": {

            "command": [

              "$(job.srcdir)/crunch_scripts/ *createtwofiles.sh* "

            ]

          ,

          "runtime_constraints": {

            "docker_image": "nancy/cgatools-wormtable"

        ,

        **"Merge Files": {**

          "script": "run-command",

          "script_version": "master",

          "repository": "arvados",

          "script_parameters": {

            "command": [

              "$(job.srcdir)/crunch_scripts/ *mergefiles.sh* ",

              "$(input)"

            ],

           **"input": {**

              **"output_of": "Create Two Files"**

          ,

          "runtime_constraints": {

            "docker_image": "nancy/cgatools-wormtable"

h3. **3.2 arv-what?**

Before we go further, let's take a quick step back. Arvados consists of two parts

**Part 1. Keep** - I have all your files in the cloud!

You can access your files through your browser, using **Workbench**, or using the Arvados command line (CLI) tools (link: http://doc.arvados.org/sdk/cli/index.html ).

Visually, this looks like

[!image 1: workbench]

[!image 2: shell session, arv mount]

**Part 2. Crunch** - I run all your scripts in the cloud!

Crunch both dispatches jobs and provides version control for your pipelines.

You describe your workflow to Crunch using **pipeline templates**. Pipeline templates describe a pipeline ("workflow"), the type of inputs each step in the pipeline requires, and . You provide a high-level description of how data flows through the pipeline—for example, the outputs of programs A and B are provided as input to program C—and let Crunch take care of the details of starting the individual programs at the right time with the inputs you specified.

[!image 2: complex pipeline]

Once you save a pipeline template in Arvados, you run it by creating a pipeline instance that lists the specific inputs you’d like to use. The pipeline’s final output(s) will be saved in a project you specify.

Concretely, a pipeline template describes

* **data inputs** - specified as Keep content addresses

* **job scripts** - stored in a Git version control repository and referenced by a commit hash

* **parameters** - which, along with the data inputs, can have default values or can be filled in later when the pipeline is actually run

* **the execution environment** - stored in Docker images and referenced by Docker image name

**What is Docker**? Docker allows Arvados to replicate the execution environment your tools need. You install whatever bioinformatics tools (bwa-mem, vcftools, etc.) you are using inside a Docker image, upload it to Arvados, and Arvados will recreate your environment for computers in the cloud.

**Protip:** Install stable external tools in Docker. Put your own scripts in a Git repository. This is because each docker image is about 500 GB, so each new docker image takes a while to upload (30 minutes) if you are not using Arvados on a local cluster. In the future, we hope to use small diff files describing just the changes made to Docker image instead of the full Docker image. [Last updated 19 Feb 2015]

h3. 3.3 In More Detail

Alright, let's put that all together.

    **pipelinetemplate.json**

    {

    "name": "Tiny Bash Script",

      "components": {

        "Create Two Files": {

          "script": "run-command",

          "script_version": "master",

          "repository": "nancy",

          "script_parameters": {

            "command": [

              "$(job.srcdir)/crunch_scripts/createtwofiles.sh" **#[1]**

            ]

          ,

          "runtime_constraints": {

            "docker_image": "nancy/cgatools-wormtable"

        ,

        "Merge Files": {

          "script": "run-command",

          "script_version": "master",

          "repository": "nancy",

          "script_parameters": {

            "command": [

              "$(job.srcdir)/crunch_scripts/mergefiles.sh", **#[2]**

              "$(input)"

            ],

            "input": {

              "output_of": "Create Two Files" **#[3]**

          ,

          "runtime_constraints": {

            "docker_image": "nancy/cgatools-wormtable"    

**Explanation**

[1] **$(job.srcdir)** references the git repository "in the cloud". Even though **run-command** is in nancy/crunch_scripts/ and is "magically found" by Arvados, INSIDE run-command you can't reference other files in the same repo as run-command without this magic variable.

Any output files as a result of this run-command will be automagically stored to keep as an auto-named collection (which you can think of as a folder for now).

[2] Okay, so how does the next script know where to find the output of the previous job? run-command will keep track of the collections it's created, so we can feed that in as an argument to our next script. In this "command" section under "run-command", you can think of the commas as spaces. Thus, what this line is saying is "run mergefile.sh on the previous input", or

  $ mergefiles.sh [directory with output of previous command]

[3] Here we set the variable "input" to point to the directory with the output of the previous command "Create Two Files".

(Lost? Try the hands-on example in the next section, or read more detailed documentation on the Arvados website: 

* http://doc.arvados.org/user/tutorials/running-external-program.html

* http://doc.arvados.org/user/topics/run-command.html

* http://doc.arvados.org/api/schema/PipelineTemplate.html )

h3. 3.4 All hands on deck!

Okay, now that we know the rough shape of what's going on, let's get our hands dirty.

*From your local machine, login to Arvados virtual machine*

Single step:

  nrw@ *@nrw-local@* $ ssh nancy@lightning-dev4.shell.arvados

(Lost? See "SSH access to machine with Arvados commandline tools installed" http://doc.arvados.org/user/getting_started/ssh-access-unix.html )

**In VM, create pipeline template**

A few steps:

  nancy@ *@lightning-dev4.su92l@* :~$ arv create pipeline_template

Created object qr1hi-p5p6p-3p6uweo7omeq9e7

$ arv edit qr1hi-p5p6p-3p6uweo7omeq9e7 #Create the pipeline template as described above! [[Todo: concrete thing]]

(Lost? See "Writing a pipeline template" http://doc.arvados.org/user/tutorials/running-external-program.html )

*In VM, set up git repository with run_command and our scripts*

A few steps: 

  $ mkdir @~@/projects

$ cd @~@/projects

~/projects $ git clone git@git.qr1hi.arvadosapi.com:nancy.git 

(Lost? Find your own git URL by going to https://workbench.su92l.arvadosapi.com/manage_account )

    ⤷Copy run_command & its dependencies into this crunch_scripts

  $ git clone https://github.com/curoverse/arvados.git 

(Lost? Visit https://github.com/curoverse/arvados )

  @  @$ cd ./nancy

  *@~/projects/nancy@* $ mkdir crunch_scripts

  *@~/projects/nancy@* $ cd crunch_scripts

  *@~/projects/nancy/crunch_scripts@* $ cp @~@/projects/arvados/crunch_scripts/run_command . #trailing dot!

  ~/projects/nancy/crunch_scripts$ cp ~/projects/arvados/crunch_scripts/crunchutil . #trailing dot!

  @  @$ cd ~/projects/nancy/crunch_scripts

  @  @$ vi createtwofiles.sh

    ⤷ $cat createtwofiles.sh

    #!/bin/bash

    echo "Hello " > out1.txt

    echo "Arvados!" > out2.txt

  @  @$ vi mergefiles.sh

    ⤷$cat mergefiles.sh

      #!/bin/bash *#[1]*

      PREVOUTDIR=$1 *#[2]*

      echo $TASK_KEEPMOUNT/by_id/$PREVOUTDIR *#[3]*

      cat $TASK_KEEPMOUNT/by_id/$PREVOUTDIR/*.txt > output.txt

⤷ *Explanations*

*[1]* We use the @#!@ syntax to let bash know what to execute this file with

  ⤷To find the location of any particular tool, try using **which**

    $ which python

    /usr/bin/python

    $ which bash

    /bin/bash

*[2]* [[TODO: $1]] Here we give a human-readable name, @PREVOUTDIR@, to the first argument given to @mergefiles.sh@, which (referring back to the pipeline template) we defined as the directory containing the output of the previous job (which ran @createtwofiles.sh@).

*[3]* Using the environmental variable @TASK_KEEPMOUNT@ allows us to not make assumptions about where **keep** is mounted. @TASK_KEEPMOUNT@ will be replaced by Arvados automatically with the name of the location to which **keep** is mounted on each worker node. (Lost? Visit http://doc.arvados.org/user/tutorials/tutorial-keep-mount.html )

<pre>$ chmod +x createtwofiles.sh mergefiles.sh # make these files executable</pre>

**Commit changes and push to remote**

A few steps: 

  $ git status #check that everything looks ok

$ git add *

$ git commit -m “hello world-of-arvados scripts!”

$ git push

**Install Docker**

A few steps: 

  $ sudo apt-get install docker.io

$ sudo groupadd docker

$ sudo gpasswd -a $USER docker #in my case, I replace $USER with “nancy”

$ sudo service docker restart

$ exec su -l $USER   #if you don’t want to login+out or spawn a new shell, this will restart your shell

**Make docker less sad about running out of space on the VM**

A few steps:

  $ sudo mkdir /data/docker

$ sudo vi /etc/default/docker

@  @⤷$ cat /etc/default/docker

      DOCKER_OPTS="--graph='/data/docker'"

      export TMPDIR="/data/docker"

**Make Arvados less sad about running out of space on the VM**

A few steps: 

    $ sudo mkdir /data/docker-cache

$ sudo chown nancy:nancy /data/docker-cache

$ ln -s /data/docker-cache docker

**Create Docker image with Arvados command-line tools and other tools we want**

A few steps: 

    $ docker pull arvados/jobs

$ docker run -ti arvados/jobs /bin/bash

Now we are in the docker image.

    root@4fa648c759f3:/# apt-get update 

    @  @⤷In the docker image, install external tools that you don't expect to need to update often. 

    For instance, we can install the wormtable python tool in this docker image

    @  @# apt-get install libdb-dev

    @  @# pip install wormtable

    @  @  ⤷ Note: If you're installing from binaries, you should either

        1) Install in existing places where bash looks for programs (e.g. install in /usr/local/bin/cgatools). 

        To see where bash looks, inspect the PATH variable.

          #echo $PATH

          /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

        2) If you put them in a custom directory, remember them to reference them as such in your scripts

        (e.g. spell out /home/nrw/local/bin/cgatools).

        Arvados will not respect modifyng the $PATH variable by using the ~/.bashrc configuration file in the docker image.

(Lost? See http://doc.arvados.org/user/topics/arv-docker.html )

  root@4fa648c759f3:/# exit

*Commit Docker image*

<pre>

$ docker commit 4fa648c759f3 nancy/cgatools-wormtable #Label the image thoughtfully

$ #For instance here I used the name of key tools I installed: cgatools & wormtable

</pre>

*Upload Docker image from your VM to Keep*

<pre>

$ arv keep docker nancy/cgatools-wormtable #this takes a few minutes

$ arv keep docker #lists docker images in the cloud, so you can double-check what was uploaded </pre>

**Run this pipeline!**

Go to Workbench and hit **Run**.

<pre>$ firefox http://su92l.arvadosapi.com</pre>

[!image: workbench with 'tiny bash script']

*Note: If no worker nodes are already provisioned, your job may take up to 10 minutes to queue up and start.* Behind-the-scenes, Arvados is requesting compute nodes for you and installing your Docker image and otherwise setting up the environment on those nodes. Then Arvados will be ready to run your job. Be patient -- the wait time may seem frustrating for a trivial pipeline like this, but Arvados really excels at handling long and complicated pipelines with built-in data provenance and pipeline reproducibility.

h3. 3.5 Celebrate

Whew! Congratulations on porting your first pipeline to Arvados! Check out http://doc.arvados.org/user/topics/crunch-tools-overview.html to learn more about the different ways to port pipelines to Arvados and how to take full advantage of Arvados's features, like restarting pipelines from where they failed instead of from the beginning. 

h2. 4. Debugging Tips and Pro-Tips

h3. **4.1 Pro-tips**

**Keep mounts are read-only right now. [19 March 2015]**

Need to 1) make some temporary directories or 2) change directories away from wherever you started out in but still upload the results to keep?

For 1, Explicitly use the $HOME directory and make the temporary files there

For 2, Use present working directory, $(pwd) at the beginning of your script to write down the directory where run-command will look for files to upload to keep.

Here's an example:

<pre>

$ cat mergefiles.sh

  TMPDIR=$HOME #directory to make temporary files in

  OUTDIR=$(pwd) #directory to put output files in

  mkdir $TMPDIR

  touch $TMPDIR/sometemporaryfile.txt #this file is deleted when the worker node is stopped

  touch $OUTDIR/someoutputfile.txt #this file will be uploaded to keep by run-command

</pre>

* make sure you point to the right repository, your own or arvados.

* make sure you pin the script versions of your python sdk, docker image, and script version or you will not get reproducibiltiy.

* if you have a file you want to use as a crunch script, make sure its in a crunch_scripts directory. otherwise, arvados will not find it. i.e. ~/path/to/git/repo/crunch_scripts/foo.py

h3. 4.2 Common log errors and reasons for pipelines to fail

Todo.

h3. 4.3 Miscellaneous Notes

Other ways to avoid the read-only keep mount problem is to use task.vwd which uses symlinks from the output directory which is writable to the colelction in keep. If you can change your working directory to the output directory and do all your work there, you'll avoid the keep read only issue.  (lost? see http://doc.arvados.org/user/topics/run-command.html )

When indexing, i.e. tabix, bwa index, etc. The index file tends to be created in the same directory as your fastq file. In order to avoid this, use ^. There is no way to send the index file to another directory. If you figure out a way, please tell me.

"bash" "-c" could be your friend, it works sometimes, sometimes it doesnt. I don't have a good handle on why this works sometimes.

if you're trying to iterate over >1 files using the task.foreach, its important to know that run-command uses a m x n method of making groups. I dont think I can explain it right now, but it may not be exactly what you want and you can trip over it. (lost? see http://doc.arvados.org/user/topics/run-command.html )

When trying to pair up reads, its hard to use run-command. You have to manipulate basename and hope your file names are foo.1 foo.2. base name will treat the group as foo (because you'll regex the groups as foo) and you can glob for foo.1 and foo.2. but if the file names are foo_1 and foo_2, you cant regex search them for foo becuase you'll get both names into a group and you'll be iterating through both of them twice, because of m x n. 

Your scripts need to point to the right place where the file is. Its currently hard to figure out how to grep the file names, you have to do some magic through the collection api.

h2. 5. Learn More

To learn more, head over to the Arvados User Guide documentation online: http://doc.arvados.org/user/