≪ View Page

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
en:centro:servizos:hpc [2016/05/19 16:40] – fernando.guillenen:centro:servizos:hpc [2024/03/13 10:37] (current) – [Sending a job to the queue system] fernando.guillen
Line 1: Line 1:
-FIXME **This page is not fully translated, yet. Please help completing the translation.**\\ //(remove this paragraph once the translation is finished)//+====== High Performance Computing (HPC) cluster ctcomp3  ====== 
 +[[ https://web.microsoftstream.com/video/f5eba154-b597-4440-9307-3befd7597d78 | Video of the presentation of the service (7/3/22) (Spanish only) ]] 
 +===== Description =====
  
-====== High Performance Computing (HPC) ======+The computing part of the cluster is made up of: 
 +  * 9 servers for general computing. 
 +  * 1 "fat node" for memory-intensive jobs. 
 +  * 4 servers for GPU computing. 
 +  
 +Users only have direct access to the login node, which has more limited features and should not be used for computing. \\ 
 +All nodes are interconnected by a 10Gb network. \\ 
 +There is distributed storage accessible from all nodes with 220 TB of capacity connected by a dual 25Gb fibre network. \\
  
-===== Quick usage instructions ===== +\\ 
----------------- +^  Name                    ^  Model      ^  Processor                                     ^  Memory  ^  GPU                         ^ 
-A summary of the steps necessary to get a job done:+|  hpc-login2                |  Dell R440   |  1 x Intel Xeon Silver 4208 CPU @ 2.10GHz (8c)  |  16 GB    |  -                           | 
 +|  hpc-node[1-2]             |  Dell R740   |  2 x Intel Xeon Gold 5220 @2,2 GHz (18c)        |  192 GB   |  -                           | 
 +|  hpc-node[3-9]             |  Dell R740   |  2 x Intel Xeon Gold 5220R @2,2 GHz (24c)       |  192 GB   |  -                           | 
 +|  hpc-fat1                  |  Dell R840   |  4 x Xeon Gold 6248 @ 2.50GHz (20c)             |  1 TB     |  -                           | 
 +|  hpc-gpu[1-2]  |  Dell R740   |  2 x Intel Xeon Gold 5220 CPU @ 2.20GHz (18c)   |  192 GB   |  2x Nvidia Tesla V100S       | 
 +|  hpc-gpu3                  |  Dell R7525  |  2 x AMD EPYC 7543 @2,80 GHz (32c)              |  256 GB   |  2x Nvidia Ampere A100 40GB  | 
 +|  hpc-gpu4                  |  Dell R7525  |  2 x AMD EPYC 7543 @2,80 GHz (32c)              |  256 GB   |  1x Nvidia Ampere A100 80GB  |
  
-  - [[ es:centro:servizos:hpc:acceso_al_cluster | Log into the cluster and copy the necessary files.]] +===== Accessing the cluster ===== 
-  - [[ es:centro:servizos:hpc:escribir_script | Prepare the job for submission to the queue manager.]] +To access the cluster, access must be requested in advance via [[https://citius.usc.es/uxitic/incidencias/add|incident form]]. Users who do not have access permission will receive an "incorrect password" message.
-  - [[ es:centro:servizos:hpc:envio_trabajo | Submit and manage the job in the queue manager.]]+
  
 +The access is done through an SSH connection to the login node:
 +<code bash>
 +ssh <nombre_de_usuario>@hpc-login2.inv.usc.es
 +</code>
  
 +=====  Storage, directories and filesystems  =====
 +<note warning> None of the file systems in the cluster are backed up!!!</note>
 +The HOME of the users in the cluster is on the file share system, so it is accessible from all nodes in the cluster. Path defined in the environment variable %%$HOME%%. \\
 +Each node has a local 1TB scratch partition, which is deleted at the end of each job. It can be accessed through the %%$LOCAL_SCRATCH%% environment variable in the scripts. \\
 +For data to be shared by groups of users, you must request the creation of a folder in the shared storage that will only be accessible by members of the group.\\
 +^  Directory        ^  Variable               ^  Mount point             ^  Capacity  ^
 +|  Home              |  %%$HOME%%              |  /mnt/beegfs/home/<username>  |  220 TB*    |
 +|  local Scratch      |  %%$LOCAL_SCRATCH%%     |  varía                        |  1 TB       |
 +|  Group folder  |  %% $GRUPOS/<nombre>%%  |  /mnt/beegfs/groups/<nombre>  |  220 TB*    |
 +%%* storage is shared %%
 +=== WARNING ===
 +The file share system performs poorly when working with many small files. To improve performance in such scenarios, create a file system in an image file and mount it to work directly on it. The procedure is as follows:
 +  * Create the image file at your home folder:
 +<code bash>
 +## truncate image.name -s SIZE_IN_BYTES
 +truncate example.ext4 -s 20G
 +</code>
 +  *  Create a filesystem in the image file:
 +<code bash>
 +## mkfs.ext4 -T small -m 0 image.name
 +## -T small optimized options for small files
 +## -m 0 Do not reserve capacity for root user 
 +mkfs.ext4 -T small -m 0 example.ext4
 +</code>
 +  * Mount the image (using SUDO) with the script  //mount_image.py// :
 +<code bash>
 +## By default it is mounted at /mnt/imagenes/<username>/ in read-only mode.
 +sudo mount_image.py example.ext4
 +</code>
 +  * To unmount the image use the script //umount_image.py// (using SUDO)
  
-===== Introduction ===== +The mount script has this options: 
-------------- +<code> 
-High Performance Computing (HPC from now on) infrastructures offer CITIUS researchers a platform to resolve problems with high computational requirements. A computational cluster is an set of nodes interconnected by a dedicated network that can act as a single computational element. This offers a huge computational power (allowing the execution of a big parallel job or several concurrent small executions) in a shared infrastructure.+--mount-point path   <-- (optional) This option creates subdirectories under /mnt/imagenes/<username>/<path>  
 +--rw                  <-- (optional) By default it is mounted readonly, with this option it is mounted readwrite. 
 +</code> 
 +<note warning> Do not mount the image file readwrite from more than one node!!!</note>
  
-A queue management system is a program that plans how and when jobs will execute using the available computational resources.  Allows for an efficient use of computational resources in systems with multiple users. In the our cluster we use PBS/TORQUE.+The unmounting script has this options: 
 +<code>only supports as an optional parameter the same path you have used when mounting with the option  
 +--mount-point  <-- (optional) 
 +</code> 
 +=====  Transference of files and data  ===== 
 +=== SCP === 
 +From your local machine to the cluster: 
 +<code bash> 
 +scp filename <username>@hpc-login2:/<path> 
 +</code> 
 +From the cluster to your local machine: 
 +<code bash> 
 +scp filename <username>@<hostname>:/<path> 
 +</code> 
 +[[https://man7.org/linux/man-pages/man1/scp.1.html | SCP man page]] 
 +=== SFTP === 
 +To transfer several files or to navigate through the filesystem. 
 +<code bash> 
 +<hostname>:~$ sftp <user_name>@hpc-login2 
 +sftp> 
 +sftp> ls 
 +sftp> cd <path> 
 +sftp> put <file> 
 +sftp> get <file> 
 +sftp> quit 
 +</code> 
 +[[https://www.unix.com/man-page/redhat/1/sftp/ | SFTP man page]] 
 +=== RSYNC === 
 +[[ https://rsync.samba.org/documentation.html | RSYNC documentation ]] 
 +=== SSHFS === 
 +Requires local installation of the sshfs package.\\ 
 +Allows for example to mount the user's local home in hpc-login2: 
 +<code bash> 
 +## Mount 
 +sshfs  <username>@ctdeskxxx.inv.usc.es:/home/<username> <mount_point> 
 +## Unmount 
 +fusermount -u <mount_point> 
 +</code> 
 +[[https://linux.die.net/man/1/sshfs | SSHFS man page]]
  
-The way these systems work is: +===== Available Software ===== 
-        - The user requests some resources to the queue manager for a computational task. This task is a set of instructions written in a script. +All nodes have the basic software that is installed by default in AlmaLinux 8.4, in particular: 
-        - The queue manager assigns the request to one of its queues. +  * GCC 8.5.0 
-        - When the requested resources are available and depending on the priorities established by the system, the queue manager executes the task and stores the output.+  * Python 3.6.8 
 +  * Perl 5.26.3 
 +GPU nodes, in addition: 
 +  * nVidia Driver 510.47.03 
 +  * CUDA 11.6 
 +  * libcudnn 8.7 
 +To use any other software not installed on the system or another version of the system, there are three options: 
 +  - Use Modules with the modules that are already installed (or request the installation of a new module if it is not available). 
 +  - Use a container (uDocker or Apptainer/Singularity) 
 +  - Use Conda 
 +A module is the simplest solution for using software without modifications or difficult to satisfy dependencies.\\ 
 +A container is ideal when dependencies are complicated and/or the software is highly customised. It is also the best solution if you are looking for reproducibility, ease of distribution and teamwork.\\ 
 +Conda is the best solution if you need the latest version of a library or program or packages not otherwise available.\\
  
-It is important to note that the request and the execution of a given task are independent actions that are not resolved atomically. In fact it is usual that the execution of the task has to wait in one of the queues until the requested resources are available. Also, interactive use is impossible.+==== Modules/Lmod use==== 
 +[[ https://lmod.readthedocs.io/en/latest/010_user.html | Lmod documentation]] 
 +<code bash> 
 +# See available modules: 
 +module avail 
 +# Module load: 
 +module <module_name> 
 +# Unload a module: 
 +module unload <module_name> 
 +# List modules loaded in your environment: 
 +module list 
 +# ml can be used as a shorthand of the module command: 
 +ml avail 
 +# To get info of a module: 
 +ml spider <module_name> 
 +</code>
  
-==== Hardware description ====+==== Software containers execution ==== 
 +=== uDocker ==== 
 +[[ https://indigo-dc.gitbook.io/udocker/user_manual | uDocker manual ]] \\ 
 +udocker is installed as a module, so it needs to be loaded into the environment: 
 +<code bash> 
 +ml uDocker 
 +</code>
  
-Ctcomp2 is a heterogeneous cluster, composed of 8 HP Proliant BL685c G7, 5 Dell PowerEdge M910 and 5 Dell PowerEdge M620 nodes. +=== Apptainer/Singularity === 
-  * Each HP Proliant node has 4 AMD Opteron 6262 HE (16 cores) processors and 256 GB RAM(except node1 and the master with 128GB).  +[[ https://sylabs.io/guides/3.8/user-guide/ | Apptainer/Singularity documentation]] \\ 
-  * Each Dell PowerEdge M910 node has 2  Intel Xeon L7555 (8 cores, 16 threads) processors and 64 GB RAM.  +Apptainer/Singularity is installed on each node's system, so you don't need to do anything to use it.
-  * Each Dell PowerEdge M620 node has 2 Intel Xeon E5-2650L (8 cores, 16 threads) processors and 64 GB RAM.  +
-  * Connection with the cluster is made at 1Gb but nodes are connected between them by several 10 GbE networks. +
  
  
-==== Software description ==== +==== CONDA ==== 
-La gestión de los trabajos en el clúster se realiza a través del sistema de colas PBS/Torque. Para mejorar la eficiencia energética del cluster se utiliza un sistema de encendido y apagado de nodos bajo demanda llamado CLUES.+[[ https://docs.conda.io/en/latest/miniconda.html | Conda Documentation ]] \\ 
 +Miniconda is the minimal version of Anaconda and only includes the conda environment manager, Python and a few necessary packages. From there on, each user only downloads and installs the packages they need. 
 +<code bash> 
 +# Getting miniconda 
 +wget https://repo.anaconda.com/miniconda/Miniconda3-py39_4.11.0-Linux-x86_64.sh 
 +# Install  
 +sh Miniconda3-py39_4.11.0-Linux-x86_64.sh 
 +#  Initialize for bash shell 
 +~/miniconda3/bin/conda init bash 
 +</code>
  
-  * [[http://docs.adaptivecomputing.com/maui/index.php|MAUI 3.3.1]] +===== Using SLURM ===== 
-  * [[http://docs.adaptivecomputing.com/torque/4-1-7/help.htm|Torque 4.1.3]] +The cluster queue manager is[[ https://slurm.schedmd.com/documentation.html | SLURM ]]. \\ 
-  * [[http://www.grycap.upv.es/clues/eng/index.php|CLUES 0.88]]+<note tip>The term CPU identifies a physical core in a socket. Hyperthreading is disabled, so each node has as many CPUs available as (number of sockets) * (number of physical cores per socket) it has.</note> 
 +== Available resources == 
 +<code bash> 
 +hpc-login2 ~]# ver_estado.sh 
 +============================================================================================================= 
 +  NODO     ESTADO                        CORES EN USO                           USO MEM     GPUS(Uso/Total) 
 +============================================================================================================= 
 + hpc-fat1    up   0%[--------------------------------------------------]( 0/80) RAM:  0%     --- 
 + hpc-gpu1    up   2%[||------------------------------------------------]( 1/36) RAM: 47%   V100S (1/2) 
 + hpc-gpu2    up   2%[||------------------------------------------------]( 1/36) RAM: 47%   V100S (1/2) 
 + hpc-gpu3    up   0%[--------------------------------------------------]( 0/64) RAM:  0%   A100_40 (0/2) 
 + hpc-gpu4    up   1%[|-------------------------------------------------]( 1/64) RAM: 35%   A100_80 (1/1) 
 + hpc-node1   up   0%[--------------------------------------------------]( 0/36) RAM:  0%     --- 
 + hpc-node2   up   0%[--------------------------------------------------]( 0/36) RAM:  0%     --- 
 + hpc-node3   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node4   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node5   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node6   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node7   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node8   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node9   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 +============================================================================================================= 
 +TOTALES: [Cores : 3/688] [Mem(MB): 270000/3598464] [GPU: 3/ 7] 
 +hpc-login2 ~]$ sinfo -e -o "%30N  %20c  %20m  %20f  %30G " --sort=N 
 +# There is an alias for that command: 
 +hpc-login2 ~]$ ver_recursos 
 +NODELIST                        CPUS                  MEMORY                AVAIL_FEATURES        GRES                            
 +hpc-fat1                        80                    1027273               cpu_intel             (null)                          
 +hpc-gpu[1-2]                    36                    187911                cpu_intel             gpu:V100S:2                     
 +hpc-gpu3                        64                    253282                cpu_amd               gpu:A100_40:2                   
 +hpc-gpu4                        64                    253282                cpu_amd               gpu:A100_80:1(S:0)              
 +hpc-node[1-2]                   36                    187645                cpu_intel             (null)                          
 +hpc-node[3-9]                   48                    187645                cpu_intel             (null)
  
-===== Colas de usuario ===== +# To see current resource use: (CPUS (Allocated/Idle/Other/Total)) 
--------------+hpc-login2 ~]$ sinfo -N -r -O NodeList,CPUsState,Memory,FreeMem,Gres,GresUsed 
 +# There is an alias for that command: 
 +hpc-login2 ~]$ ver_uso 
 +NODELIST            CPUS(A/I/O/T)       MEMORY              FREE_MEM            GRES                GRES_USED 
 +hpc-fat1            80/0/0/80           1027273             900850              (null)              gpu:0,mps:0 
 +hpc-gpu3            2/62/0/64           253282              226026              gpu:A100_40:2       gpu:A100_40:2(IDX:0- 
 +hpc-gpu4            1/63/0/64           253282              244994              gpu:A100_80:1(S:0)  gpu:A100_80:1(IDX:0) 
 +hpc-node1           36/0/0/36           187645              121401              (null)              gpu:0,mps:0 
 +hpc-node2           36/0/0/36           187645              130012              (null)              gpu:0,mps:0 
 +hpc-node3           36/12/0/48          187645              126739              (null)              gpu:0,mps:0 
 +hpc-node4           36/12/0/48          187645              126959              (null)              gpu:0,mps:0 
 +hpc-node5           36/12/0/48          187645              128572              (null)              gpu:0,mps:0 
 +hpc-node6           36/12/0/48          187645              127699              (null)              gpu:0,mps:0 
 +hpc-node7           36/12/0/48          187645              127002              (null)              gpu:0,mps:0 
 +hpc-node8           36/12/0/48          187645              128182              (null)              gpu:0,mps:0 
 +hpc-node9           36/12/0/48          187645              127312              (null)              gpu:0,mps:0 
 +</code> 
 +==== Nodes ==== 
 +A node is SLURM's computation unit and corresponds to a physical server. 
 +<code bash> 
 +# Show node info: 
 +hpc-login2 ~]$ scontrol show node hpc-node1 
 +NodeName=hpc-node1 Arch=x86_64 CoresPerSocket=18  
 +   CPUAlloc=0 CPUTot=36 CPULoad=0.00 
 +   AvailableFeatures=cpu_intel 
 +   ActiveFeatures=cpu_intel 
 +   Gres=(null) 
 +   NodeAddr=hpc-node1 NodeHostName=hpc-node1 Version=21.08.6 
 +   OS=Linux 4.18.0-305.el8.x86_64 #1 SMP Wed May 19 18:55:28 EDT 2021  
 +   RealMemory=187645 AllocMem=0 FreeMem=166801 Sockets=2 Boards=1 
 +   State=IDLE ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A 
 +   Partitions=defaultPartition  
 +   BootTime=2022-03-01T13:13:56 SlurmdStartTime=2022-03-01T15:36:48 
 +   LastBusyTime=2022-03-07T14:34:12 
 +   CfgTRES=cpu=36,mem=187645M,billing=36 
 +   AllocTRES= 
 +   CapWatts=n/a 
 +   CurrentWatts=0 AveWatts=0 
 +   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s 
 +</code> 
 +==== Partitions ==== 
 +Partitions in SLURM are logical groups of nodes. In the cluster there is a single partition to which all nodes belong, so it is not necessary to specify it when submitting jobs. 
 +<code bash> 
 +# Show partition info: 
 +hpc-login2 ~]$ sinfo 
 +defaultPartition*    up   infinite     11   idle hpc-fat1,hpc-gpu[1-4],hpc-node[1-9] 
 +</code> 
 +==== Jobs ==== 
 +Jobs in SLURM are resource allocations to a user for a given time. Jobs are identified by a sequential number or JOBID. \\ 
 +A JOB consists of one or more STEPS, each consisting of one or more TASKS that use one or more CPUs. There is one STEP for each program that executes sequentially in a JOB and there is one TASK for each program that executes in parallel. Therefore in the simplest case such as launching a job consisting of executing the hostname command the JOB has a single STEP and a single TASK.
  
-El sistema PBS del clúster ''ctcomp2'' tiene cuatro colas de usuario y ocho colas de sistema. Las colas de usuario son en realidad colas //routing// que determinan, en función del número de núcleos computacionales solicitados, la cola de sistema en la que debe  ejecutarse cada trabajo. Los usuarios deben enviar sus trabajos a las colas de usuario, ya que no pueden enviar trabajos directamente a las colas de sistema.+==== Queue system (QOS) ==== 
 +The queue to which each job is submitted defines the priority, the limits and also the relative "cost" to the user. 
 +<code bash> 
 +# Show queues 
 +hpc-login2 ~]$ sacctmgr show qos 
 +# There is an alias that shows only the relevant info: 
 +hpc-login2 ~]$ ver_colas 
 +      Name    Priority                                  MaxTRES     MaxWall            MaxTRESPU MaxJobsPU MaxSubmitPU  
 +----------  ---------- ---------------------------------------- ----------- -------------------- --------- -----------  
 +   regular         100                cpu=200,gres/gpu=1,node=4  4-04:00:00       cpu=200,node=4        10          50  
 +interactive        200                                   node=1    04:00:00               node=1         1           1  
 +    urgent         300                        gres/gpu=1,node=1    04:00:00               cpu=36         5          15  
 +      long         100                        gres/gpu=1,node=4  8-04:00:00                              1           5  
 +     large         100                       cpu=200,gres/gpu=2  4-04:00:00                              2          10  
 +     admin         500                                                                                                  
 +     small         150                             cpu=6,node=2    04:00:00              cpu=400        40         100  
 +</code> 
 +# Priority: is the relative priority of each queue. \\ 
 +# DenyonLimit: job will not be executed if it doesn't comply with the queue limits \\ 
 +# UsageFactor: relive cost for the user to execute jobs on that queue \\ 
 +# MaxTRES: limnits applied to each job \\ 
 +# MaxWall: maximum time the job can run \\ 
 +# MaxTRESPU: global limits per user \\ 
 +# MaxJobsPU: Maximum number of jobs a user can have running simultaneously. \\ 
 +# MaxSubmitPU: Maximum number of jobs that a user can have in total both queued and running.\\ 
 +  
 +==== Sending a job to the queue system ==== 
 +== Requesting resources == 
 +By default, if you submit a job without specifying anything, the system submits it to the default (regular) QOS and assigns it a node, a CPU and 4 GB. The time limit for job execution is that of the queue (4 days and 4 hours).  
 +This is very inefficient, the ideal is to specify as much as possible at least three parameters when submitting jobs: 
 +  -  %%Node number (-N or --nodes), tasks (-n or --ntasks) and/or CPUs per task (-c or --cpus-per-task).%% 
 +  -  %%Memory (--mem) per node or memory per cpu (--mem-per-cpu).%% 
 +  -  %%Job execution time ( --time )%%
  
-Independientemente del tipo de cola que se utilice para el envío de trabajos,  +In addition, it may be interesting to add the following parameters: 
-los únicos parámetros que puede solicitar el usuario son el **número de nodos**, el **número de núcleos (procesos) por nodo** y el **tiempo de ejecución**. La memoria asignada y el tiempo máximo de ejecución de un trabajo están determinados por la cola de sistema en la que se ejecute el trabajo. Los trabajos que superen estos límites durante su ejecución serán cancelados. Por lo tanto, aquellos trabajos en los que tanto la memoria como el tiempo de ejecución son críticos, se recomienda a los usuarios modificar el número de procesos solicitados (aunque realmente no se utilicen todos durante su ejecución) para que se garanticen los requisitos del trabajo. El límite máximo de trabajos por usuario y la prioridad de los trabajos es también dependiente de la cola de sistema. Se permite que los usuarios determinen el tiempo de ejecución de los trabajos ya que una estimación precisa de los tiempos de ejecución permite al sistema de colas hacer un uso eficiente de los recursos sin perturbar las prioridades establecidas. En cualquier caso, es recomendable establecer un margen de tiempo suficiente para garantizar la correcta ejecución del trabajo y evitar la cancelación del mismo.  __Para ejecutar trabajos que no se ajusten a los parámetros de las colas PBS será necesario ponerse en contacto con el responsable del clúster.__+|  -J   |  %%--job-name%%  |Job name. Default: executable name  | 
 +|  -q   |  %%--qos%%       |Name of the queue to which the job is sent. Default: regular  | 
 +|  -o   |  %%--output%%    |File or file pattern to which all standard and error output is redirected.  | 
 +|       |  %%--gres%%      |Type and/or number of GPUs requested for the job.   | 
 +|  -C   |  %%--constraint%%  |Para especificar que se quieren nodos con procesadores Intel o AMD (cpu_intel o cpu_amd)  | 
 +|    |  %%--exclusive%%  |To specify that you want nodes with Intel or AMD processors (cpu_intel or cpu_amd)  | 
 +|  -w  |  %%--nodelist%%   |List of nodes to run the job on  |
  
 +== How resources are allocated ==
 +The default allocation method between nodes is block allocation (all available cores on a node are allocated before using another node). The default allocation method within each node is cyclic allocation (the required cores are distributed equally among the available sockets in the node). 
  
-Las colas de usuario son ''batch'', ''short'', ''bigmem'' e ''interactive''. +== Priority calculation == 
-  *  ''batch''. Es la cola por defecto.((Si no se especifica una cola particular, mediante la opción ''-q'' del comando ''qsub'', el trabajo se asignará a la cola ''batch''.)) Admite hasta 10 trabajos por usuario. Los trabajos enviados a esta cola podrán ejecutarse en cualquier cola de sistema.+When a job is submitted to the queuing system, the first thing that happens is that the requested resources are checked to see if they fall within the limits set in the corresponding queue. If it exceeds any of them, the submission is cancelled. \\ 
 +If resources are available, the job is executed directly, but if not, it is queued. Each job is assigned a priority that determines the order in which the jobs in the queue are executed when resources are available. To determine the priority of each job, 3 factors are weighted: the time it has been waiting in the queue (25%), the fixed priority of the queue (25%) and the user's fairshare (50%). \\ 
 +The fairshare is a dynamic calculation made by SLURM for each user and is the difference between the resources allocated and the resources consumed over the last 14 days. 
 +<code bash> 
 +hpc-login2 ~]$ sshare -l  
 +      User  RawShares  NormShares    RawUsage   NormUsage   FairShare  
 +---------- ---------- ----------- ----------- -----------  ----------  
 +                         1.000000     2872400                0.500000  
 +                    1    0.500000     2872400    1.000000    0.250000  
 +user_name         100    0.071429        4833    0.001726    0.246436 
 +</code> 
 +# RawShares: Is the amount of resources allocated to the user in absolute terms . It is the same for all users.\\ 
 +# NormShares: This is the above amount normalised to the total allocated resources.\\ 
 +# RawUsage: The number of seconds/cpu consumed by all user jobs.\\ 
 +# NormUsage: RawUsage normalised to total seconds/cpu consumed in the cluster.\\ 
 +# FairShare: The FairShare factor between 0 and 1. The higher the cluster usage, the closer to 0 and the lower the priority.\\
  
-  *  ''short''. Es una cola diseñada para disminuir el tiempo de espera de trabajos que no sean muy costosos temporalmente (máximo 12 horas) y que no consuman muchos recursos (menos de 16 núcleos computacionales). La cola ''short'' tiene una mayor prioridad que la cola ''batch'' y admite hasta 40 trabajos por usuario. Los trabajos enviados a esta cola solo pueden ejecutarse en un subconjunto de las colas de sistema: ''np16'', ''np8'', ''np4'', ''np2'' y ''np1''. Para solicitar la ejecución de un trabajo en la cola ''short'' es necesario indicarlo explícitamente con la opción ''-q'' del comando ''qsub'':   +== Job submission == 
-<code> +  - sbatch 
-ct$ qsub -q short script.sh +  - salloc 
 +  - srun 
 + 
 +1. SBATCH \\ 
 +Used to send a script to the queuing system. It is batch-processing and non-blocking. 
 +<code bash> 
 +# Crear el script: 
 +hpc-login2 ~]$ vim test_job.sh 
 +    #!/bin/bash 
 +    #SBATCH --job-name=test              # Job name 
 +    #SBATCH --nodes=1                    # -N Run all processes on a single node    
 +    #SBATCH --ntasks=1                   # -n Run a single task    
 +    #SBATCH --cpus-per-task=1            # -c Run 1 processor per task        
 +    #SBATCH --mem=1gb                    # Job memory request 
 +    #SBATCH --time=00:05:00              # Time limit hrs:min:sec 
 +    #SBATCH --qos=urgent                 # Queue 
 +    #SBATCH --output=test%j.log          # Standard output and error log 
 + 
 +    echo "Hello World!" 
 + 
 +hpc-login2 ~]$ sbatch test_job.sh 
 </code> </code>
-  *  ''bigmem''. Es una cola diseñada para trabajos que consuman mucha memoria. Esta cola reservará un nodo de 64 núcleos completo para el trabajo del usuario, por lo que se deben indicar ''nodes=1:ppn=64'' en la opción ''-l'' de ''qsub''. Esta cola tiene una mayor prioriodad que la cola ''batch'' y está limitada a dos trabajos por usuario. Para solicitar la ejecución de un trabajo en la cola ''bigmem'' es necesario indicarlo explícitamente con la opción ''-q'' del comando ''qsub'':   +2. SALLOC \\ 
-<code> +It is used to immediately obtain an allocation of resources (nodes). As soon as it is obtained, the specified command or a shell is executed.  
-ct$ qsub -q bigmem script.sh +<code bash> 
 +# Get 5 nodes and launch a job. 
 +hpc-login2 ~]$ salloc -N5 myprogram 
 +# Get interactive access to a node (Press Ctrl+D to exit): 
 +hpc-login2 ~]$ salloc -N1  
 +# Get interactive EXCLUSIVE access to a node 
 +hpc-login2 ~]$ salloc -N1 --exclusive
 </code> </code>
-  *  ''interactive''. Esta cola es la única que admite sesiones interactivas en los nodos computacionales. En esta cola solo se admite un trabajo por usuario, con un tiempo máximo de ejecución de 1 hora y se tendrá acceso a un único núcleo de un nodo computacional. La utilización de la cola ''interactive'' no requiere un //script//, pero es necesario indicar la interactividad de nuestro trabajo a través de la opción ''-I'': +3. SRUN \\ 
-<code> +It is used to launch a parallel job (preferable to using mpirun). It is interactive and blocking. 
-ct$ qsub -q interactive -I+<code bash> 
 +# Launch the hostname command on 2 nodes 
 +hpc-login2 ~]$ srun -N2 hostname 
 +hpc-node1 
 +hpc-node2
 </code> </code>
  
  
-Las colas de sistema son  ''np1'', ''np2'', ''np4'', ''np8'', ''np16'', ''np32'', ''np64'' y ''parallel''. +==== GPU use ==== 
-  *  ''np1''. Trabajos que requieren 1 proceso y 1 nodo. La memoria asociada a los trabajos de esta cola es 1,99 GB y el tiempo máximo de ejecución 672 horas. +To specifically request a GPU allocation for a job, options must be added to sbatch or srun:  
-  *  ''np2''. Trabajos que requieren 2 procesos. La memoria asociada a los trabajos de esta cola es 3,75 GB y el tiempo máximo de ejecución 192 horas. +|  %%--gres%%  |  Request gpus per NODE  |  %%--gres=gpu[[:type]:count],...%%  | 
-  *  ''np4''. Trabajos que requieren 4 procesos. La memoria asociada a los trabajos de esta cola es 7,5 GB y el tiempo máximo de ejecución 192 horas. +|  %%--gpus o -G%%  |  Request gpus per JOB  |  %%--gpus=[type]:count,...%%  | 
-  *  ''np8''. Trabajos que requieren 8 procesos y, como máximo, 5 nodos. La memoria asociada a los trabajos de esta cola es 15 GB y el tiempo máximo de ejecución 192 horas. +There are also the options %% --gpus-per-socket,--gpus-per-node y --gpus-per-task%%,\\ 
-  *  ''np16''. Trabajos que requieren 16 procesos y, como máximo, 5 nodos. La memoria asociada a los trabajos de esta cola es 31 GB y el tiempo máximo de ejecución 192 horas. +Ejemplos: 
-  *  ''np32''. Trabajos que requieren 32 procesos y, como máximo, 5 nodos. La memoria asociada a los trabajos de esta cola es 63 GB y el tiempo máximo de ejecución 288 horas. +<code bash> 
-  *  ''np64''. Trabajos que requieren 64 procesos y, como máximo, 5 nodos. La memoria asociada a los trabajos de esta cola es 127 GB y el tiempo máximo de ejecución 384 horas. +## See the list of nodes and gpus: 
-  *  ''parallel''. Trabajos que requieren más de 32 procesos en, al menos, 2 nodos diferentes. La memoria asociada a los trabajos de esta cola es 64 GB y el tiempo máximo de ejecución 192 horas.+hpc-login2 ~]$ ver_recursos 
 +## Request any 2 GPUs for a JOB, add: 
 +--gpus=2 
 +## Request a 40G A100 at one node and an 80G A100 at another node, add: 
 +--gres=gpu:A100_40:1,gpu:A100_80:1  
 +</code>
  
  
 +==== Job monitoring ====
 +<code bash>
 +## List all jobs in the queue
 +hpc-login2 ~]$ squeue
 +## Listing a user's jobs            
 +hpc-login2 ~]$ squeue -u <login>
 +## Cancel a job:
 +hpc-login2 ~]$ scancel <JOBID>
 +## List of recent jobs:
 +hpc-login2 ~]$ sacct -b
 +## Detailed historical information for a job:
 +hpc-login2 ~]$ sacct -l -j <JOBID>
 +## Debug information of a job for troubleshooting:
 +hpc-login2 ~]$ scontrol show jobid -dd <JOBID>
 +## View the resource usage of a running job:
 +hpc-login2 ~]$ sstat <JOBID>
 +</code>
 +==== Configure job output ====
 +== Exit codes ==
 +By default these are the output codes of the commands:
 +^  SLURM command  ^  Exit code  ^
 +|  salloc  |  0 success, 1 if the user's command cannot be executed  |
 +|  srun  |  The highest among all executed tasks or 253 for an out-of-mem error.  |
 +|  sbatch  |  0 success, if not, the corresponding exit code of the failed process  |
  
 +== STDIN, STDOUT y STDERR ==
 +**SRUN:**\\
 +By default stdout and stderr are redirected from all TASKS to srun's stdout and stderr, and stdin is redirected from srun's stdin to all TASKS. This can be changed with:
 +|  %%-i, --input=<option>%%    | 
 +|  %%-o, --output=<option>%%   |
 +|  %%-e, --error=<option>%%   |
 +And options are:
 +  * //all//: by default.
 +  * //none//: Nothing is redirected.
 +  * //taskid//: Redirects only to and/or from the specified TASK id.
 +  * //filename//: Redirects everything to and/or from the specified file.
 +  * //filename pattern//: Same as the filename option but with a file defined by a [[ https://slurm.schedmd.com/srun.html#OPT_filename-pattern | pattern ]].
  
-La siguiente tabla resume las características de las colas de usuario y de sistema del clúster ''ctcomp2'':+**SBATCH:**\\ 
 +By default "/dev/null" is open in the script's stdin and stdout and stderror are redirected to a file named "slurm-%j.out". This can be changed with: 
 +|  %%-i, --input=<filename_pattern>%%  | 
 +|  %%-o, --output=<filename_pattern>%%  | 
 +|  %%-e, --error=<filename_pattern>%%  | 
 +The reference of filename_pattern is [[ https://slurm.schedmd.com/sbatch.html#SECTION_%3CB%3Efilename-pattern%3C/B%3E | here ]].
  
-^ Cola             ^ Límites                                                                                                                   |||||| +==== Sending mail ==== 
-| :::              ^ Procesos  ^ Nodos  ^ Memoria (GB)  ^ Trabajos/usuario  ^ Tiempo máximo (horas)  ^ Prioridad((Mayor número = mayor prioridad))  ^ +JOBS can be configured to send mail in certain circumstances using these two parameters (**BOTH ARE REQUIRED**): 
-| ''batch''        |      1-64 | -      | -             | 128               | -                      | 1                                            | +|  %%--mail-type=<type>%%  |  Options: BEGIN, END, FAIL, REQUEUE, ALL, TIME_LIMIT, TIME_LIMIT_90, TIME_LIMIT_50.  | 
-| ''short''        |      1-16 | -      | -             | 256               | -                      | 3                                            | +|  %%--mail-user=<user>%%  |  The destination mailing address.  | 
-| ''bigmem''       |        64 | -      | -             | 8                 | -                      | 2                                            | + 
-| ''interactive''  | 1         | 1      | 2             | 1                 | 1                      | 7                                            | + 
-| ''np1''          | 1         | 1      | 1,99          | 120               | 672                    | 6                                            | + 
-| ''np2''          | 2         | 2      | 3,75          | 120               | 192                    | 5                                            | +==== Status of Jobs in the queuing system ==== 
-| ''np4''          | 4         | 4      | 7,5           | 60                | 192                    | 4                                            | +<code bash> 
-| ''np8''          | 8         | 5      | 15            | 60                | 192                    | 4                                            | +hpc-login2 ~]# squeue -l 
-| ''np16''         | 16        | 5      | 31            | 15                | 192                    | 3                                            | +JOBID PARTITION     NAME     USER      STATE       TIME  NODES NODELIST(REASON) 
-| ''np32''         | 32        | 5      | 63            | 15                | 288                    | 2                                            | +6547  defaultPa  example <username>  RUNNING   22:54:55      1 hpc-fat1 
-| ''np64''         | 64        | 5      | 127           | 3                 | 384                    | 1                                            | + 
-| ''parallel''     | 32-160    | 5      | 64            | 15                | 192                    | 3                                            |+## Check status of queue use: 
 +hpc-login2 ~]$ estado_colas.sh 
 +JOBS PER USER: 
 +-------------- 
 +       usuario.uno:  3 
 +       usuario.dos:  1 
 + 
 +JOBS PER QOS: 
 +-------------- 
 +             regular:  3 
 +                long:  1 
 + 
 +JOBS PER STATE: 
 +-------------- 
 +             RUNNING:  3 
 +             PENDING:  1 
 +========================================== 
 +Total JOBS in cluster:  4 
 +</code> 
 +Common job states: 
 +  * R RUNNING Job currently has an allocation. 
 +  * CD COMPLETED Job has terminated all processes on all nodes with an exit code of zero.  
 +  * F FAILED Job terminated with non-zero exit code or other failure condition. 
 +  * PD PENDING Job is awaiting resource allocation. 
 +  
 +[[ https://slurm.schedmd.com/squeue.html#SECTION_JOB-STATE-CODES | Full list of possible job statuses ]].\\
  
 +If a job is not running, a reason will be displayed underneath REASON:[[ https://slurm.schedmd.com/squeue.html#SECTION_JOB-REASON-CODES | reason list ]] for which a job may be awaiting execution.
  
-  * Procesos: Número máximo de procesos por trabajo en esta cola. 
-  * Nodos: Número máximo de nodos en los que se ejecutará el trabajo en esta cola. 
-  * Memoria: Cantidad de memoria virtual máxima usada de modo concurrente por todos los procesos del trabajo. 
-  * Trabajos/usuario: Número máximo de trabajos por usuario en esta cola. Es independiente del estado de dichos trabajos. 
-  * Tiempo máximo (horas): tiempo real máximo durante el que el trabajo puede estar en ejecución. 
-  * Prioridad: Prioridad de la cola de ejecución frente a las otras. Un valor más alto expresa una mayor prioridad. Nótese que esto implica que ante la falta de otros criterios, cualquier trabajo enviado con qsub sin definir parámetros se ejecutará en np1 con los límites de dicha cola.