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.)

When accessed through SSH, using a terminal multiplexer such as Screen, Zellij or tmux is often useful for long-running processes that need to survive logging off the machine.

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¶

SMCS1&2¶

The machines SMCS1&2 are both dedicated to statistical applications. They are managed in collaboration with SMCS and offer the following services:

• SAS, which can be accessed either through SSH or SAS Entreprise Guide
• R, which can be used either through SSH or using an RStudio web interface.
• STATA, available in MP (parallel computing) mode.

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.

Brufence and CeSAM¶

These interactive machines are dedicated to Matlab use. They were acquired thanks to collaborations with the Department of Mathematical Engineering and the Louvain School of Management.

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¶

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.

Jupyterhub¶

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.

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 (ssh, scp, rsync, 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.

Running programs¶

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 tmux or 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.