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, because of resource contention.
Often, the intractive servers have a preffered usage, such as statistical computing or Matlab code compiling, and offer specific, possibly licence-restricted, software, depending on the entity that funded them.
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.)
Access & conditions¶
- access to most servers is granted automatically to every member of the University, a CISM account must be requested ;
- access servers for statistical computing is subjected to SMCS approval and must be requested by ticking the Statistical commputing box when requesting the CISM account ;
- access to the servers might be reserved without prior notice for the entity that funded them when necessary.
List of servers and services¶
|Rstudio-server||Openstack||Rstudio||2x 32CPUs/192GBRAM||https://smcs1.cism.ucl.ac.be/rstudio or https://smcs2.cism.ucl.ac.be/rstudio|
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 SMCS1&2, 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. 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.
Brufence also has a licence of Magma installed.
All machines share a single common storage.
Pelican was acquired thanks to funding from ELIC and is designed for post processing of data produced on the clusters. It offers a specific 44TB local storage reserved to ELIC members. The ELIC mass storage is furhtermore mounted through NFS on Pelican to facilitate data transfers.
We offer access to a Jupyterhub service running on our private cloud. It is meant for small tests rather than heavy computations. You can access ith with your CISM accout.
Make sure to login with your CISM account, and not your email address. While this will allow you to authenticate, some functionalities will fail to work properly.
While you can copy files through the web interface, the home directory is shared with the interactive machines Brufence and Cesam so you can also use
rsync through those servers for a more convenient data transfer.
Access and file transfer¶
Access and file tranfers to the SSH servers are done through the SSH protocol (
sftp, or any graphical user interface built upon SSH:
MobaXTerm, Filezilla, Cyberduck, etc.) in a very standard way with your CISM
login and password.
Access to the web services is done also with the CISM login and password, simply using a browser and navigating to the URLs listed in the table above. File transfers can be done using the web interface or with SSH connecting to an interactive server.
Note that these machines are accessible directly only from within the network of the university or through the UCLouvain VPN. You won’t be able to access it from your home or from abroad. To access it from outside the university, you will need to use a gateway as explained here.
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.
About the costs¶
Access is free of charge, but storage space is limited, and access might be reserved periodically to the funding entity.