This is an old revision of the document!
Table of Contents
Interactive Jobs
The cluster allows for interactive jobs where you can login to machines and interact with your scripts/etc directly. There are currently 51 available interactive slots, which will each be allocated 4GB of memory. QSUB submissions can be run from interact slots in the same manner as described under Job submission
Starting an interactive job
Interactive jobs are started with qinteract. To start an interactive job,
> qinteract
Running an interactive job for the first time may launch a prompt confirming the connection
The authenticity of host 'node4.biac.duke.edu (152.3.98.178)' can't be established. RSA key fingerprint is d8:ae:54:b5:99:3b:34:c2:40:da:d0:70:b2:e5:9b:b0. Are you sure you want to continue connecting (yes/no)?
A “yes” response followed by “Enter” key will establish the connection. A password prompt requesting the cluster password ( used while logging into einstein) will appear.
deshmukh@node4.biac.duke.edu's password:
Once the connection has been established, the prompt should indicate the node where the interactive job has been started.
[deshmukh@node4 ~]$
Job restrictions
Each node has a finite amount of memory installed and due to the disk-less nature of the nodes there are restrictions set on the amount of ram used. Currently, the default is to assign 4G of ram per job that is submitted. If your job requires more than 4GB, then you may request a higher limit with the “-l h_vmem” directive … otherwise you don't have to do anything. This is done to prevent memory over subscription and to better distribute the load across the available machines.
> qrsh -l h_vmem=5G bash -li
The above example will request/reserve 5G of available memory. Your job will not go to a node unless it has the required amount available. Also, if you exceed the requested amount the grid engine will terminate the job and you will receive notice. In most cases you will not have to do anything, since 4G is a significant amount. The amount of ram used in your jobs is listed as “Max vmem” in the emails set from the cluster. The restriction is put in place to prevent memory being over allocated and jobs crashing an entire node, which would therefore kill other users' jobs.
The maximum available is 94.5GB on any node, so if you request more than that, the job will just sit in the queue waiting indefinitely.
Please do not request additional resources unless you absolutely need them. If additional resources are requested, they are deducted from the amount available to everyone else. If unneeded resources are requested, this reduces the capacity on a given node for other potential usage.
There is a 1GB cumulative quota on all HOME directories and a 32GB cumulative quota for space in /tmp ( or $TMP ) across all nodes combined.
Accessing experiments
Experiments can be reached multiple ways:
There is an automounter that is running on each node that can mount experiments when they are accessed through it's proxy filesystem “/mnt/BIAC2” A call to a valid path will be intercepted by the proxy, and mounted. Paths are /mnt/BIAC2/server.dhe.duke.edu/share/Experiemnt.01
If you are unsure, you can call the helper function findexp in various ways to return a valid path:
cd /mnt/BIAC2/munin.dhe.duke.edu/BIAC/Dummy.01 cd `findexp Dummy.01` ls `findexp Dummy.01` EXP1=`findexp Dummy.01`; cd $EXP1;
All of those instances would mount the experiment Dummy.01 within the proxy filesystem. The experiment paths within the proxy filesystem are consistent across all of the nodes, therefore you can access the data with the same path on any batch or interactive job.
mntshare //server/share [deshmukh@node4 ~]$ ls ~/net/fatt/data
this will mount the entire server and therefore you can access all the experiments on that share. You will be prompted for your window's password
lnexp Dummy.01 [deshmukh@node4 ~]$ ls ~/experiments/Dummy.01
this will mount a single experiment and create a symbolic link to the path in ~/experiments
using MATLAB
To load the entire graphical matlab desktop:
matlab
Please not that this requires a lot of memory to run the desktop, so if the environment is not needed consider running:
matlab -nodesktop
This turns the linux command line into the matlab command line. You'll still have access to all the functions, displays, etc … however this requires less overhead. If the full desktop is required, you will likely have to request slightly more ram than the default 4G.
If you do not need to interactively run matlab you can run a .m script without actually getting into the matlab environment. This is also the type of thing that should be submitted for batch processing:
matlab -nodesktop < myscript.m
Ending a job
To end a job type exit or ctr+D It may take a minute or two before the terminal is closed. Killing the terminal at this point will result in a failed job and affect the unmount process. Please wait till exit is complete. On completion you should see the prompt for the head node.
[deshmukh@head ~]$
Using FSL
To launch the fsl GUI for creating fsf design files used by feat,
> fsl