Access to the cluster is made trough an independent virtual machine called frontend(ctcomp2.inv.usc.es). This frontend has very limited resources and it's only purpose is to manage file transfers and job submissions to queues. Code execution is not allowed in this server.

Remote access to the frontend is made with ssh (secure shell). Access credentials are the CITIUS ones. Note: If having problems connecting using the hostname then use the IP address instead: 172.16.242.122.

local$ ssh [-X] -p 1301  citius_user@ctcomp2.inv.usc.es
Password:
ctcomp2$ 

The -X parameter is optional. Connects the X redirection. It is an essential requirement in order to execute programs that need a graphical mode.

The cluster's filesystems are independent and are isolated from the CITIUS network so it is necessary to import to the cluster's user space all necessary files to execute our programs (for example, source code or the input files).

An user has the following places available, inside the cluster's filesystem, to place his files:

• /home/local/name.surname/
  This directory is the user's $HOME and is accessible from all the cluster nodes including the frontend. By default it is the reference directory of code accessed by all running jobs in the computing nodes. Each user's available space is limited by quotes, so very big files will have to be stored in the /sfs/ directory.

• /sfs/
  This directory is also shared between the nodes and the frontend. It can be used as an auxiliary space during job execution, for temporary file files that need to be accessible by all nodes or to store files resulting from job execution. Inside this directory any file not accessed in the last 30 days can be deleted. It is recommended to use file/directory names that identify clearly the coupling between user and programs to avoid potential conflicts between users.

• /scratch/
  Each node has a local scratch directory that can be used for temporal local storage during job execution. The contents of the scratch directory is not visible from other nodes nor is visible from the frontend, as such is not a good choice for storing results files. The content of this directory can be erased any time. It is recommended to use file/directory names that identify clearly the coupling between user and programs to avoid potential conflicts between users.

To import and export the necessary files in and out the cluster the scp command is used. It allows the user to move files between other file systems in the network. Syntax of the scp command is the following:

scp -P 1301 [-r] <source_address> <destination_address>

Argument explanation:

• -r (optional) Used whenever source address is a directory and denotes that directory contents must be copied recursively.
• <direccion_origen> Indica la ruta completa del fichero/directorio que se copiará.
• <direccion_destino> Indica la ruta completa donde queremos ubicar la copia del fichero/directorio.

As an example, several cases of file imports are shown. In this examples it is assumed that the user is user.name and that his workplace is ctXXX.inv.usc.es. The file/directory to be imported is located in ctXXX.inv.usc.es in the /datos/work/ directory and that we want to copy them to the user's working space in the cluster in the directory work in the user's $HOME. If we use scp from inside the cluster after logging in trough ssh:

ct$ scp -P 1301  user.name@ctXXX.inv.usc.es:/datos/work/one.file  ~/work/
ct$ scp -P 1301  -r user.name@ctXXX.inv.usc.es:/datos/work/directory/  ~/work/

Id using scp from our own computer:

local$ scp -P 1301 /datos/work/one.file  user.name@ctcomp2.inv.usc.es:~/work/
local$ scp -P 1301  -r /datos/work/directory/   user.name@ctcomp2.inv.usc.es:~/work/