Cluster (CIN)
How to access the CIN Cluster (FIN)
Cluster Hardware/Software
more Information here
current use of the node:
born1 | free for all |
---|---|
born2 | free for all |
born3 | free for all |
born4 | free for all |
born5 | free for all |
born6 | free for all |
born7 | free for all |
born8 | free for all |
born9 | free for all |
born10 | free for all |
born11 | free for all |
born12 | free for all |
With the command "who" you can see who just used the node.
With the command "htop" you can see how high the usage on the Node.
The clusters are there for everyone!
It should not use someone all nodes alone!
At problems send an e-mail to
support-mp[at]medizin.uni-tuebingen.de
Remote Desktop
For Windows/MAC user
- open remote desktop
- Now ask xrdp after your access data
- Use your CIN login and password ( Create an account for the CIN Server )
- Now you're logged into a Debian system, from here you open a terminal window
- Connect over the terminal to the CIN Cluster with:
- Connect to a node with (for example cn47):
- ssh born1 -X
- Now you can start Matlab with command:
- start Matlab R2016a with this command "/usr/local/MATLAB/R2016a/bin/matlab &"
- start Matlab R2016b with this command "/usr/local/MATLAB/R2016b/bin/matlab &"
- start Matlab R2017b with this command "/usr/local/MATLAB/R2017b/bin/matlab &"
- start Matlab R2018b with this command "/usr/local/MATLAB/R2018b/bin/matlab &"
- start Matlab R2019b with this command "/usr/local/MATLAB/R2019b/bin/matlab &"
- start Matlab R2020b with this command "/usr/local/MATLAB/R2020b/bin/matlab &"
- wait a moment and Matlab will start!
You can close your Remote Desktop session and can reconnect later to the same session.
X-terminal forwarding (using Matlab GUI)
For Windows/MAC user
Installing Putty and Xming Tutorial
X2go - Client
For Windows/MAC user
coming soon
Docker
coming soon
For Linux User
start by step 3 in the Windows manual!
After you start your Matlab calculation, you can close remote desktop and login to a later time. Your Matlab calculation runs without remote desktop connection!
Passwordless SSH connection
For passwordless ssh connection between headnode and compute nodes type in on hn1:
$ ssh-keygen
You get following output and always press return without any changes:
Generating public/private rsa key pair. Enter file in which to save the key (/home/<user>/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/<user>/.ssh/id_rsa. Your public key has been saved in /home/<user>/.ssh/id_rsa.pub. The key fingerprint is: xx:xx..xx:xx <user>@hn1.medizin.uni-tuebingen.de The key's randomart image is: +--[ RSA 2048]----+ | . | | . o | | . . + o | | + . . o = | | . E S = + = .| | . . + = = o | | o + . | | . o | | . | +-----------------+
Now type in the following for the compute node you want to exchange your password
$ ssh-copy-id cnxx <user>@cnxx's password:
And type in your password for the last time. After you press return you will never be asked again for the password if you connect from the headnode to this compute node.
Your homedirectory is identical on every node, so this keychange allows you to switch passwordless to any node of the cluster
SSH Key Failure
If ssh keys are changed (could happen after updates etc.) and you can't login to a compute node anymore, you will get this message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is ... Please contact your system administrator. Add correct host key in /gpfs01/xx/.ssh/known_hosts to get rid of this message. Offending RSA key in /gpfs01/../.ssh/known_hosts:xx RSA host key for cnXX has changed and you have requested strict checking. Host key verification failed.
You can easily solve this problem with simply removing the old key from your known_hosts. Just use following command with the affected compute node name:
ssh-keygen -R bornXX (eg. born1)
After that you should be able to login to the node again without password and failure message.
Parallel Computing
Introduction: http://www.ch.cam.ac.uk/computing/maui-and-torque-introduction
Toolbox: https://github.com/fieldtrip/fieldtrip/tree/master/qsub
Manual: http://www.fieldtriptoolbox.org/faq/how_to_get_started_with_distributed_computing_using_qsub