Introduction

This is the sixth blog post in a series of articles about using the CCEB cluster. An overview of the series is available here. This post focuses on the basics of using an interactive session.

Interactive sessions are opened by requesting appropriate system parameters using the LSF bsub command. Once a session is open you can run your code on the loaded host interactively. This allows you to work dynamically on your code. Utilizing this resource on the cluster is best for when you’re writing code for the first time, debugging code, or running code that uses a small amount of memory and runs fast.

An interactive session can be utilized on a single core (default) and for parallel computing. This post is going to focus on a single core and the next will cover parallel computing.

Code to Log On

A whole blog post is dedicated to logging onto the cluster and can be found here. As a refresher the code is below. Remember to connect to the VPN using Pulse Secure.

ssh -X pennkey@scisub

Interactive Session Basics

Once you’ve logged onto the cluster you need to use a bsub command to open an interactive session. A full reference manual of the bsub command is available online here.

The most basic bsub command to open an interactive session is below:

bsub -Is -q cceb_interactive "bash"

• bsub is the command name which communicates to LSF to submit a job.
• -Is is an option that submits an interactive job and creates a pseudo-terminal with shell mode support when the job starts.
  
• -q cceb_interactive submits the job to the specified queues. The specified queues must be defined for the local cluster. For a list of available queues in your local cluster, use bqueues. As a student or staff you should have access to the cceb_interactive queue. In certain groups you may have access to different queues. For example, in Taki’s group we have access to taki_interactive, a portion of the cluster reserved for the PennSIVE working group.

After executing this command you’ll see some output that either successfully puts you onto an execution host or fails. The output will explicitly tell you which machine you’ve been put on. This can be useful for quality control in the event of problems with memory or speed.

Now that you are on an execution host you need to load R or another computing language. To load R on the cluster just type module load R/version. I personally have been using R version 3.5.0 on the cluster so I’d type module load R/3.5.0. In a later blog post, I’ll discuss bash aliases and how you can bypass typing module load R/3.5.0 before opening R. If you want to see what other versions of R are available on the cluster type module load R then hit tab twice. You will see some output with all the different versions installed. This is an excellent resource if the package you want to use requires an older version of R. You won’t have to uninstall and re-install R on your local machine.

Once you have ssh’ed, bsub’ed, and module load’ed R, just type R.

Based on the output after my bsub I was successfully put onto the amber03 machine. You’ll notice that the terminal with R open looks very similar to the console after opening a new R session in RStudio. At this point you can go about coding as you normally would in R.

As an example, let’s run a simple and useful function for cluster computing. Provided below is a simple function:

lsos <- function (..., n = 10) {
  .ls.objects(..., order.by = "Size", decreasing = TRUE, head = TRUE, n = n)
}

This function will return what objects you have loaded in your R environment with some information about the type of object, the size, and the dimension of the object. For example, if you run the lsos function from above and then run the following:

first  = 'my first name is Ali'
last = 'my last name is Valcarcel'
number = 9
lsos()

You should see the following returned:

At this point, you’re ready to run code on the cluster. Remember you can always save data or plots to your home directory on the cluster or wherever appropriate given your permissions. If you need to continue working locally use Fetch to pull the material off the cluster.

In future posts, I’ll discuss the power of the bsub and how to request different parameters on the cluster. For example, you can be given access to more than 1 core for parallelization or have your job be killed if you exceed a certain memory by using different options associated with the command.

To exit out of R just type q() and hit enter. You’ll be asked if you would like to save your environment so just type what you would like to do.

It is important to note that if you click the x, the exit button, on your terminal window to close terminal then the interactive session you had open will be terminated and killed. Essentially, you’re logged off. If you want to exit out of R and your entire session you are free to just exit the window and everything will quit and exit.

Screen

Unfortunately, in an interactive session if your WiFi connection drops, the VPN connection drops, or you exit the ssh session (i.e. exit out of terminal) then the interactive session will be interrupted, killed, and exited. Your work being done on the remote locally will be lost. This is especially frustrating for longer-running tasks. Luckily, there is a utility called screen that is already installed on the cluster that allows your work to continue running in the event of lost connections or exiting and you can resume the session later. For example, say you’re running a set of simulations that will take approximately 10 hours. You’re not going to sit there and make sure your computer doesn’t go to sleep or lose connections. You just want your code to run uninterrupted. Screen is the solution to this dilemma.

Screen also referred to as GNU Screen is a terminal multiplexer. This means that you can start a screen session and then open any number of windows (virtual terminals) inside that session. Processes running in Screen will continue to run when their window is not visible even if you get disconnected. Screen is kind of like the movie Inception. Think dream within a dream. You’ll log onto the cluster from your local machine. Then from the remote host you’ll screen a session. This opens a session inside of session so that if you exit the terminal on your computer the session within a session will continue.

For more information about screen and how to use it check out this How To Use Linux Screen article or the the manual.

# Log onto the cluster
ssh -X alval@scisub
# Screen the session while on the scisub host
screen
# bsub and work interactively as you would like
bsub -Is -q cceb_interactive "bash"
# Load R
module load R/3.5.0
# Open R
R
# run stuff you'd like

screen -ls

screen -r

screen -r 30768.example1

Downloading R Packages and Software

The cluster is already configured with a number of useful day to day packages that most of us use consistently. There will be times though that you need a specific package installed.

For security reasons you will not be able to download packages manually. For example, install.packages('ggplot2') will error. Instead, email the Scientific Computing System Administration Team. I have excluded their email from this series of posts so they don’t inadvertently receive spam but just ask around and it should be easy to track down. In your email you should include the version(s) of R you would like the package installed, the package name, and package version you need downloaded. When they install the package, it will only be available in the version of R you specified. When possible it is also helpful to include a link to the package (i.e. CRAN or GitHub links).

Similarly, if you need other non-R software downloaded on the cluster email them to install and configure.

module load R

After sshing onto the cluster and bsubing onto an execution host in order to load R you have to type the following:

Of course, you can use whatever version of R you prefer or need. I find typing this every time I log on really annoying. This also has to be loaded when submitting a job as a normal session. I’ll talk more about normal sessions later but you’ll end up typing module load R/#.#.# almost every time you’re doing something on the cluster. Luckily, there are start up scripts that we can add this to so that it is automatically run when we begin our session.

To avoid typing module load R/#.#.# everytime you can put module load R/3.5.0 (or whatever version of R you use the most) in your .bash_profile. A .bash_profile is essentially a start up script. Anything in your .bash_profile is run for you immediately after logging on. Therefore, if you put module load R/3.5.0 this line of code is run as soon as you log on to the submission and execution host automatically and there is no need to type it. After this is added all you have to type is R on the command line and R will open.

Remember, this bash command will be run upon logging on. If you want to load a different R module, you’ll have to first unload the one specified in your .bash_profile and then load the one you’d like to use.

You can do this with any module load you use often.

There are a number of ways to edit your .bash_profile. You can use the command line but I like to do this using Fetch.

Edit .bash_profile instructions:

1. Connect to the VPN
2. Open Fetch into your home directory. The full path is normally /pennkey/home.
3. Right-click on .bash_aliases within Fetch and choose the option Edit. You might get a pop-up asking you to choose what program you’d like to edit the file with. I personally like TextEdit.

4. A pop up text editor of your .bash_profile will open.

5. Add the line module load R/3.5.0 or whatever R version you like to this file.
6. Save and exit.

Now, if you open an interactive session you only need to type R.