Accessing the MERCED Cluster

Open a terminal application

Once you have an account, the cluster can be accessed on Mac and Linux where you can use a built-in terminal application; on Windows you can use WSL or Moba XTERM to open a terminal

ssh <YourUCMercedNetID>@merced.ucmerced.edu

Note that you have to be connected to the VPN in order to access the MERCED cluster. Information on downloading and accessing VPN here.

Using ssh to connect to MERCED places a user on the login, or head, node. Do not run computationally intensive processes on the head node. File preparation/editing, compiling, simple analyses, and other low computational
cost activities are appropriate on the head node, but, again, other types of work should be submitted to the cluster via the available queue system. Users may also connect to MERCED using an x-terminal to spawn graphics based programs such as gnuplot, gimp, etc. For more information using x-terminals for such uses, contact the MERCED system administration team.

Getting Around

In the following we will assume you have some familiarity with linux; if you do not feel free to book a consultation with the IT team; but a lot of resources are available on the internet. 

After login in on the merced cluster you can run the following command to see the available content: 

$ ls
help data scratch

Those are 3 folders that you will start with. 

  •  Store in data all that is research grade data that need to be backed-up and safe. 
  •  Put in scratch everything that is temporary; all files older than 5 weeks are removed from scratch. Use if for jobs checkpoints or similar.
  •  help is the content of this GitHub repository which is regularly synchronized with the cluster. It contains examples jobs and tests scripts. 

Running your first job on MERCED

Unlike with your computer you cannot just run a program on a supercomputer. It is a shared resources, so you need to wait in line when running a process for more than a few minutes.

Let's see how to run our first job. In the help folder you will findprojectile.exeandsample.sub. The former one is a compiled binary that compute the trajectory of a projectile, the later is a set of instruction that tell the super computer how to run projectile.exe; copy both to your home folder denoted~:

$ cp ~/help/projectile.exe ~/
$ cp ~/help/sample.sub ~/

Let's edit sample.sub:

#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem-per-cpu=1G
# #SBATCH --partition fast.q
#SBATCH --time=0-00:15:00 # 0days 15 minutes
#
#SBATCH --output=myjob_%j.stdout
# #SBATCH --job-name=test #SBATCH --export=ALL

# This submission file will run a simple set of commands. All stdout will be
# captured in mmyjob_XXXX.stdout (as specified in the Slurm command above).
# This job file uses a shared-memory parallel environment and requests 1 cores 
# on a single node.This script loads PGI compiler module named "pgi"

whoami
+date
module load pgi
+./projectile/.exe
+sleep 60

The bolded lines are those that need to be modified per your needs. If you are unfamiliar with the terminal you can use $ nano sample.sub to edit this file. At the bottom of the screen are the shortcut to same, and quit ^W (Ctrl+W, then enter) to save, and ^X (Ctrl-X) to quit.

Let's quickly describe the files; the first 4 lines tell the super computer how many machine you are requested; how many tasks you expect to run, how many CPU per task, and how much memory per task. So far we will not go beyond 1 machine (or node). Most of these are indicative of what you expect to use. We will make sure you have at least that available to run your program.