About the service¶
By contrast with the compute clusters, to which batch jobs must be submitted, the machines listed here are ‘interactive’ machines, meaning that users are expected to use them directly rather than through a scheduler. The main advantage is that there is no need to wait for a job to start, but at the same time, if many users are busy on the same machine, the performances quickly degrade.
Those machines are typically used either through SSH, through a dedicated web interface (e.g. RStudio), or through a specific client (e.g. SAS Enterprise Guide.) When accessed through SSH, using a terminal multiplexer such as Screen or tmux is often useful for long-running processes that need to survive logging off the machine.
The machines SMCS1&2 are both dedicated to statistical applications. They are managed in collaboration with SMCS and offer the following services:
With 32 CPU cores at 3.5GHz and 192GB of memory, they can perform larger statistical analysis than any laptop on the market would be able to handle.
As they share a single home space for user files, you can use both ; the files you copy on one will be visible on the other automatically. That shared storage is backed up every day.
To have access to those machines, you will need to tick the box ‘Statistical computing’ when you create your CISM account.
Brufence and CeSAM¶
Several versions of Matlab are installed, which can be selected using modules. For instance, on Brufence:
$ module av matlab --- /usr/share/Modules/modulefiles --- matlab/R2010a matlab/R2015a matlab/R2013a matlab/R2017a
Beside the classical use of Matlab to perform numerical computations, the machines can also be used to compile Matlab code to standalone executables that can be run on the clusters without the need to have Matlab installed. More information on this can be found in the slides of the Matlab training session.
All machines share a single common storage.
Access and file transfer¶
To connect to the interactive machines, you will need to use your CISM login and password.
Accessing the machines¶
On Linux and MacOS, those are installed by default. In Gnome, for instance, you can hit Ctrl+Alt+T to open a terminal window. In MacOS, search for “terminal” in the Launchpad.
Once the terminal is open, you can type in commands. To use the SSH client to connect to a machine, run the following command:
ssh -X <my_cism_login>@<machine_name>.cism.ucl.ac.be
Make sure to replace the parts in
<my_cism_login> with your actual login and
<machine_name> with the name of the computer you want to connect to. The
-X option allows using software with a graphical user interface (GUI). You can ignore it if all you need is a command line interface (CLI). Note that on MacOS, you will need to install XQuartz for this to work.
When you login, you will be asked for your password. You should then give the password you chose when you created your account. You can spare the need for typing the password at every login by using SSH keys. See Creating and using SSH keys.
On Windows, the easiest way is to install (or simply download) MobaXterm. Then in MobaXterm, create a new SSH session, and specify the machine name, you CISM login and password.
If connecting from outside the UCLouvain network, you might need to use an SSH gateway .
The usual way is to use the commands
rsync. You can always use any graphical user interface you like as long as it uses scp or sftp to make the transfers. For instance, you can run the following in a terminal:
scp -r <source_dir> <my_cism_login>@<machine_name>.cism.ucl.ac.be:<target_dir>
<source_dir> on your laptop to
<target_dir> on the machine, and
scp -r <my_cism_login>@<machine_name>.cism.ucl.ac.be:<source_dir> <target_dir>
to copy a directory back. See the scp manpage for more examples or type ‘’man scp’’ or ‘’man rsync’’ to get information about those commands.
Programs that are run from the SSH command line will be killed whenever the SSH connection is lost, which can happen from a loss of network connectivity, a laptop crash or shutdown, etc.
Multiple solutions can be resorted to, based on the
nohup or the
disown Linux commands, but the most user-friendly way to address the issue is to use a terminal multiplexer such as Tmux (most recent and feature-full) or Screen (more ancient but more widely available).
The way they both work is that the first time you start working on a remote computer, you start a Screen or Tmux session by running the corresponding
screen command followed by ENTER. Make sure that command is run on the remote computer and not your laptop or local workstation.
The screen will blank, and you get the prompt back where you can work as usual and run the commands you want. Then, at some point, when you want, you can detach from the session. With Screen this is done with
CTRL-a d i.e. press and hold the CTRL key and the
a key at the same time, then release both and hit the
d key. Actually all “actions” in Screen are prefixed with the same
CTRL-a sequence. Tmux works exactly the same way except you need to do it with
CTRL-b d so the prefix for Tmux is
CTRL-b. You will then come back to the session from which you started the multiplexor, recovering what was displayed on the screen at the time.
You can then disconnect from the remote computer; your program will keep running.
Later on, you can reconnect with SSH to the remote computer and re-attach to the Tmux or Screen session. This is done by running the
screen -r command or the
tmux a command depending on which program was used in the first place. Then, your screen blanks and you get the session in which your long-running program is running.
The nice thing is that this process will work even if you did not detach safely and your laptop crashed instead. You can simply SSH back to the remote computer again and re-attach to the session.
You can actually start multiple sessions on the remote commuter and name them. You can list the running sessions with
screen -ls or
tmux ls. You will find more information on the respective manual pages of both commands :
man tmux or
man screen. An example with screenshots is also available in the slides of the CISM/CÉCI training sessions dedicated to Matlab for which a video is also available.
While both Scren and Tmux do a good job at protecting running programs from disconnections, there are a few caveats you must be aware of.
Scrolling in both is a more complicated than using the scrolling wheel of the mouse or using the scroll bars of the terminal window. It can work but requires slightly more configuration.
Copy/pasting with the mouse also does not work out of the box and requires specific configuration.
Graphical programs are not design to work with terminal multiplexer. In such cases, other solutions like VNC must be pursued.