GPI - Image Processing Group
Access services
The first thing you have to do in this landing is to connect to the GPI servers.
The basic information to connect to our servers is:
- Server / Host: calcula.tsc.upc.edu
- SSH Port: 2225
- Credentials (user/pass): Use your TSC credentials.
You have two main ways to connect to our server: Terminal only or with a Graphical interfaces available.
In addition, there is an specific Landing Page for GPI at TRAC
Terminal (SSH)
Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. SSH was designed as a replacement for Telnet and other insecure remote shells, which send information, notably passwords, in plaintext, rendering them susceptible to packet analysis. The encryption used by SSH is intended to provide confidentiality and integrity of data over an unsecured network, such as the Internet.
Linux and Mac use to have a ssh-client out-of-the-box. Just open a Terminal application and type the following command replacing username by your actual username:
>> ssh -p2225 username@calcula.tsc.upc.edu
If you are at the UPC or you have a really good internet connection you can use X11-Forwarding by:
>> ssh -X -p2225 username@calcula.tsc.upc.edu
If your laptop is Windows, then the recommended option is to install Mobaxterm as a terminal, open a local terminal and type the above commands. Here you have a basic tutorial for Mobaxterm. For downloading or uploading files to the server, you can use FileZilla on Windows, Linux and macOS. Here you haver a basic tutorial for FileZilla.
Storage services
We have different network storage services:
- /home/usuaris/imatge/$user:: (also linked as /imatge/$user and /mnt/gpid07/imatge/$user
- Contents: users' home data: code, documents...
- Backup: Weekly
- Quota: 50GB/user
- /mnt/gpid08/users/$user:: On demand, ask to your responsible
- Contents: users and projects data: experimental results, images, videos...
- Backup: NO
- Quota: 100G/user
- /mnt/gpid08/datasets
- Contents: Datasets, you can find a Readme.md file with its structure. Only writable by professors and project responsibles
- Backup: NO
- Quota: on demand
Computing services
We have a computing service, to be able to run a lot of experiments using all our computing servers, but keeping our access servers free to be used to code or other non-processing-intensive tasks.
Environment Modules
The Environment Modules package provides a mechnism for dynamic modification of a user's environment via modulefiles. Each modulefile contains the information needed to configure the shell for an application. Environment Modules has been around since the early 1990s and is used at some of the largest computer centers to deploy multiple versions of different software tools to users. Modules can be loaded and unloaded dynamically and atomically, in an clean fashion. All popular shells are supported, including bash, ksh, zsh, sh, csh, tcsh, as well as some scripting languages such as perl and python.
The idea is quite similar to Python's VirtualEnv, and somehow related to some of the goals of Docker.
Why did we start using it at GPI?
Some time ago we all tried to share the same environment in order to be able to also share code between us. We created, developed and used ImagePlus, and we setup our SDK in a default PATHs in order to be used by everybody. Although the idea is still a good one, the amount of open-source code that we can use, its fast evolution, versioning and forks, and the DeepLearning revolution, have forced us to redesign our workflow.
We want to provide the means to allow as much flexibility as possible to all us to create our own SDK picking the right combinations of depencies and their versions.
That's why we want to start using EnvironmentModules, VirtualEnv, Docker and similar technologies.
In practice, Environment Modules is the best way to handle environment variables like:
- PATH: for apps
- LD_LIBRARY_PATH: for shared libs
- CPATH and LIBRARY_PATH: for GCC includes and libs
- PKG_CONFIG_PATH: for .pc files)
- CMAKE_MODULE_PATH: for .cmake files
- CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH: for CMake includes and libs (CMake is not using the standard CPATH and LIBRARY_PATH)
- PYTHONPATH: for Python modules
Configuration
We've decided to drastically minimize the amount of software in any default path. So, to use any software we will need to load it before:
>> matlab # won't work! >> module load matlab >> matlab # will work!
To still keep some of the "sharing SDK" idea, we will try to install all the modules to a shared directory /opt, so we will be able to use the same versions or not as needed. And it will also allow to get support from Josep Pujal.
Also, we have created a small naming convention between directory names and tag versions of the installed software to use a default and complete modulefile template for all of them.
Usage
List available modules:
>> module avail ----------------------------------------------------------------------------- /opt/etc/modules ------------------------------------------------------------------------------ cmake/3.15.5 cuda/9.0 cuda/10.0 cudnn/6.0 cudnn/7.4 gcc/5 gcc/7 jdk/11.0.2 openpose/1.5.1 pycharm/2019.1.3 slurm/18.08 tmux/2.8 xv/2019.09 cuda/8.0 cuda/9.1 cudnn/5.1 cudnn/7.0 gcc/4.8 gcc/6 golang/1.12.1 matlab/2018b protobuf/3.9.2 singularity/3.2.1 slurm/19.05 virtualgl/2.6 -------------------------------------------------------------------------- /opt/etc/modules-custom -------------------------------------------------------------------------- custom/openpose-1.5.1
Please note that custom is no really a module, but a way to allow extra setup where the standard modulefile is not enough (usually because the lib is not following standard rules of paths)
Load the default version of a module
>> module load matlab
Load an specific version of a module
>> module load matlab/2018b
List the already loaded modules:
>> module list
Unload a module
>> module unload matlab
Unload all the modules (purge)
>> module purge
Share: