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
Interactive jobs are started with qinteract. To start an interactive job,
Running an interactive job for the first time may launch a prompt confirming the connection
The authenticity of host 'node4.biac.duke.edu (22.214.171.124)' 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.
Once the connection has been established, the prompt should indicate the node where the interactive job has been started.
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 8G of ram per job that is submitted. If your job requires more than 8GB, 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 -q interact.q -V -verbose -N interact -l h_vmem=10G bash
The above example will request/reserve 10G 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 8G 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 187GB 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 5GB cumulative quota on all $HOME directories ( shared with your window's home directory ) and a 32GB cumulative quota for space in /tmp ( or $TMP ) across all nodes combined.
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/BIAC” A call to a valid path will be intercepted by the proxy, and mounted. Paths are /mnt/BIAC/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/BIAC/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.
To load the entire graphical matlab desktop:
Please not that this requires a lot of memory to run the desktop, so if the environment is not needed consider running:
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
You can run matlab without the desktop and without the java-virtual-machine if you continue to have “out of memory” errors: - some functions that require java may no longer be accessible
matlab -nodesktop -nojvm -nosplash
Also, if you continue having JAVA memory errors you can create a java.opts file to increase the JAVA memory that matlab uses. In a directory where you launch matlab, create a file names “java.opts” containing the following lines:
This will increase the initial java-virtual-machine to 128 megabytes from the default of 64, it will also allow it to grow to 1gigabyte from the previous default of 128mb. This is only relevant if NOT using the “-nojvm” flag.
You can also set the heap space preference through the graphical desktop in matlab: http://blogs.mathworks.com/community/2010/04/26/controlling-the-java-heap-size/
Just a word of cause, setting it to the max available space in the gui caused matlab to not open ( for me )
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.
To launch the fsl GUI for creating fsf design files used by feat,