NLHPC - Contribuciones del usuario [es]

Tutorial de acceso a Leftraru via SSH

2026-04-15T18:54:08Z

Administrador:

== Accediendo desde un equipo Linux o Mac OSX ==
Para realizar una conexión desde un sistema GNU/Linux o MacOSX, use el comando SSH (ejemplo con usuario "prueba") e indicar el uso del puerto '''4603'''.

Por ejemplo, el usuario Dave Bowman (nombre de usuario ''dbowman'') accede al clúster ejecutando:
<pre>
$ ssh -p 4603 dbowman@leftraru.nlhpc.cl
dbowman@leftraru.nlhpc.cl password:

[...]

dbowman@leftraru2:~$
</pre>

=== Guardar información de la sesión ===

Es posible almacenar los datos de conexión bajo el archivo '''~/.ssh/config''', lo que nos otorgará un poco más de flexibilidad a la hora de conectarnos.

Por ejemplo, el usuario Dave Bowman edita el archivo mencionado con:

<pre>
vi ~/.ssh/config
</pre>

y agrega la siguiente información:

<pre>
Host leftraru
Hostname leftraru.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no
</pre>

El parámetro '''Host''' indica el valor '''leftraru''' como nombre de conexión. Este valor podrá ser utilizado directamente con el comando '''ssh'''.

El valor '''Hostname''' indica la dirección a la cual nos queremos conectar (puedes indicar una IP si así lo deseas).

Los parámetros '''User''' y '''Port''' ya los hemos visto.

Y por último el parámetro '''UpdateHostKeys''' indica si deberá aceptar o no los cambios de llaves en el servidor. Por seguridad se recomienda el valor '''no'''.

Una vez que se edito esta información, nuestro usuario podrá acceder al clúster con tan solo escribir el comando:

<pre>ssh leftraru</pre>

==== Es posible tener una gran cantidad de entradas en nuestro archivo .ssh/config ====

Un ejemplo del archivo de configuración con más cantidad de entradas sería similar a:

<pre>
Host leftraru
Hostname leftraru.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host l1
Hostname leftraru1.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host l2
Hostname leftraru2.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host HAL
Hostname 127.0.0.1
User dbwoman
Port 9000
UpdateHostKeys no
...
</pre>

Con dicha configuración, el usuario podría acceder usando uno de los siguientes comandos:

<pre>
ssh l1
ssh l2
</pre>

== Accediendo desde un equipo Windows ==
Para conectar desde sistemas Windows, se recomienda usar Putty como cliente SSH.

Como vemos en el ejemplo se indican los campos:

* Hostname: dbowman@leftraru.nlhpc.cl
* Puerto: 4603

[[Archivo:Putty-dbowman-hostname.png|no]]

Y se realiza la conexión haciendo ''click'' en el botón inferior ''Open''.

Si la conexión es exitosa podremos ingresar el usuario y contraseña.

En este ejemplo, es el usuario Dave Bowman (dbowman) quien intenta conectarse al clúster.

[[Archivo:Putty-dbowman-user-ssh.png|no]]

Recuerda que al momento de ingresar tu contraseña, esta no será desplegada en pantalla.

=== Guardar nuestra sesión ===

Una vez que se ingresa los valores de '''Hostname''' y '''Puerto''', es posible almacenar dicha información indicando un nombre en el campo '''Saved Sessions''' y presionando el botón '''Save''.

La próxima vez que necesitemos acceder al cluster, bastará hacer doble ''click'' sobre la sesión que necesitemos abrir.

Por ejemplo en este caso es posible ver que las siguientes sesiones están almacenadas:

<gallery>
Archivo:Putty-saved-sessions.png
</gallery>

* Default
* L1
* L2
* Leftraru

== Acceso utilizando llaves ==
La autenticación con clave pública es un método de seguridad alternativo a las contraseñas, mucho más difícil de hackear y, por lo tanto, más seguro. Este método de autenticación es recomendable usarlo para acceder a servidores.

La clave SSH consiste en la generación de un par de claves que proporcionan dos largas cadenas de caracteres, una pública y una privada. La clave pública se instala en cualquier servidor y luego se desbloquea mediante la conexión con un cliente SSH que hace uso de la clave privada. Si las dos claves coinciden, el servidor SSH permite el acceso sin necesidad de utilizar una contraseña. No obstante, para añadir una capa de seguridad adicional, siempre podemos aumentar la protección de la clave privada usando una contraseña.

Entonces nuestro usuario Dave Bowman creará una llave en su computadora personal para copiarla en el clúster siguiendo los pasos que se indican a continuación:

<pre>
[dave@HAL ~]$ ssh-keygen -t ed25519
</pre>

Tras ejecutar el comando obtendremos la siguiente respuesta:

<pre>
Generating public/private ed25519 key pair.
</pre>

Una vez ejecutada la instrucción para generar las claves, se nos pedirá que indiquemos la ruta en la que queremos almacenar la clave:

<pre>
Enter file in which to save the key (/home/dave/.ssh/id_ed25519):
</pre>

Tras indicar la ruta en la que se almacenará la clave, lo siguiente que tendremos que hacer es indicar una contraseña (puede dejar vacío para acceso directo):

<pre>
Enter passphrase (empty for no passphrase):
</pre>

Finalmente debemos copiar nuestra llave pública al cluster:

<pre>
[dave@HAL ~] ssh-copy-id -p 4603 dbowman@leftraru.nlhpc.cl
Number of key(s) added: 1

Now try logging into the machine, with: "ssh -p '4603' 'dbowman@leftraru.nlhpc.cl'"
and check to make sure that only the key(s) you wanted were added.
</pre>

Ahora ya podremos conectarnos directamente con nuestras llaves:

<pre>
[dave@HAL ~] ssh -p 4603 dbowman@leftraru.nlhpc.cl
</pre>

=== Copiar la llave desde Windows al clúster ===

En el caso de que se utilice Windows como sistema operativo, una posibilidad de copiar la llave es ejecutando:

<pre>
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh -p 4603 dbowman@leftraru.nlhpc.cl "cat >> .ssh/authorized_keys"
</pre>

Si lo anterior no funciona, recomendamos que abra en una aplicación como NotePad el archivo '''.ssh\id_rsa.pub''' y copie el contenido al archivo en:

<pre>
nano ~/.ssh/authorized_keys
</pre>

Considere también que dependiendo de las aplicaciones utilizadas bajo Windows, este paso puede requerir de otros pasos.

Recomedamos que lea la documentación oficial de su software.

== Cambiar contraseña ==
Para cambiar la contraseña de usuario, es necesario que esta cumpla con ciertos requisitos como por ejemplo:

* El mínimo de caracteres son 10.
* Debe ser alfanumérica.
* Tener 3 caracteres especiales (al menos 1 mayúscula – 1 minúscula y 1 número).

Para ejecutar esta acción, utilice el siguiente comando:
<pre>
[dbowman@leftraru1 ~]$ passwd

Changing password for user dbowman.
(current) LDAP Password: <- Ingrese su contraseña actual.

New password: ********* <- Ingrese su nueva contraseña.

Retype new password: Reingrese su nueva contraseña.

passwd: all authentication tokens updated successfully.
</pre>

Confirmación de cambio de clave exitoso, le recomendamos cerrar su sesión e ingresar nuevamente a nuestro sistema ingresando su nueva contraseña.

=== Cambio de Contraseña vía Dashboard ===

También puede cambiar su contraseña desde nuestros [[Dashboard]] siguiendo el siguiente [[Procedimiento cambio o recuperación de contraseña]].

== Conexión a nodos actualmente utilizados ==
Algunas veces, por distintas circunstancias, sería deseable tener la posibilidad de ingresar al nodo donde se estén ejecutando nuestras tareas con tal de verificar su estado, comprobar ciertos valores, etc.

Pensado en la comodidad de los usuarios, se ha implementado un módulo del gestor que colas SLURM que permite esta funcionalidad. Por tanto, el login será permitido en todas aquellas máquinas donde actualmente exista un trabajo nuestro.

Por ejemplo; nuestra tarea de prueba 'tarea_test.sh' ha sido enviada a la cola y ha ingresado con el ID '3469576'. Slurm reservó el nodo 'cn053' para llevar a cabo la ejecución, por tanto el usuario tiene permitido el ingreso mediante ssh al nodo:

<pre>
leftraru$ sbatch tarea_test.sh
leftraru$ squeue

JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
3469576 general Prueba test R 1:57 1 sn007

leftraru$ ssh sn007
Last login: today 2016 from leftraru.nlhpc.cl
sn007$
</pre>

Tenga en cuenta que aún se mantiene la restricción de ingreso para el resto de los nodos:
<pre>
leftraru$ ssh sn001
Access denied: user test (uid=000) has no active jobs on this node.
leftraru$
</pre>

== Nodos Login ==
Aunque disponemos de 4 nodos para el acceso al clúster por parte de los usuarios, en general, hay que usar el nombre:

* leftraru.nlhpc.cl

A la hora de conectarse por SSH al clúster. Al acceder a esa dirección se consigue que los usuarios queden conectados aleatoriamente a los nodos login.

Pero si resultara necesario, se puede acceder a un nodo login específicamente usando su nombre a la hora de realizar la conexión SSH:

* leftraru1.nlhpc.cl
* leftraru2.nlhpc.cl

== Sobre nodos de acceso y uso de multiplexadores ==
Debido a que Leftraru balancea la carga de los nodos Login se debe evitar el uso de screen, ya que no se garantiza el acceso al mismo nodo que tenía la sesión screen abierta una vez que el usuario cierra su sesión.

Un usuario sólo podrá acceder por ssh a los nodos logins. En el caso de querer acceder a un nodo de cómputo, el usuario deberá tener al menos una tarea SLURM en ejecución en el nodo al cual necesite acceder, y deberá considerar que si dicha tarea finaliza, su sesión será cerrada del nodo.

'''Si falla muchas veces el intento de login por SSH o genera muchas conexiones, su IP podría ser bloqueada. Contacte por correo electrónico con Soporte indicando información relevante (más información [[Como_abrir_un_ticket#Problemas_de_acceso_al_clúster|aquí]]) si presenta problemas de conexión: ''' '''[mailto:soporte@nlhpc.cl soporte@nlhpc.cl]'''

== Ejecución de aplicaciones gráficas ==
Para poder ejecutar aplicaciones gráficas, es necesario conectarse al clúster habilitando el ''reenvío de X11'' (en inglés ''X11 Forwarding''.

Esto se consigue conectándose mediante SSH indicando los parámetros '''-X''' o '''-Y'''

ssh -p 4603 -X dbowman@leftraru.nlhpc.cl

Si ha logrado conectarse podrá ejecutar la aplicación con su interfaz gráfica:

ml ncview/2.1.7
ncview mi_archivo.nc

Si la aplicación no cuenta con interfaz gráfica podrá utilizar la línea de comandos de manera normal.

=== Para usuarios de OS X ===
Si utiliza una computadora con OS X, deberá instalar en su computadora XQuartz, disponible desde: https://www.xquartz.org/

Luego de eso podrá utilizar el comando indicado en la sección anterior.

=== Para usuarios de Windows ===
Si utiliza una computadora con Windows, deberá instalar un programa como XMing, disponible desde:http://www.straightrunning.com/XmingNotes/

Una vez instalado en su computadora, deberá activar el reenvío de X11 en su aplicación.
Por ejemplo, al momento de crear una conexión debe ir a la sección '''Conexión'''→'''SSH'''→'''X11''' y seleccionar la opción '''Enable X11 forwarding'''.

[[Archivo:X11-forwarding.png|Putty y reenvío de X11]]

== Problemas conocidos ==
=== IP bloqueada ===
Si ha ingresado su contraseña de manera equivocada en varias oportunidades, su acceso puede ser bloqueado por razones de seguridad. Favor enviar un correo a [mailto:soporte@nlhpc.cl soporte@nlhpc.cl] indicando su IP pública.

Si desconoce su IP pública puede vistar https://miip.cl o un servicio similar a su elección.

=== No logra acceder desde su lugar de trabajo ===
Pruebe conectándose a otra red.

Una prueba sencilla y rápida es compartir la conexión a Internet de su celular móvil (''hotspot'') y probar acceder al clúster.

Esta prueba permite cambiar de IP y no tener restricciones en base a las políticas de su lugar de trabajo.

Si logra conectarse de esta manera, contacte a su Administrador de Sistemas local e indíquele esta situación, haciendo especial énfasis en mencionar el puerto '''4603''' y el protocolo '''ssh'''.

=== SSH desconoce el identificador de los nodos de acceso ===
En ocasiones puede presentar problemas de acceso debido a las llaves de identificación de los servidores de acceso.

Puede probar a verificar si en su directorio personal existe el directoro '''.ssh'''.
Para los usuarios de Linux, OS X y Powershell pueden acceder simplemente con:

<pre>
cd ~/.ssh
</pre>

Dentro de dicho directorio podrá ver que existe un archivo llamado '''known_hosts'''.

Puede eliminar o renombrar dicho archivo para que en el siguiente intento de conexión se genere nuevamente.

Por ejemplo:

<pre>
cd ~/.ssh
mv known_hosts known_hosts_backup
</pre>

Luego al conectar nuevamente a '''leftraru.nlhpc.cl'''

<pre>
ssh -p 4603 dbowman@leftraru.nlhpc.cl
</pre>

se nos pedirá confirmar:

<pre>
The authenticity of host '[leftraru.nlhpc.cl]:4603 ([146.83.2.234]:4603)' can't be established.
ED25519 key fingerprint is SHA256:Murakami74f74....
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[leftraru.nlhpc.cl]:4603' (ED25519) to the list of known hosts.
</pre>

Lo anterior también lo puede ejecutar para los nodos de acceso específicos '''leftraru1.nlhpc.cl''' y '''leftraru2.nlhpc.cl'''.

==== Usuarios de Putty ====
En el caso de utilizar Putty, es necesario que abra el Registro de Windows, busque el valor ''' HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys''' y elimine los valores asociados a los servidores de acceso.

Puede buscar más información en el siguiente [https://www.google.com/search?q=putty+como+borrar+archivo+known+hosts link].

==== Otras aplicaciones ====
Dependiendo de las aplicaciones que utilice y los sistemas operativos, recomendamos que busque información sobre como eliminar las preferencias específicas de su aplicación, como también utilizar las palabras claves '''known hosts''' al buscar información específica de la herramienta que esté utilizado.

=== Error de conexión en redes institucionales (Firewall) ===
Si experimenta problemas conectándose desde su red institucional, es muy probable que el firewall local esté bloqueando el '''puerto 4603'''. Para confirmarlo, ejecute el comando correspondiente a su sistema operativo:

==== Verificación de conectividad ====

; Desde Linux / macOS:
<syntaxhighlight lang="bash">
nc -zv leftraru.nlhpc.cl 4603
</syntaxhighlight>
* '''Puerto abierto:''' Verá un mensaje similar a <code>Connection to leftraru.nlhpc.cl 4603 port [tcp/*] succeeded!</code>.
* '''Puerto bloqueado:''' Verá un error de <code>Connection refused</code> o <code>Timeout</code>.

; Desde Windows (PowerShell):
<syntaxhighlight lang="text">
Test-NetConnection -ComputerName leftraru.nlhpc.cl -Port 4603
</syntaxhighlight>
* '''Puerto abierto:''' En la última línea leerá <code>TcpTestSucceeded : True</code>.
* '''Puerto bloqueado:''' Leerá <code>TcpTestSucceeded : False</code>.

==== Resolución del problema ====

Si confirma que el acceso está restringido, debe realizar las siguientes acciones:

# '''Prueba de descarte (Hotspot):''' Conecte su equipo a una red externa, como el punto de acceso de su dispositivo móvil. Si logra conectarse exitosamente de esta manera, habrá descartado un problema con el clúster.
# '''Gestión con soporte TI:''' Con la prueba anterior como respaldo, deberá contactar con el administrador de red de su institución para solicitar la apertura del '''puerto 4603''', indicando que es necesario para la conexión al clúster del NLHPC.

=== Contraseña incorrecta ===
Puede solicitar una nueva contraseña a nuestro correo electrónico [mailto:soporte@nlhpc.cl soporte@nlhpc.cl].

Favor indicar su nombre de usuario para esto.

Recuerde que el remitente será contrastado con nuestros registros de su cuenta.

== Si necesita soporte ==

Si necesita soporte o tiene problemas de acceso escriba a '''[mailto:soporte@nlhpc.cl soporte@nlhpc.cl]''' indicando su nombre de usuario, su IP pública, aplicaciones utilizadas y los mensajes de error que haya observado.

Algunos puntos a considerar en el siguiente [https://wiki.nlhpc.cl/Como_abrir_un_ticket#Problemas_de_acceso_al_cl%C3%BAster enlace].

== Enlaces externos ==

Guía de generación de llaves SSH y su uso bajo sistema operativo Windows en el siguiente [https://chrisjhart.com/Windows-10-ssh-copy-id/ enlace].

Playlist con vídeo tutoriales en canal de [https://www.youtube.com/watch?v=mWa-1Ad1SmY&list=PL6GflPS8SOqrEeAbBKOKqhWy3y3LF_gQ6 YouTube].

Tutorial de acceso a Leftraru via SSH

2026-04-15T18:51:31Z

Administrador:

== Accediendo desde un equipo Linux o Mac OSX ==
Para realizar una conexión desde un sistema GNU/Linux o MacOSX, use el comando SSH (ejemplo con usuario "prueba") e indicar el uso del puerto '''4603'''.

Por ejemplo, el usuario Dave Bowman (nombre de usuario ''dbowman'') accede al clúster ejecutando:
<pre>
$ ssh -p 4603 dbowman@leftraru.nlhpc.cl
dbowman@leftraru.nlhpc.cl password:

[...]

dbowman@leftraru2:~$
</pre>

=== Guardar información de la sesión ===

Es posible almacenar los datos de conexión bajo el archivo '''~/.ssh/config''', lo que nos otorgará un poco más de flexibilidad a la hora de conectarnos.

Por ejemplo, el usuario Dave Bowman edita el archivo mencionado con:

<pre>
vi ~/.ssh/config
</pre>

y agrega la siguiente información:

<pre>
Host leftraru
Hostname leftraru.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no
</pre>

El parámetro '''Host''' indica el valor '''leftraru''' como nombre de conexión. Este valor podrá ser utilizado directamente con el comando '''ssh'''.

El valor '''Hostname''' indica la dirección a la cual nos queremos conectar (puedes indicar una IP si así lo deseas).

Los parámetros '''User''' y '''Port''' ya los hemos visto.

Y por último el parámetro '''UpdateHostKeys''' indica si deberá aceptar o no los cambios de llaves en el servidor. Por seguridad se recomienda el valor '''no'''.

Una vez que se edito esta información, nuestro usuario podrá acceder al clúster con tan solo escribir el comando:

<pre>ssh leftraru</pre>

==== Es posible tener una gran cantidad de entradas en nuestro archivo .ssh/config ====

Un ejemplo del archivo de configuración con más cantidad de entradas sería similar a:

<pre>
Host leftraru
Hostname leftraru.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host l1
Hostname leftraru1.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host l2
Hostname leftraru2.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host HAL
Hostname 127.0.0.1
User dbwoman
Port 9000
UpdateHostKeys no
...
</pre>

Con dicha configuración, el usuario podría acceder usando uno de los siguientes comandos:

<pre>
ssh l1
ssh l2
</pre>

== Accediendo desde un equipo Windows ==
Para conectar desde sistemas Windows, se recomienda usar Putty como cliente SSH.

Como vemos en el ejemplo se indican los campos:

* Hostname: dbowman@leftraru.nlhpc.cl
* Puerto: 4603

[[Archivo:Putty-dbowman-hostname.png|no]]

Y se realiza la conexión haciendo ''click'' en el botón inferior ''Open''.

Si la conexión es exitosa podremos ingresar el usuario y contraseña.

En este ejemplo, es el usuario Dave Bowman (dbowman) quien intenta conectarse al clúster.

[[Archivo:Putty-dbowman-user-ssh.png|no]]

Recuerda que al momento de ingresar tu contraseña, esta no será desplegada en pantalla.

=== Guardar nuestra sesión ===

Una vez que se ingresa los valores de '''Hostname''' y '''Puerto''', es posible almacenar dicha información indicando un nombre en el campo '''Saved Sessions''' y presionando el botón '''Save''.

La próxima vez que necesitemos acceder al cluster, bastará hacer doble ''click'' sobre la sesión que necesitemos abrir.

Por ejemplo en este caso es posible ver que las siguientes sesiones están almacenadas:

<gallery>
Archivo:Putty-saved-sessions.png
</gallery>

* Default
* L1
* L2
* Leftraru

== Acceso utilizando llaves ==
La autenticación con clave pública es un método de seguridad alternativo a las contraseñas, mucho más difícil de hackear y, por lo tanto, más seguro. Este método de autenticación es recomendable usarlo para acceder a servidores.

La clave SSH consiste en la generación de un par de claves que proporcionan dos largas cadenas de caracteres, una pública y una privada. La clave pública se instala en cualquier servidor y luego se desbloquea mediante la conexión con un cliente SSH que hace uso de la clave privada. Si las dos claves coinciden, el servidor SSH permite el acceso sin necesidad de utilizar una contraseña. No obstante, para añadir una capa de seguridad adicional, siempre podemos aumentar la protección de la clave privada usando una contraseña.

Entonces nuestro usuario Dave Bowman creará una llave en su computadora personal para copiarla en el clúster siguiendo los pasos que se indican a continuación:

<pre>
[dave@HAL ~]$ ssh-keygen -t ed25519
</pre>

Tras ejecutar el comando obtendremos la siguiente respuesta:

<pre>
Generating public/private ed25519 key pair.
</pre>

Una vez ejecutada la instrucción para generar las claves, se nos pedirá que indiquemos la ruta en la que queremos almacenar la clave:

<pre>
Enter file in which to save the key (/home/dave/.ssh/id_ed25519):
</pre>

Tras indicar la ruta en la que se almacenará la clave, lo siguiente que tendremos que hacer es indicar una contraseña (puede dejar vacío para acceso directo):

<pre>
Enter passphrase (empty for no passphrase):
</pre>

Finalmente debemos copiar nuestra llave pública al cluster:

<pre>
[dave@HAL ~] ssh-copy-id -p 4603 dbowman@leftraru.nlhpc.cl
Number of key(s) added: 1

Now try logging into the machine, with: "ssh -p '4603' 'dbowman@leftraru.nlhpc.cl'"
and check to make sure that only the key(s) you wanted were added.
</pre>

Ahora ya podremos conectarnos directamente con nuestras llaves:

<pre>
[dave@HAL ~] ssh -p 4603 dbowman@leftraru.nlhpc.cl
</pre>

=== Copiar la llave desde Windows al clúster ===

En el caso de que se utilice Windows como sistema operativo, una posibilidad de copiar la llave es ejecutando:

<pre>
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh -p 4603 dbowman@leftraru.nlhpc.cl "cat >> .ssh/authorized_keys"
</pre>

Si lo anterior no funciona, recomendamos que abra en una aplicación como NotePad el archivo '''.ssh\id_rsa.pub''' y copie el contenido al archivo en:

<pre>
nano ~/.ssh/authorized_keys
</pre>

Considere también que dependiendo de las aplicaciones utilizadas bajo Windows, este paso puede requerir de otros pasos.

Recomedamos que lea la documentación oficial de su software.

== Cambiar contraseña ==
Para cambiar la contraseña de usuario, es necesario que esta cumpla con ciertos requisitos como por ejemplo:

* El mínimo de caracteres son 10.
* Debe ser alfanumérica.
* Tener 3 caracteres especiales (al menos 1 mayúscula – 1 minúscula y 1 número).

Para ejecutar esta acción, utilice el siguiente comando:
<pre>
[dbowman@leftraru1 ~]$ passwd

Changing password for user dbowman.
(current) LDAP Password: <- Ingrese su contraseña actual.

New password: ********* <- Ingrese su nueva contraseña.

Retype new password: Reingrese su nueva contraseña.

passwd: all authentication tokens updated successfully.
</pre>

Confirmación de cambio de clave exitoso, le recomendamos cerrar su sesión e ingresar nuevamente a nuestro sistema ingresando su nueva contraseña.

=== Cambio de Contraseña vía Dashboard ===

También puede cambiar su contraseña desde nuestros [[Dashboard]] siguiendo el siguiente [[Procedimiento cambio o recuperación de contraseña]].

== Conexión a nodos actualmente utilizados ==
Algunas veces, por distintas circunstancias, sería deseable tener la posibilidad de ingresar al nodo donde se estén ejecutando nuestras tareas con tal de verificar su estado, comprobar ciertos valores, etc.

Pensado en la comodidad de los usuarios, se ha implementado un módulo del gestor que colas SLURM que permite esta funcionalidad. Por tanto, el login será permitido en todas aquellas máquinas donde actualmente exista un trabajo nuestro.

Por ejemplo; nuestra tarea de prueba 'tarea_test.sh' ha sido enviada a la cola y ha ingresado con el ID '3469576'. Slurm reservó el nodo 'cn053' para llevar a cabo la ejecución, por tanto el usuario tiene permitido el ingreso mediante ssh al nodo:

<pre>
leftraru$ sbatch tarea_test.sh
leftraru$ squeue

JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
3469576 general Prueba test R 1:57 1 sn007

leftraru$ ssh sn007
Last login: today 2016 from leftraru.nlhpc.cl
sn007$
</pre>

Tenga en cuenta que aún se mantiene la restricción de ingreso para el resto de los nodos:
<pre>
leftraru$ ssh sn001
Access denied: user test (uid=000) has no active jobs on this node.
leftraru$
</pre>

== Nodos Login ==
Aunque disponemos de 4 nodos para el acceso al clúster por parte de los usuarios, en general, hay que usar el nombre:

* leftraru.nlhpc.cl

A la hora de conectarse por SSH al clúster. Al acceder a esa dirección se consigue que los usuarios queden conectados aleatoriamente a los nodos login.

Pero si resultara necesario, se puede acceder a un nodo login específicamente usando su nombre a la hora de realizar la conexión SSH:

* leftraru1.nlhpc.cl
* leftraru2.nlhpc.cl

== Sobre nodos de acceso y uso de multiplexadores ==
Debido a que Leftraru balancea la carga de los nodos Login se debe evitar el uso de screen, ya que no se garantiza el acceso al mismo nodo que tenía la sesión screen abierta una vez que el usuario cierra su sesión.

Un usuario sólo podrá acceder por ssh a los nodos logins. En el caso de querer acceder a un nodo de cómputo, el usuario deberá tener al menos una tarea SLURM en ejecución en el nodo al cual necesite acceder, y deberá considerar que si dicha tarea finaliza, su sesión será cerrada del nodo.

'''Si falla muchas veces el intento de login por SSH o genera muchas conexiones, su IP podría ser bloqueada. Contacte por correo electrónico con Soporte indicando información relevante (más información [[Como_abrir_un_ticket#Problemas_de_acceso_al_clúster|aquí]]) si presenta problemas de conexión: ''' '''[mailto:soporte@nlhpc.cl soporte@nlhpc.cl]'''

== Ejecución de aplicaciones gráficas ==
Para poder ejecutar aplicaciones gráficas, es necesario conectarse al clúster habilitando el ''reenvío de X11'' (en inglés ''X11 Forwarding''.

Esto se consigue conectándose mediante SSH indicando los parámetros '''-X''' o '''-Y'''

ssh -p 4603 -X dbowman@leftraru.nlhpc.cl

Si ha logrado conectarse podrá ejecutar la aplicación con su interfaz gráfica:

ml ncview/2.1.7
ncview mi_archivo.nc

Si la aplicación no cuenta con interfaz gráfica podrá utilizar la línea de comandos de manera normal.

=== Para usuarios de OS X ===
Si utiliza una computadora con OS X, deberá instalar en su computadora XQuartz, disponible desde: https://www.xquartz.org/

Luego de eso podrá utilizar el comando indicado en la sección anterior.

=== Para usuarios de Windows ===
Si utiliza una computadora con Windows, deberá instalar un programa como XMing, disponible desde:http://www.straightrunning.com/XmingNotes/

Una vez instalado en su computadora, deberá activar el reenvío de X11 en su aplicación.
Por ejemplo, al momento de crear una conexión debe ir a la sección '''Conexión'''→'''SSH'''→'''X11''' y seleccionar la opción '''Enable X11 forwarding'''.

[[Archivo:X11-forwarding.png|Putty y reenvío de X11]]

== Problemas conocidos ==
=== IP bloqueada ===
Si ha ingresado su contraseña de manera equivocada en varias oportunidades, su acceso puede ser bloqueado por razones de seguridad. Favor enviar un correo a [mailto:soporte@nlhpc.cl soporte@nlhpc.cl] indicando su IP pública.

Si desconoce su IP pública puede vistar https://miip.cl o un servicio similar a su elección.

=== No logra acceder desde su lugar de trabajo ===
Pruebe conectándose a otra red.

Una prueba sencilla y rápida es compartir la conexión a Internet de su celular móvil (''hotspot'') y probar acceder al clúster.

Esta prueba permite cambiar de IP y no tener restricciones en base a las políticas de su lugar de trabajo.

Si logra conectarse de esta manera, contacte a su Administrador de Sistemas local e indíquele esta situación, haciendo especial énfasis en mencionar el puerto '''4603''' y el protocolo '''ssh'''.

=== SSH desconoce el identificador de los nodos de acceso ===
En ocasiones puede presentar problemas de acceso debido a las llaves de identificación de los servidores de acceso.

Puede probar a verificar si en su directorio personal existe el directoro '''.ssh'''.
Para los usuarios de Linux, OS X y Powershell pueden acceder simplemente con:

<pre>
cd ~/.ssh
</pre>

Dentro de dicho directorio podrá ver que existe un archivo llamado '''known_hosts'''.

Puede eliminar o renombrar dicho archivo para que en el siguiente intento de conexión se genere nuevamente.

Por ejemplo:

<pre>
cd ~/.ssh
mv known_hosts known_hosts_backup
</pre>

Luego al conectar nuevamente a '''leftraru.nlhpc.cl'''

<pre>
ssh -p 4603 dbowman@leftraru.nlhpc.cl
</pre>

se nos pedirá confirmar:

<pre>
The authenticity of host '[leftraru.nlhpc.cl]:4603 ([146.83.2.234]:4603)' can't be established.
ED25519 key fingerprint is SHA256:Murakami74f74....
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[leftraru.nlhpc.cl]:4603' (ED25519) to the list of known hosts.
</pre>

Lo anterior también lo puede ejecutar para los nodos de acceso específicos '''leftraru1.nlhpc.cl''' y '''leftraru2.nlhpc.cl'''.

==== Usuarios de Putty ====
En el caso de utilizar Putty, es necesario que abra el Registro de Windows, busque el valor ''' HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys''' y elimine los valores asociados a los servidores de acceso.

Puede buscar más información en el siguiente [https://www.google.com/search?q=putty+como+borrar+archivo+known+hosts link].

==== Otras aplicaciones ====
Dependiendo de las aplicaciones que utilice y los sistemas operativos, recomendamos que busque información sobre como eliminar las preferencias específicas de su aplicación, como también utilizar las palabras claves '''known hosts''' al buscar información específica de la herramienta que esté utilizado.

=== Error de conexión en redes institucionales (Firewall) ===
Si experimenta problemas conectándose desde su red institucional, es muy probable que el firewall local esté bloqueando el '''puerto 4603'''. Para confirmarlo, ejecute el comando correspondiente a su sistema operativo:

==== Verificación de conectividad ====

; Desde Linux / macOS:
<syntaxhighlight lang="bash">
nc -zv leftraru.nlhpc.cl 4603
</syntaxhighlight>
* '''Puerto abierto:''' Verá un mensaje similar a <code>Connection to leftraru.nlhpc.cl 4603 port [tcp/*] succeeded!</code>.
* '''Puerto bloqueado:''' Verá un error de <code>Connection refused</code> o <code>Timeout</code>.

; Desde Windows (PowerShell):
<syntaxhighlight lang="powershell">
Test-NetConnection -ComputerName leftraru.nlhpc.cl -Port 4603
</syntaxhighlight>
* '''Puerto abierto:''' En la última línea leerá <code>TcpTestSucceeded : True</code>.
* '''Puerto bloqueado:''' Leerá <code>TcpTestSucceeded : False</code>.

==== Resolución del problema ====

Si confirma que el acceso está restringido, debe realizar las siguientes acciones:

# '''Prueba de descarte (Hotspot):''' Conecte su equipo a una red externa, como el punto de acceso de su dispositivo móvil. Si logra conectarse exitosamente de esta manera, habrá descartado un problema con el clúster.
# '''Gestión con soporte TI:''' Con la prueba anterior como respaldo, deberá contactar con el administrador de red de su institución para solicitar la apertura del '''puerto 4603''', indicando que es necesario para la conexión al clúster del NLHPC.

=== Contraseña incorrecta ===
Puede solicitar una nueva contraseña a nuestro correo electrónico [mailto:soporte@nlhpc.cl soporte@nlhpc.cl].

Favor indicar su nombre de usuario para esto.

Recuerde que el remitente será contrastado con nuestros registros de su cuenta.

== Si necesita soporte ==

Si necesita soporte o tiene problemas de acceso escriba a '''[mailto:soporte@nlhpc.cl soporte@nlhpc.cl]''' indicando su nombre de usuario, su IP pública, aplicaciones utilizadas y los mensajes de error que haya observado.

Algunos puntos a considerar en el siguiente [https://wiki.nlhpc.cl/Como_abrir_un_ticket#Problemas_de_acceso_al_cl%C3%BAster enlace].

== Enlaces externos ==

Guía de generación de llaves SSH y su uso bajo sistema operativo Windows en el siguiente [https://chrisjhart.com/Windows-10-ssh-copy-id/ enlace].

Playlist con vídeo tutoriales en canal de [https://www.youtube.com/watch?v=mWa-1Ad1SmY&list=PL6GflPS8SOqrEeAbBKOKqhWy3y3LF_gQ6 YouTube].

Tutorial de acceso a Leftraru via SSH

2026-04-15T18:49:41Z

Administrador: /* Problemas conocidos */

== Accediendo desde un equipo Linux o Mac OSX ==
Para realizar una conexión desde un sistema GNU/Linux o MacOSX, use el comando SSH (ejemplo con usuario "prueba") e indicar el uso del puerto '''4603'''.

Por ejemplo, el usuario Dave Bowman (nombre de usuario ''dbowman'') accede al clúster ejecutando:
<pre>
$ ssh -p 4603 dbowman@leftraru.nlhpc.cl
dbowman@leftraru.nlhpc.cl password:

[...]

dbowman@leftraru2:~$
</pre>

=== Guardar información de la sesión ===

Es posible almacenar los datos de conexión bajo el archivo '''~/.ssh/config''', lo que nos otorgará un poco más de flexibilidad a la hora de conectarnos.

Por ejemplo, el usuario Dave Bowman edita el archivo mencionado con:

<pre>
vi ~/.ssh/config
</pre>

y agrega la siguiente información:

<pre>
Host leftraru
Hostname leftraru.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no
</pre>

El parámetro '''Host''' indica el valor '''leftraru''' como nombre de conexión. Este valor podrá ser utilizado directamente con el comando '''ssh'''.

El valor '''Hostname''' indica la dirección a la cual nos queremos conectar (puedes indicar una IP si así lo deseas).

Los parámetros '''User''' y '''Port''' ya los hemos visto.

Y por último el parámetro '''UpdateHostKeys''' indica si deberá aceptar o no los cambios de llaves en el servidor. Por seguridad se recomienda el valor '''no'''.

Una vez que se edito esta información, nuestro usuario podrá acceder al clúster con tan solo escribir el comando:

<pre>ssh leftraru</pre>

==== Es posible tener una gran cantidad de entradas en nuestro archivo .ssh/config ====

Un ejemplo del archivo de configuración con más cantidad de entradas sería similar a:

<pre>
Host leftraru
Hostname leftraru.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host l1
Hostname leftraru1.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host l2
Hostname leftraru2.nlhpc.cl
User dbwoman
Port 4603
UpdateHostKeys no

Host HAL
Hostname 127.0.0.1
User dbwoman
Port 9000
UpdateHostKeys no
...
</pre>

Con dicha configuración, el usuario podría acceder usando uno de los siguientes comandos:

<pre>
ssh l1
ssh l2
</pre>

== Accediendo desde un equipo Windows ==
Para conectar desde sistemas Windows, se recomienda usar Putty como cliente SSH.

Como vemos en el ejemplo se indican los campos:

* Hostname: dbowman@leftraru.nlhpc.cl
* Puerto: 4603

[[Archivo:Putty-dbowman-hostname.png|no]]

Y se realiza la conexión haciendo ''click'' en el botón inferior ''Open''.

Si la conexión es exitosa podremos ingresar el usuario y contraseña.

En este ejemplo, es el usuario Dave Bowman (dbowman) quien intenta conectarse al clúster.

[[Archivo:Putty-dbowman-user-ssh.png|no]]

Recuerda que al momento de ingresar tu contraseña, esta no será desplegada en pantalla.

=== Guardar nuestra sesión ===

Una vez que se ingresa los valores de '''Hostname''' y '''Puerto''', es posible almacenar dicha información indicando un nombre en el campo '''Saved Sessions''' y presionando el botón '''Save''.

La próxima vez que necesitemos acceder al cluster, bastará hacer doble ''click'' sobre la sesión que necesitemos abrir.

Por ejemplo en este caso es posible ver que las siguientes sesiones están almacenadas:

<gallery>
Archivo:Putty-saved-sessions.png
</gallery>

* Default
* L1
* L2
* Leftraru

== Acceso utilizando llaves ==
La autenticación con clave pública es un método de seguridad alternativo a las contraseñas, mucho más difícil de hackear y, por lo tanto, más seguro. Este método de autenticación es recomendable usarlo para acceder a servidores.

La clave SSH consiste en la generación de un par de claves que proporcionan dos largas cadenas de caracteres, una pública y una privada. La clave pública se instala en cualquier servidor y luego se desbloquea mediante la conexión con un cliente SSH que hace uso de la clave privada. Si las dos claves coinciden, el servidor SSH permite el acceso sin necesidad de utilizar una contraseña. No obstante, para añadir una capa de seguridad adicional, siempre podemos aumentar la protección de la clave privada usando una contraseña.

Entonces nuestro usuario Dave Bowman creará una llave en su computadora personal para copiarla en el clúster siguiendo los pasos que se indican a continuación:

<pre>
[dave@HAL ~]$ ssh-keygen -t ed25519
</pre>

Tras ejecutar el comando obtendremos la siguiente respuesta:

<pre>
Generating public/private ed25519 key pair.
</pre>

Una vez ejecutada la instrucción para generar las claves, se nos pedirá que indiquemos la ruta en la que queremos almacenar la clave:

<pre>
Enter file in which to save the key (/home/dave/.ssh/id_ed25519):
</pre>

Tras indicar la ruta en la que se almacenará la clave, lo siguiente que tendremos que hacer es indicar una contraseña (puede dejar vacío para acceso directo):

<pre>
Enter passphrase (empty for no passphrase):
</pre>

Finalmente debemos copiar nuestra llave pública al cluster:

<pre>
[dave@HAL ~] ssh-copy-id -p 4603 dbowman@leftraru.nlhpc.cl
Number of key(s) added: 1

Now try logging into the machine, with: "ssh -p '4603' 'dbowman@leftraru.nlhpc.cl'"
and check to make sure that only the key(s) you wanted were added.
</pre>

Ahora ya podremos conectarnos directamente con nuestras llaves:

<pre>
[dave@HAL ~] ssh -p 4603 dbowman@leftraru.nlhpc.cl
</pre>

=== Copiar la llave desde Windows al clúster ===

En el caso de que se utilice Windows como sistema operativo, una posibilidad de copiar la llave es ejecutando:

<pre>
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh -p 4603 dbowman@leftraru.nlhpc.cl "cat >> .ssh/authorized_keys"
</pre>

Si lo anterior no funciona, recomendamos que abra en una aplicación como NotePad el archivo '''.ssh\id_rsa.pub''' y copie el contenido al archivo en:

<pre>
nano ~/.ssh/authorized_keys
</pre>

Considere también que dependiendo de las aplicaciones utilizadas bajo Windows, este paso puede requerir de otros pasos.

Recomedamos que lea la documentación oficial de su software.

== Cambiar contraseña ==
Para cambiar la contraseña de usuario, es necesario que esta cumpla con ciertos requisitos como por ejemplo:

* El mínimo de caracteres son 10.
* Debe ser alfanumérica.
* Tener 3 caracteres especiales (al menos 1 mayúscula – 1 minúscula y 1 número).

Para ejecutar esta acción, utilice el siguiente comando:
<pre>
[dbowman@leftraru1 ~]$ passwd

Changing password for user dbowman.
(current) LDAP Password: <- Ingrese su contraseña actual.

New password: ********* <- Ingrese su nueva contraseña.

Retype new password: Reingrese su nueva contraseña.

passwd: all authentication tokens updated successfully.
</pre>

Confirmación de cambio de clave exitoso, le recomendamos cerrar su sesión e ingresar nuevamente a nuestro sistema ingresando su nueva contraseña.

=== Cambio de Contraseña vía Dashboard ===

También puede cambiar su contraseña desde nuestros [[Dashboard]] siguiendo el siguiente [[Procedimiento cambio o recuperación de contraseña]].

== Conexión a nodos actualmente utilizados ==
Algunas veces, por distintas circunstancias, sería deseable tener la posibilidad de ingresar al nodo donde se estén ejecutando nuestras tareas con tal de verificar su estado, comprobar ciertos valores, etc.

Pensado en la comodidad de los usuarios, se ha implementado un módulo del gestor que colas SLURM que permite esta funcionalidad. Por tanto, el login será permitido en todas aquellas máquinas donde actualmente exista un trabajo nuestro.

Por ejemplo; nuestra tarea de prueba 'tarea_test.sh' ha sido enviada a la cola y ha ingresado con el ID '3469576'. Slurm reservó el nodo 'cn053' para llevar a cabo la ejecución, por tanto el usuario tiene permitido el ingreso mediante ssh al nodo:

<pre>
leftraru$ sbatch tarea_test.sh
leftraru$ squeue

JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
3469576 general Prueba test R 1:57 1 sn007

leftraru$ ssh sn007
Last login: today 2016 from leftraru.nlhpc.cl
sn007$
</pre>

Tenga en cuenta que aún se mantiene la restricción de ingreso para el resto de los nodos:
<pre>
leftraru$ ssh sn001
Access denied: user test (uid=000) has no active jobs on this node.
leftraru$
</pre>

== Nodos Login ==
Aunque disponemos de 4 nodos para el acceso al clúster por parte de los usuarios, en general, hay que usar el nombre:

* leftraru.nlhpc.cl

A la hora de conectarse por SSH al clúster. Al acceder a esa dirección se consigue que los usuarios queden conectados aleatoriamente a los nodos login.

Pero si resultara necesario, se puede acceder a un nodo login específicamente usando su nombre a la hora de realizar la conexión SSH:

* leftraru1.nlhpc.cl
* leftraru2.nlhpc.cl

== Sobre nodos de acceso y uso de multiplexadores ==
Debido a que Leftraru balancea la carga de los nodos Login se debe evitar el uso de screen, ya que no se garantiza el acceso al mismo nodo que tenía la sesión screen abierta una vez que el usuario cierra su sesión.

Un usuario sólo podrá acceder por ssh a los nodos logins. En el caso de querer acceder a un nodo de cómputo, el usuario deberá tener al menos una tarea SLURM en ejecución en el nodo al cual necesite acceder, y deberá considerar que si dicha tarea finaliza, su sesión será cerrada del nodo.

'''Si falla muchas veces el intento de login por SSH o genera muchas conexiones, su IP podría ser bloqueada. Contacte por correo electrónico con Soporte indicando información relevante (más información [[Como_abrir_un_ticket#Problemas_de_acceso_al_clúster|aquí]]) si presenta problemas de conexión: ''' '''[mailto:soporte@nlhpc.cl soporte@nlhpc.cl]'''

== Ejecución de aplicaciones gráficas ==
Para poder ejecutar aplicaciones gráficas, es necesario conectarse al clúster habilitando el ''reenvío de X11'' (en inglés ''X11 Forwarding''.

Esto se consigue conectándose mediante SSH indicando los parámetros '''-X''' o '''-Y'''

ssh -p 4603 -X dbowman@leftraru.nlhpc.cl

Si ha logrado conectarse podrá ejecutar la aplicación con su interfaz gráfica:

ml ncview/2.1.7
ncview mi_archivo.nc

Si la aplicación no cuenta con interfaz gráfica podrá utilizar la línea de comandos de manera normal.

=== Para usuarios de OS X ===
Si utiliza una computadora con OS X, deberá instalar en su computadora XQuartz, disponible desde: https://www.xquartz.org/

Luego de eso podrá utilizar el comando indicado en la sección anterior.

=== Para usuarios de Windows ===
Si utiliza una computadora con Windows, deberá instalar un programa como XMing, disponible desde:http://www.straightrunning.com/XmingNotes/

Una vez instalado en su computadora, deberá activar el reenvío de X11 en su aplicación.
Por ejemplo, al momento de crear una conexión debe ir a la sección '''Conexión'''→'''SSH'''→'''X11''' y seleccionar la opción '''Enable X11 forwarding'''.

[[Archivo:X11-forwarding.png|Putty y reenvío de X11]]

== Problemas conocidos ==
=== IP bloqueada ===
Si ha ingresado su contraseña de manera equivocada en varias oportunidades, su acceso puede ser bloqueado por razones de seguridad. Favor enviar un correo a [mailto:soporte@nlhpc.cl soporte@nlhpc.cl] indicando su IP pública.

Si desconoce su IP pública puede vistar https://miip.cl o un servicio similar a su elección.

=== No logra acceder desde su lugar de trabajo ===
Pruebe conectándose a otra red.

Una prueba sencilla y rápida es compartir la conexión a Internet de su celular móvil (''hotspot'') y probar acceder al clúster.

Esta prueba permite cambiar de IP y no tener restricciones en base a las políticas de su lugar de trabajo.

Si logra conectarse de esta manera, contacte a su Administrador de Sistemas local e indíquele esta situación, haciendo especial énfasis en mencionar el puerto '''4603''' y el protocolo '''ssh'''.

=== SSH desconoce el identificador de los nodos de acceso ===
En ocasiones puede presentar problemas de acceso debido a las llaves de identificación de los servidores de acceso.

Puede probar a verificar si en su directorio personal existe el directoro '''.ssh'''.
Para los usuarios de Linux, OS X y Powershell pueden acceder simplemente con:

<pre>
cd ~/.ssh
</pre>

Dentro de dicho directorio podrá ver que existe un archivo llamado '''known_hosts'''.

Puede eliminar o renombrar dicho archivo para que en el siguiente intento de conexión se genere nuevamente.

Por ejemplo:

<pre>
cd ~/.ssh
mv known_hosts known_hosts_backup
</pre>

Luego al conectar nuevamente a '''leftraru.nlhpc.cl'''

<pre>
ssh -p 4603 dbowman@leftraru.nlhpc.cl
</pre>

se nos pedirá confirmar:

<pre>
The authenticity of host '[leftraru.nlhpc.cl]:4603 ([146.83.2.234]:4603)' can't be established.
ED25519 key fingerprint is SHA256:Murakami74f74....
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[leftraru.nlhpc.cl]:4603' (ED25519) to the list of known hosts.
</pre>

Lo anterior también lo puede ejecutar para los nodos de acceso específicos '''leftraru1.nlhpc.cl''' y '''leftraru2.nlhpc.cl'''.

==== Usuarios de Putty ====
En el caso de utilizar Putty, es necesario que abra el Registro de Windows, busque el valor ''' HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys''' y elimine los valores asociados a los servidores de acceso.

Puede buscar más información en el siguiente [https://www.google.com/search?q=putty+como+borrar+archivo+known+hosts link].

==== Otras aplicaciones ====
Dependiendo de las aplicaciones que utilice y los sistemas operativos, recomendamos que busque información sobre como eliminar las preferencias específicas de su aplicación, como también utilizar las palabras claves '''known hosts''' al buscar información específica de la herramienta que esté utilizado.

=== Error de conexión en redes institucionales (Firewall) ===
Si experimenta problemas conectándose desde su red institucional, es muy probable que el firewall local esté bloqueando el '''puerto 4603'''. Para confirmarlo, ejecute el comando correspondiente a su sistema operativo:

=== Verificación de conectividad ===

; Desde Linux / macOS:
<syntaxhighlight lang="bash">
nc -zv leftraru.nlhpc.cl 4603
</syntaxhighlight>
* '''Puerto abierto:''' Verá un mensaje similar a <code>Connection to leftraru.nlhpc.cl 4603 port [tcp/*] succeeded!</code>.
* '''Puerto bloqueado:''' Verá un error de <code>Connection refused</code> o <code>Timeout</code>.

; Desde Windows (PowerShell):
<syntaxhighlight lang="powershell">
Test-NetConnection -ComputerName leftraru.nlhpc.cl -Port 4603
</syntaxhighlight>
* '''Puerto abierto:''' En la última línea leerá <code>TcpTestSucceeded : True</code>.
* '''Puerto bloqueado:''' Leerá <code>TcpTestSucceeded : False</code>.

==== Resolución del problema ====

Si confirma que el acceso está restringido, debe realizar las siguientes acciones:

# '''Prueba de descarte (Hotspot):''' Conecte su equipo a una red externa, como el punto de acceso de su dispositivo móvil. Si logra conectarse exitosamente de esta manera, habrá descartado un problema con el clúster.
# '''Gestión con soporte TI:''' Con la prueba anterior como respaldo, deberá contactar con el administrador de red de su institución para solicitar la apertura del '''puerto 4603''', indicando que es necesario para la conexión al clúster del NLHPC.

=== Contraseña incorrecta ===
Puede solicitar una nueva contraseña a nuestro correo electrónico [mailto:soporte@nlhpc.cl soporte@nlhpc.cl].

Favor indicar su nombre de usuario para esto.

Recuerde que el remitente será contrastado con nuestros registros de su cuenta.

== Si necesita soporte ==

Si necesita soporte o tiene problemas de acceso escriba a '''[mailto:soporte@nlhpc.cl soporte@nlhpc.cl]''' indicando su nombre de usuario, su IP pública, aplicaciones utilizadas y los mensajes de error que haya observado.

Algunos puntos a considerar en el siguiente [https://wiki.nlhpc.cl/Como_abrir_un_ticket#Problemas_de_acceso_al_cl%C3%BAster enlace].

== Enlaces externos ==

Guía de generación de llaves SSH y su uso bajo sistema operativo Windows en el siguiente [https://chrisjhart.com/Windows-10-ssh-copy-id/ enlace].

Playlist con vídeo tutoriales en canal de [https://www.youtube.com/watch?v=mWa-1Ad1SmY&list=PL6GflPS8SOqrEeAbBKOKqhWy3y3LF_gQ6 YouTube].

Diffusers

2025-09-23T15:17:07Z

Administrador: /* Creación de un script python */

== Introducción ==

Los modelos de difusión son arquitecturas generativas que permiten crear imágenes de alta calidad a partir de texto u otras modalidades.

En esta guía, se enseñara el uso de diffusers de hugging face. Con lo que podrá realizar inferencia utilizando el cluster.

== Cargar módulos necesarios: ==

Para utilizar diffusers con compatibilidad AMD, se deben cargar los módulos:

export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack/linux-rocky9-x86_64/aocc/5.0.0
ml ai-inference

El cual contiene todos paquetes de software necesarios para realizar inferencia con modelos de difusión y LLM’s.

Entre los paquetes se encuentran:

* Pytorch,
* Ollama,
* vLLM,
* diffusers,
* huggingface-cli,
* transformers,
* etc.

== Creación de un script python ==

Para ejecutar inferencia con modelos de difusión, se debe tener un script en python pre-preparado, por ejemplo:

import torch
from diffusers import StableDiffusionPipeline
pipe = StableDiffusionPipeline.from_pretrained(
"stabilityai/stable-diffusion-2-1",
torch_dtype=torch.float16
).to("cuda")
image = pipe("Astronaut riding a horse on Mars, HD, cinematic").images[0]
image.save("output.png")

Notar que la imagen quedará guardada en el directorio de ejecución del script python.
Ejecución con sbatch

Para ejecutar el script en python creado anteriormente, se puede utilizar el siguiente script sbatch como ejemplo:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J diffusion_inference
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --ntasks-per-node=1
#SBATCH -t 0:30:00
#SBATCH --mem=8192MB
#SBATCH -o logs/diffusion_%j.out
#SBATCH -e logs/diffusion_%j.err
# ----------------Modulos----------------------------
ml purge
export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack/linux-rocky9-x86_64/aocc/5.0.0
ml ai-inference
# ----------------Comando--------------------------
python <python_script>.py

== ⚠️ Consideraciones importantes ==

* Uso de VRAM

Si el modelo excede la capacidad de VRAM de una tarjeta gráfica, puede utilizar 2, notar que la velocidad de inferencia no aumenta si hace eso. A continuación algunos ejemplos:

** SD 2.1 Base (~5.1GB en FP16) (una gpu)
** SDXL (~14GB en FP16) (una gpu)

Por lo general, todos los modelos de difusión caben en una sola MI210, por tanto, se recomienda el uso de una sola GPU.

* Reserva de CPU’s

Se recomienda que se soliciten 8 CPU’s por cada GPU

* Directorio de descarga de modelos

Los modelos se descargan automáticamente de Hugging Face Hub en el directorio <code>/home/ai_inference_db/models/</code>. Para usar y descargar modelos en su carpeta de usuario, cambie las variables de entorno:

unset HF_HOME
unset HF_DATASETS_CACHE

Además, si su modelo requiere permisos para utilizarse, puede realizar login a su cuenta utilizando:

huggingface-cli login

Por último, puede comunicarse con el soporte de NLHPC vía tickets para solicitar el grupo <practica-gpu> y descargar modelos en la carpeta compartida.

== Rendimiento ==

[[Archivo:DIFFUSERS-Rendimiento.png]]

== Troubleshooting ==

=== Descarga y Carga del Modelo ===

==== ¿ Por qué el modelo no se descarga, no carga o no se lanza correctamente? ====

Posibles causas:

* Variables de entorno configuradas de forma incorrecta (por ejemplo, <code>HF_HOME</code> o <code>HF_DATASETS_CACHE</code> apuntando a rutas no deseadas).
* Falta de permisos para acceder a ciertos modelos o repositorios.
* El modelo no se encuentra en la carpeta compartida predeterminada (<code>/home/ai_inference_db/models/</code>).

Soluciones:

* Ejecutar <code>unset HF_HOME</code> y <code>unset HF_DATASETS_CACHE</code> para forzar la descarga en la carpeta de usuario.
* Realizar login con huggingface-cli login si el modelo requiere autenticación.
* Consultar con soporte NLHPC para solicitar el grupo de permisos adecuado y confirmar la disponibilidad del modelo en la carpeta compartida.

==== ¿Por qué me aparece error de asignación de memoria en el proceso de carga? ====

Posibles causas:

* El modelo excede la capacidad de RAM asignada. Por ejemplo, algunos modelos (como SDXL en FP16) pueden requerir más memoria de la que solicitaste.

Soluciones:

* Verificar los requisitos de memoria del modelo consultando su documentación (e.g., SD 2.1 Base requiere ~5.1 GB en FP16, mientras que modelos más grandes podrían necesitar GPU adicionales).
* Reservar al menos 8 CPU por cada GPU solicitada y asignar memoria acorde al cálculo: Memoria requerida.
* Revisar y, de ser necesario, aumentar los recursos en el script SBATCH.

== Otros Enlaces ==

[[OLLAMA API]]

[[ Diffusers ]]

[[ vLLM API con módulos de software ]]

OLLAMA API

2025-06-02T20:49:55Z

Administrador: /* Lanzar el servicio Ollama */

== Introducción ==

En el contexto del NLHPC, se ofrecen dos herramientas principales para desplegar y realizar inferencia con LLMs: Ollama y vLLM. La elección entre ambas dependerá del formato del modelo y de los requisitos específicos de la implementación:

* Ollama: Recomendado para utilizar modelos cuantizados, lo que permite una inferencia más rápida y eficiente.
* vLLM: Ideal para ejecutar modelos descargados desde Hugging Face en formato .safetensors, ofreciendo un alto rendimiento y eficiencia en el manejo de múltiples solicitudes simultáneas.

Ollama es una herramienta diseñada para ejecutar y utilizar grandes modelos de lenguaje (LLMs) de forma eficiente y accesible. Su enfoque se centra en la facilidad de uso y se destaca por su soporte con modelos cuantizados.

En el siguiente artículo se le enseñará a:

# Desplegar el servicio de Ollama en el cluster.
# Conectarse a la API del servicio desplegado desde su computadora local.
# Utilizar la API para realizar cargas de trabajo de inferencia.

== Cargar ollama ==

Para obtener Ollama con compatibilidad AMD debe cargar el módulo:

export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack/linux-rocky9-x86_64/aocc/5.0.0
ml ai-inference

El cual contiene todos paquetes de software necesarios para realizar inferencia con modelos de deep learning como diffusers y LLM’s.

Entre los paquetes se encuentran:

* Pytorch,
* Ollama,
* vLLM,
* diffusers,
* huggingface-cli,
* transformers,
* etc.

== Lanzar el servicio Ollama ==

Para poder utilizar el servicio de ollama, primero hay que lanzarlo, esto se puede realizar con el siguiente script sbatch de ejemplo:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J ollama_serve
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH -c 8
#SBATCH -t 0:10:00
#SBATCH --mem=30354MB
#SBATCH -o logs/ollama_serve_%j.out
#SBATCH -e logs/ollama_serve_%j.err
#-----------------Toolchain--------------------------
ml purge
# ----------------Modulos----------------------------
export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack/linux-rocky9-x86_64/aocc/5.0.0
ml ai-inference
# ----------------Comando--------------------------
export OLLAMA_HOST=0.0.0.0:11434
ollama serve &

=== ⚠️ Consideraciones importantes: ===

==== Terminar el servicio de Ollama: ====

El servicio de Ollama '''no termina automáticamente''', recuerde siempre cancelar la tarea con <code>scancel</code> para evitar subutilización de los recursos de cómputo.

==== Memoria RAM: ====

La cantidad de RAM que se está reservando debe ser acorde a la cantidad de memoria que
necesita el modelo a lanzar. Se puede utilizar la siguiente fórmula para estimar el peso en
GB

<cantidad de parámetros> * <cantidad de bits> / (8 * 10 ^ 9)

Por ejemplo, si su modelo tiene 14 billones de parámetros y está cuantizado a 4 bits, entonces requerirá 7GB de memoria para lanzarse, por tanto debe reservar siete o más gigabytes de memoria.

==== Reserva de GPU’s: ====

Cada GPU MI210 tiene 64 GB de memoria VRAM. Si su modelo utiliza más memoria, entonces solicitar más GPU’s adicionales con <code>--gres</code>.

Notar que, al solicitar más GPU’s el rendimiento en tokens/s no mejora. Además, se recomienda pedir 8 CPU’s por GPU solicitada.

==== Puerto de escucha: ====

Por defecto, el puerto de escucha de ollama es 11434, considere cambiarlo en el archivo <code>.job</code> para que su puerto no choque con el de otros usuarios.

export OLLAMA_HOST=0.0.0.0:<puerto>

==== Usar Modelos en una Ubicación Personalizada: ====

Por defecto, el directorio de descarga de modelos es <code>/home/ai_inference_db/models</code>. Si el
modelo que se quiere utilizar no se encuentra en esta ubicación. Entonces:

* Solicitar el grupo <code><practica-gpu></code> a soporte NLHPC
* Cambiar el directorio OLLAMA_MODELS con: <code>unset OLLAMA_MODELS</code>

== Identificar en qué Nodo ejecutó Ollama ==

Una vez lanzado el servicio de Ollama, debemos saber qué nodo se asignó. Para esto, utilizar <code>squeue</code>

[intern02@leftraru2 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
38922125 mi210 ollama_s intern02 R 0:03 1 gn004

Recordar el nodo donde está ejecutando nuestra tarea, en este caso '''gn004'''.

== Creación de túnel de acceso ==

Sabiendo el nodo donde ejecutó nuestra tarea, podemos crear un túnel de acceso utilizando <code>ssh</code>

ssh <usuario>@leftraru.nlhpc.cl -p 4603 -L <puerto local>:<nodo>:<puerto en que se abrió el proceso>

por ejemplo:

ssh intern02@leftraru.nlhpc.cl -p 4603 -L 4466:gn004:11434

Con esto, podremos usar el “puerto local” para acceder a la API de ollama y por tanto, utilizarla.
Ejemplo de uso

Una vez realizado el túnel de acceso con el nodo, es posible utilizar herramientas como curl
o la librería requests de python para realizar consultas a la API de ollama de manera local
[https://github.com/ollama/ollama/blob/main/docs/api.md Guia de uso de la API de ollama].

Por ejemplo:

import requests, json
url = f"<http://127.0.0.1:{port}/api/generate>"
headers = {
"Content-Type": "application/json",
}
payload = {
"model": <modelo>,
"prompt": <prompt>,
"stream": False
}
response = requests.post(url, json=payload, headers=headers)
data = response.json()
response = data.get(“response”, “”)
print(response)

o con curl:

curl -X POST "<http://127.0.0.1:<port>>/api/generate" -H "Content-Type: application/json" -d '{
"model": "<modelo>", "prompt": "<prompt>", "stream": false }'

== Rendimiento: ==

Si se utiliza Ollama en las GPU’s MI210, se espera obtener el siguiente rendimiento:

[[Archivo:OLLAMA-Rendimiento.png]]

== Troubleshooting: ==
=== ¿Cómo puedo cargar mi modelo de lenguaje propio y/o finetuned? ===

* Copiar el modelo en formato <code>.gguf</code> desde su computadora local al cluster utilizando <code>rsync</code> o filezilla. Notar que Ollama sólo acepta un archivo <code>.gguf</code>.
* Crear un modelfile de ollama, puede seguir la siguiente [https://github.com/ollama/ollama/blob/main/docs/modelfile.md#build-from-a-safetensors-model documentación].

Un modelfile típico es:

FROM
ruta/a/tu/modelo.gguf
TEMPLATE """
{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}
{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}
<|im_start|>assistant
"""

* Lanzar un script sbatch cargando el modelo con: <code>ollama serve &</code> y <code>ollama create <model_name> -f /ruta/al/model_file</code>.

Ejemplo:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J ollama_serve
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH -c 6
#SBATCH -t 0:10:00
#SBATCH --mem=4090MB
#SBATCH -o logs/ollama_serve_%j.out
#SBATCH -e logs/ollama_serve_%j.err
#-----------------Toolchain--------------------------
ml purge
# ----------------Modulos----------------------------
ml ai-inference
# ----------------Comando--------------------------
export OLLAMA_HOST=0.0.0.0:11434
ollama serve &
sleep 5
ollama create Hermes-3:405b-Q4_L -f /home/intern02/test/ollama_test/Modelfile

* Posterior a este paso, puede realizar inferencia con su modelo con:

ollama run <model_name>

=== ¿Por qué falla al cargar el modelo? ===

Si el modelo no carga, es probable que no esté disponible en directorio compartido <code>/home/ai_inference_db/models</code>, ante esto hay dos soluciones.

* Comunicarse con el equipo NLHPC mediante Ticket a soporte para ser agregado al grupo <code><practica-gpu\></code>, el cual puede descargar modelos en la carpeta compartida.
* Cambiar la variable de entorno <code>OLLAMA_MODELS</code> a un directorio con permisos.

unset OLLAMA_MODELS

Con esto podrá descargar modelos en su directorio local y por tanto, ejecutarlos.

=== ¿Es posible utilizar modelos desde hugging face? ===

Si, si el modelo está en formato <code>.gguf</code>, es posible que exista compatibilidad directa con el servicio de ollama. Por ejemplo:

ollama run hf.co/unsloth/DeepSeek-R1-GGUF:Q4_K_M

Por lo general, puede encontrar las instrucciones de ejecución en la página de Hugging Face, específicamente en la sección "Use this model" del modelo.

== Otros Enlaces ==

[[OLLAMA API]]

[[VLLM API con módulos de software]]

[[VLLM API con apptainer]]

[[ Diffusers ]]

OLLAMA API

2025-06-02T20:48:52Z

Administrador: /* Lanzar el servicio Ollama */

== Introducción ==

En el contexto del NLHPC, se ofrecen dos herramientas principales para desplegar y realizar inferencia con LLMs: Ollama y vLLM. La elección entre ambas dependerá del formato del modelo y de los requisitos específicos de la implementación:

* Ollama: Recomendado para utilizar modelos cuantizados, lo que permite una inferencia más rápida y eficiente.
* vLLM: Ideal para ejecutar modelos descargados desde Hugging Face en formato .safetensors, ofreciendo un alto rendimiento y eficiencia en el manejo de múltiples solicitudes simultáneas.

Ollama es una herramienta diseñada para ejecutar y utilizar grandes modelos de lenguaje (LLMs) de forma eficiente y accesible. Su enfoque se centra en la facilidad de uso y se destaca por su soporte con modelos cuantizados.

En el siguiente artículo se le enseñará a:

# Desplegar el servicio de Ollama en el cluster.
# Conectarse a la API del servicio desplegado desde su computadora local.
# Utilizar la API para realizar cargas de trabajo de inferencia.

== Cargar ollama ==

Para obtener Ollama con compatibilidad AMD debe cargar el módulo:

export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack/linux-rocky9-x86_64/aocc/5.0.0
ml ai-inference

El cual contiene todos paquetes de software necesarios para realizar inferencia con modelos de deep learning como diffusers y LLM’s.

Entre los paquetes se encuentran:

* Pytorch,
* Ollama,
* vLLM,
* diffusers,
* huggingface-cli,
* transformers,
* etc.

== Lanzar el servicio Ollama ==

Para poder utilizar el servicio de ollama, primero hay que lanzarlo, esto se puede realizar con el siguiente script sbatch de ejemplo:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J ollama_serve
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH -c 8
#SBATCH -t 0:10:00
#SBATCH --mem=30354MB
#SBATCH -o logs/ollama_serve_%j.out
#SBATCH -e logs/ollama_serve_%j.err
#-----------------Toolchain--------------------------
ml purge
# ----------------Modulos----------------------------
export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack/linux-rocky9-x86_64/aocc/5.0.0

ml ai-inference
# ----------------Comando--------------------------
export OLLAMA_HOST=0.0.0.0:11434
ollama serve &

=== ⚠️ Consideraciones importantes: ===

==== Terminar el servicio de Ollama: ====

El servicio de Ollama '''no termina automáticamente''', recuerde siempre cancelar la tarea con <code>scancel</code> para evitar subutilización de los recursos de cómputo.

==== Memoria RAM: ====

La cantidad de RAM que se está reservando debe ser acorde a la cantidad de memoria que
necesita el modelo a lanzar. Se puede utilizar la siguiente fórmula para estimar el peso en
GB

<cantidad de parámetros> * <cantidad de bits> / (8 * 10 ^ 9)

Por ejemplo, si su modelo tiene 14 billones de parámetros y está cuantizado a 4 bits, entonces requerirá 7GB de memoria para lanzarse, por tanto debe reservar siete o más gigabytes de memoria.

==== Reserva de GPU’s: ====

Cada GPU MI210 tiene 64 GB de memoria VRAM. Si su modelo utiliza más memoria, entonces solicitar más GPU’s adicionales con <code>--gres</code>.

Notar que, al solicitar más GPU’s el rendimiento en tokens/s no mejora. Además, se recomienda pedir 8 CPU’s por GPU solicitada.

==== Puerto de escucha: ====

Por defecto, el puerto de escucha de ollama es 11434, considere cambiarlo en el archivo <code>.job</code> para que su puerto no choque con el de otros usuarios.

export OLLAMA_HOST=0.0.0.0:<puerto>

==== Usar Modelos en una Ubicación Personalizada: ====

Por defecto, el directorio de descarga de modelos es <code>/home/ai_inference_db/models</code>. Si el
modelo que se quiere utilizar no se encuentra en esta ubicación. Entonces:

* Solicitar el grupo <code><practica-gpu></code> a soporte NLHPC
* Cambiar el directorio OLLAMA_MODELS con: <code>unset OLLAMA_MODELS</code>

== Identificar en qué Nodo ejecutó Ollama ==

Una vez lanzado el servicio de Ollama, debemos saber qué nodo se asignó. Para esto, utilizar <code>squeue</code>

[intern02@leftraru2 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
38922125 mi210 ollama_s intern02 R 0:03 1 gn004

Recordar el nodo donde está ejecutando nuestra tarea, en este caso '''gn004'''.

== Creación de túnel de acceso ==

Sabiendo el nodo donde ejecutó nuestra tarea, podemos crear un túnel de acceso utilizando <code>ssh</code>

ssh <usuario>@leftraru.nlhpc.cl -p 4603 -L <puerto local>:<nodo>:<puerto en que se abrió el proceso>

por ejemplo:

ssh intern02@leftraru.nlhpc.cl -p 4603 -L 4466:gn004:11434

Con esto, podremos usar el “puerto local” para acceder a la API de ollama y por tanto, utilizarla.
Ejemplo de uso

Una vez realizado el túnel de acceso con el nodo, es posible utilizar herramientas como curl
o la librería requests de python para realizar consultas a la API de ollama de manera local
[https://github.com/ollama/ollama/blob/main/docs/api.md Guia de uso de la API de ollama].

Por ejemplo:

import requests, json
url = f"<http://127.0.0.1:{port}/api/generate>"
headers = {
"Content-Type": "application/json",
}
payload = {
"model": <modelo>,
"prompt": <prompt>,
"stream": False
}
response = requests.post(url, json=payload, headers=headers)
data = response.json()
response = data.get(“response”, “”)
print(response)

o con curl:

curl -X POST "<http://127.0.0.1:<port>>/api/generate" -H "Content-Type: application/json" -d '{
"model": "<modelo>", "prompt": "<prompt>", "stream": false }'

== Rendimiento: ==

Si se utiliza Ollama en las GPU’s MI210, se espera obtener el siguiente rendimiento:

[[Archivo:OLLAMA-Rendimiento.png]]

== Troubleshooting: ==
=== ¿Cómo puedo cargar mi modelo de lenguaje propio y/o finetuned? ===

* Copiar el modelo en formato <code>.gguf</code> desde su computadora local al cluster utilizando <code>rsync</code> o filezilla. Notar que Ollama sólo acepta un archivo <code>.gguf</code>.
* Crear un modelfile de ollama, puede seguir la siguiente [https://github.com/ollama/ollama/blob/main/docs/modelfile.md#build-from-a-safetensors-model documentación].

Un modelfile típico es:

FROM
ruta/a/tu/modelo.gguf
TEMPLATE """
{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}
{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}
<|im_start|>assistant
"""

* Lanzar un script sbatch cargando el modelo con: <code>ollama serve &</code> y <code>ollama create <model_name> -f /ruta/al/model_file</code>.

Ejemplo:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J ollama_serve
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH -c 6
#SBATCH -t 0:10:00
#SBATCH --mem=4090MB
#SBATCH -o logs/ollama_serve_%j.out
#SBATCH -e logs/ollama_serve_%j.err
#-----------------Toolchain--------------------------
ml purge
# ----------------Modulos----------------------------
ml ai-inference
# ----------------Comando--------------------------
export OLLAMA_HOST=0.0.0.0:11434
ollama serve &
sleep 5
ollama create Hermes-3:405b-Q4_L -f /home/intern02/test/ollama_test/Modelfile

* Posterior a este paso, puede realizar inferencia con su modelo con:

ollama run <model_name>

=== ¿Por qué falla al cargar el modelo? ===

Si el modelo no carga, es probable que no esté disponible en directorio compartido <code>/home/ai_inference_db/models</code>, ante esto hay dos soluciones.

* Comunicarse con el equipo NLHPC mediante Ticket a soporte para ser agregado al grupo <code><practica-gpu\></code>, el cual puede descargar modelos en la carpeta compartida.
* Cambiar la variable de entorno <code>OLLAMA_MODELS</code> a un directorio con permisos.

unset OLLAMA_MODELS

Con esto podrá descargar modelos en su directorio local y por tanto, ejecutarlos.

=== ¿Es posible utilizar modelos desde hugging face? ===

Si, si el modelo está en formato <code>.gguf</code>, es posible que exista compatibilidad directa con el servicio de ollama. Por ejemplo:

ollama run hf.co/unsloth/DeepSeek-R1-GGUF:Q4_K_M

Por lo general, puede encontrar las instrucciones de ejecución en la página de Hugging Face, específicamente en la sección "Use this model" del modelo.

== Otros Enlaces ==

[[OLLAMA API]]

[[VLLM API con módulos de software]]

[[VLLM API con apptainer]]

[[ Diffusers ]]

Monitoreo

2025-04-29T18:21:53Z

Administrador: /* Archivo report.log */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[dbowman@sn009 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando '''seff''' muestra la eficiencia de un trabajo en SLURM.
Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

''seff <job_id>''

<pre>
[dbowman@sn009]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes.

[[Archivo:Dashboard.jpg|no|dashboard]]

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Uso_por_core.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Mem_por_core.png|no]]

Monitoreo

2025-04-29T18:19:30Z

Administrador: /* htop */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[dbowman@sn009 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando '''seff''' muestra la eficiencia de un trabajo en SLURM.
Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

''seff <job_id>''

<pre>
[dbowman@sn009]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes.

[[Archivo:Dashboard.jpg|no|dashboard]]

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Uso_por_core.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Mem_por_core.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-29T18:18:50Z

Administrador: /* Memoria utilizada por core */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando '''seff''' muestra la eficiencia de un trabajo en SLURM.
Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

''seff <job_id>''

<pre>
[dbowman@sn009]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes.

[[Archivo:Dashboard.jpg|no|dashboard]]

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Uso_por_core.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Mem_por_core.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Archivo:Mem por core.png

2025-04-29T18:18:02Z

Administrador:

Monitoreo

2025-04-29T18:17:21Z

Administrador: /* Porcentaje de uso por core */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando '''seff''' muestra la eficiencia de un trabajo en SLURM.
Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

''seff <job_id>''

<pre>
[dbowman@sn009]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes.

[[Archivo:Dashboard.jpg|no|dashboard]]

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Uso_por_core.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Archivo:Uso por core.png

2025-04-29T18:16:48Z

Administrador:

Monitoreo

2025-04-28T21:39:06Z

Administrador: /* A través de Dashboard */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando '''seff''' muestra la eficiencia de un trabajo en SLURM.
Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

''seff <job_id>''

<pre>
[dbowman@sn009]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes.

[[Archivo:Dashboard.jpg|no|dashboard]]

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-28T21:38:05Z

Administrador: /* A través de Dashboard */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando '''seff''' muestra la eficiencia de un trabajo en SLURM.
Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

''seff <job_id>''

<pre>
[dbowman@sn009]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes.

<gallery>
Dashboard.jpg| dashboard
</gallery>

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Archivo:Dashboard.jpg

2025-04-28T21:36:11Z

Administrador:

Monitoreo

2025-04-28T20:07:12Z

Administrador: /* A través de Dashboard */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando '''seff''' muestra la eficiencia de un trabajo en SLURM.
Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

''seff <job_id>''

<pre>
[dbowman@sn009]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

SISTEMA GESTOR DE RECURSOS

2025-04-23T14:58:31Z

Administrador: /* Caso de uso de un Script Job Array (Gaussian) */

== SLURM Workload Manager ==
Es un sistema de programación de trabajos y gestión de clústeres de código abierto, tolerante a fallas y altamente escalable para clústeres Linux grandes y pequeños.

Como administrador de carga de trabajo de clúster, Slurm tiene tres funciones clave. Primero, asigna acceso exclusivo y / o no exclusivo a los recursos (nodos de cómputo) a los usuarios durante un período de tiempo para que puedan realizar el trabajo. En segundo lugar, proporciona un marco para iniciar, ejecutar y monitorear el trabajo (normalmente un trabajo paralelo) en el conjunto de nodos asignados. Finalmente, arbitra la contención de recursos mediante la gestión de una cola de trabajo pendiente.

SLURM es el gestor de colas instalado en muchos de los súper computadores del [https://www.top500.org/ TOP500], y también en el clúster del NLHPC. Si Ud. quiere lanzar tareas dentro de Leftaru, debe hacerlo a través de Slurm.

== Conceptos clave ==
SLURM gestiona trabajos de usuario que tienen las siguientes características clave:

* Conjunto de recursos solicitados:
** Número de recursos informáticos: nodos (incluidas todas sus CPUs y núcleos) o CPUs (incluidos todos sus núcleos) o solo núcleos
** Cantidad de memoria: por nodo o por CPU (lógica)
** Tiempo necesario para que las tareas del usuario completen su trabajo
* Una partición de nodo solicitada (cola de trabajos)
* Un nivel de calidad de servicio (QoS) solicitado que otorga a los usuarios accesos específicos
* Una cuenta solicitada con recursos limitados

De manera predeterminada, los usuarios envían trabajos a una partición particular (marcada como tal para todos los usuarios) y bajo una cuenta particular (preestablecida por usuario).

== Particiones SLURM ==

<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Nombre Particion</b></td>
<td><b>Nodos</b></td>
<td><b>CPUs</b></td>
<td><b>RAM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>main</td>
<td>27</td>
<td>256</td>
<td>768GB</td>
<td>
</td></tr>
<tr>
<td>general</td>
<td>48</td>
<td>44</td>
<td>187GB</td>
<td>
</td></tr>
<tr>
<td>largemem</td>
<td>9</td>
<td>44</td>
<td>765GB</td>
<td>
</td></tr>
<tr>
<td>v100</td>
<td>2</td>
<td>44</td>
<td>187GB</td>
<td>4 GPUs Nvidia Tesla V100.
</td></tr>
<tr>
<td>mi100</td>
<td>1</td>
<td>128</td>
<td>502GB</td>
<td>2 GPUs AMD Instinct MI100.
</td></tr>
<tr>
<td>mi210</td>
<td>2</td>
<td>24</td>
<td>1457GB</td>
<td>6 GPUs AMD Instinct MI210.
</td></tr>
<tr>
<td>debug</td>
<td>2</td>
<td>48</td>
<td>768GB</td>
<td>Destinados a pruebas de máximo 30 minutos.
</td></tr></table>

== Introducción a los comandos slurm ==
<table class="wikitable" style="width: 60%;">
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>srun</td>
<td>ejecutar un comando en nodos de cómputo asignados.
</td></tr>
<tr>
<td>sbatch</td>
<td>presentar un script de trabajo
</td></tr>
<tr>
<td>squeue</td>
<td>Mostrar estado de los trabajos en la cola.
</td></tr>
<tr>
<td>scancel</td>
<td>eliminar un trabajo.
</td></tr>
<tr>
<td>sinfo</td>
<td>Muestra el estado de los nodos de cómputo.
</td></tr></table>
Estos son los comandos básicos utilizados para realizar la mayoría de las operaciones básicas con SLURM.

=== Estado de nodos ===
Para consultar el uso de nuestra infraestructura y qué particiones están más libres, le recomendamos el comando sinfo:

<pre># sinfo<small>
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
main* up infinite 1 idle mn[016,018]
main* up infinite 21 mix mn[001-003,005,007-011,013,015,017,019-027]
main* up infinite 4 alloc mn[004,006,012,014]
general up infinite 1 drain sn041
general up infinite 16 mix sn[005-007,012-015,019-021,030-031,043-048]
general up infinite 31 alloc sn[001-004,008-011,016-018,022-029,032-040]
largemem up infinite 1 mix fn006
largemem up infinite 8 alloc fn[001-005,007-009]
debug up infinite 2 idle leftraru[1-2]
v100 up infinite 2 mix gn[001-002]
mi100 up infinite 1 idle gn003
mi210 up infinite 1 mix gn004
mi210 up infinite 1 idle gn005</small>
</pre>

Fijándose en el texto resaltado de la salida del comando sinfo, se puede comprobar que en la partición main hay 20 nodos que están completamente ocupados (estado alloc), 7 nodos que están libres (idle); por otro lado, en la partición general hay 22 nodos completamente ocupados, 4 parcialmente ocupados y 22 libres. Dado este escenario, está claro que debería de lanzar sus ejecuciones en los nodos de la partición general, por las razones anteriormente expuestas.

Para lanzar en la partición general, debe tener en cuenta que tiene que indicar en su script que se use dicha partición en vez de, probablemente, main. Por supuesto, en esta partición cambian las características técnicas, se pasan a tener 44 cores por nodo (en vez de 256 en main) y una capacidad RAM de 187GB (en vez de 768GB en main). Puede ver más información de las particiones en este link(agregar link), donde podrá revisar que con la inclusión de Guacolda hemos añadido nodos con hasta 765GB de memoria RAM y nodos con GPUs Nvidia Tesla V100 y AMD Instinct MI100 .

Para ver los nodos disponibles y poder determinar en que partición lanzar los trabajos se recomienda utilizar el siguiente comando.

<pre>[prueba@leftraru1 ~]$ sinfo -o "%10P %6D %10t %10m %c" -t idle| egrep "PARTITION|main|general|largemem|v100|mi100|mi210"
PARTITION NODES STATE MEMORY CPUS
PARTITION NODES STATE MEMORY CPUS
main* 2 idle 727000 256
general 0 n/a 0 0
largemem 0 n/a 0 0
v100 0 n/a 0 0
mi100 1 idle 485000 128
mi210 1 idle 1457000 48
</pre>

El comando anterior muestra que main tiene 27 nodos libres, en este caso es recomendado lanzar en en main para evitar que el trabajo quede en cola por falta de recursos en otros nodos.

Otro Ejemplo, se muestra sólo una partición específica

<pre>[prueba@leftraru1 ~]$ sinfo -p main
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
main* up infinite 15 mix mn[001-008,014-020]
main* up infinite 12 idle mn[009-013,021-027]
</pre>

=== Comprobación del estado de tareas ===
squeue - Muestra el estatus de los trabajos

<pre>squeue # tus trabajos
squeue -u <username> # trabajos por usuario <username>
</pre>

squeue: Comprobar estados de los trabajos

<div style="" class="mw-highlight mw-content-ltr" dir="ltr">
<pre>
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
13951858_1 general test1 test1 R 1-18:35:14 2 cn[009-010]
13951857_2 general test2 test1 R 1-18:36:11 2 cn[099-100]
13956453 gpu test3 test3 R 1-03:42:08 1 cn039
13956449 largemem test4 test4 R 1-05:42:08 1 cn044
</pre>

Puede utilizar squeue para saber el estado de una o varias de sus tareas

<pre>
$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.10Q %.4C %.2D %.6m" -S -t,-Q
JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME PRIORITY CPUS NO MIN_ME
10837561 general TEST1 2018-06-18T18:51:01 19:00:31 2-04:59:29 2018-06-18T18:51:01 119972 1 1 1000M
10838562 general TEST2 2018-06-19T11:30:47 2:20:45 2-21:39:15 2018-06-19T11:30:46 119946 1 1 1000M
</pre>

para mas opciones puede revisar con el comando [https://slurm.schedmd.com/squeue.html man squeue] las opciones restantes.

=== Códigos de ESTADO de los trabajos ===

Los trabajos suelen pasar por varios estados durante su ejecución. Los estados típicos son PENDIENTE, EN EJECUCIÓN, SUSPENDIDO, FINALIZANDO y TERMINADO. A continuación se explica cada estado.

'''BF''' BOOT_FAIL
Trabajo finalizado debido a un fallo de arranque, normalmente debido a un fallo de hardware (por ejemplo, no se puede arrancar el nodo o bloque y el trabajo no se puede volver a poner en cola).

'''CA''' CANCELADO
El trabajo ha sido cancelado explícitamente por el usuario o el administrador del sistema. El trabajo puede haberse iniciado o no.

'''CD''' TERMINADO
El trabajo ha terminado todos los procesos en todos los nodos con un código de salida de cero.

'''CF''' CONFIGURANDO
Al trabajo se le han asignado recursos, pero están esperando a que estén listos para su uso (por ejemplo, arrancando).

'''CG''' COMPLETANDO
El trabajo está en proceso de finalización. Algunos procesos en algunos nodos pueden estar aún activos.

'''DL''' FECHA LÍMITE
El trabajo ha finalizado en la fecha límite.

'''F''' FALLÓ
Trabajo finalizado con un código de salida distinto de cero u otra condición de fallo.

'''NF''' NODO_FAIL
Trabajo finalizado debido al fallo de uno o más nodos asignados.

'''OOM''' OUT_OF_MEMORY
El trabajo ha experimentado un error de memoria insuficiente.

'''PD''' PENDIENTE
El trabajo está pendiente de asignación de recursos.

'''PR''' PREEMPTED
El trabajo ha finalizado debido a una espera.

'''R''' EN MARCHA
El trabajo tiene actualmente una asignación.

'''RD''' RESV_DEL_HOLD
El trabajo se está reteniendo después de que se eliminara la reserva solicitada.

'''RF''' REQUEUE_FED
El trabajo está siendo solicitado por una federación.

'''RH''' REQUEUE_HOLD
Se está volviendo a poner en cola un trabajo retenido.

'''RQ''' REQUEUED
Se está poniendo en cola un trabajo que se está completando.

'''RS''' CAMBIO DE TAMAÑO
El trabajo está a punto de cambiar de tamaño.

'''RV''' REVOCADO
El trabajo se ha retirado del clúster debido a que otro clúster ha iniciado el trabajo.

'''SI''' SEÑALANDO
El trabajo está siendo señalizado.

'''SE''' SPECIAL_EXIT
El trabajo se ha puesto en cola en un estado especial. Este estado puede ser establecido por los usuarios, normalmente en EpilogSlurmctld, si el trabajo ha terminado con un valor de salida particular.

'''SO''' STAGE_OUT
El trabajo está preparando los archivos.

'''ST''' PARADO
El trabajo tiene una asignación, pero la ejecución se ha detenido con la señal SIGSTOP. Los CPUS han sido retenidos por este trabajo.

'''S''' SUSPENDIDO
El trabajo tiene una asignación, pero se ha suspendido la ejecución y se han liberado CPUs para otros trabajos.

'''TO''' TIMEOUT
El trabajo ha finalizado al alcanzar su límite de tiempo.

=== Cancelar un trabajo ===
Con scancel se puede cancelar un trabajo en ejecución
<pre>scancel <jobID> # Matar proceso <jobID>. (puede obtener el ID del job con "squeue")
scancel -u <username> # Matar proceso por usuario <username>.
</pre>
<pre>[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
45594 main TEST prueba R 0:59 3 mn[001-003]
</pre>
<pre>[prueba@leftraru1 ~]$ scancel 45594
[prueba@leftraru1 ~]$ squeue -u prueba
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
[prueba@leftraru1 ~]$
</pre>

=== Ver estado de trabajos ===
Para revisar el detalle de las opciones de un trabajo: scontrol show job

<pre>
$ scontrol show job 10837561
JobId=10837561 JobName=TEST1
UserId=usuario(1000) GroupId=group(1000) MCS_label=N/A
Priority=1100 Nice=0 Account=account QOS=120
JobState=RUNNING Reason=None Dependency=(null)
Requeue=0 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
DerivedExitCode=0:0
RunTime=19:03:08 TimeLimit=3-00:00:00 TimeMin=N/A
SubmitTime=2018-06-18T18:51:01 EligibleTime=2018-06-18T18:51:01
StartTime=2018-06-18T18:51:01 EndTime=2018-06-21T18:51:01 Deadline=N/A
PreemptTime=None SuspendTime=None SecsPreSuspend=0
Partition=main AllocNode:Sid=leftraru2:5471
ReqNodeList=(null) ExcNodeList=(null)
NodeList=cn021
BatchHost=cn021
NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=1,mem=1000M,node=1
Socks/Node=* NtasksPerN:B:S:C=1:0:*:* CoreSpec=*
Nodes=cn021 CPU_IDs=1 Mem=1000 GRES_IDX=
MinCPUsNode=1 MinMemoryCPU=1000M MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
Gres=(null) Reservation=(null)
OverSubscribe=OK Contiguous=0 Licenses=matlab Network=(null)
Command=/home/usuario/script.sh
WorkDir=/home/usuario/
StdErr=/home/usuario/10837561_%x.err
StdIn=/dev/null
StdOut=/home/usuario/10837561_%x.out
Power=
BatchScript=
</pre>

Para ver el script asociado a un trabajo: scontrol write batch_script <job_id> -

<pre>
$ scontrol write batch_script 10837561 -
#!/bin/bash
#SBATCH -J nombre_del_trabajo
#SBATCH -p main
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH --mail-user=usaurio@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o nombre_del_trabajo%j_%x.out
#SBATCH -e nombre_del_trabajo%j_%x.err
#SBATCH --license=matlab

ml MATLAB/2017a

matlab -nodisplay -nosplash -nodesktop < programa.m
</pre>

== Ejecutando trabajos ==
Actualmente contamos con 2 metodos de enviar trabajos bajo SLURM: '''sbatch''' and '''srun'''. A veces puede ser ventajoso ejecutar un solo comando en el clúster como prueba o realizar rápidamente una operación con recursos adicionales. 'srun' permite a los usuarios hacer esto, y comparte las mismas variables que 'sbatch' . STDOUT y STDERR para un trabajo 'srun' serán redirigidos a la pantalla del usuario. Ctrl-C cancelará un trabajo srun. '''sbatch''' enviará un script de trabajo para que lo ejecute el clúster. Los scripts de trabajo bajo SLURM son simplemente scripts de shell (* .sh) con un conjunto de solicitudes de recursos en la parte superior del script.

Uso básico de srun:

<pre>
srun <algúnComando>
</pre>

Ejemplo de salida (ejecutando el comando "hostname" para saber en que nodo se está ejecutando):
<pre> $ srun hostname
cn003
</pre>

Para enviar un script de trabajo a SLURM:
<pre>sbatch nombreScript.sh</pre>

Example output:
<pre>$ sbatch test-job.sh
Submitted batch job 1169</pre>

=== Variables Slurm ===
Las variables en esta sección son obligatorias, y SLURM las determina para determinar dónde y cuándo se ejecutarán sus trabajos. Si no asigna un valor para estos, el planificador asignará a sus trabajos el valor predeterminado. Si no solicita específicamente recursos para un trabajo, se le asignará un conjunto de recursos predeterminados. Para obtener una lista de todas las variables disponibles, consulte la documentación de SLURM en http://slurm.schedmd.com/sbatch.html. Las variables de este artículo estaban cubiertas porque eran las más relevantes para los casos de uso típicos.

<table class="wikitable" style="width: 100%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>--mem-per-cpu=<megabytes></td>
<td>Memoria requerida para el trabajo por CPU (en MegaBytes). El valor predeterminado es 1024 MB.
</td></tr>
<tr>
<td>-p <partition>, --partition=<partition></td>
<td>Enviar un trabajo a una partición específica.
</td></tr>
<tr>
<td>-n, --ntasks=<cantidad de tareas></td>
<td>Número de tareas que serán asignadas para el trabajo.
</td></tr>
<tr>
<td>-c <cpus></td>
<td>Esta es la cantidad de CPU que necesita su trabajo. Tenga en cuenta que SLURM es relativamente generoso con las CPU, y el valor especificado aquí es el número "mínimo" de CPU que se asignará a su trabajo. Si hay CPU adicionales disponibles en un nodo más allá de lo solicitado, su trabajo recibirá esas CPU hasta que otros trabajos las necesiten. El valor predeterminado es 1 CPU. Intentar usar más CPU de las que se le asignaron dará como resultado que sus procesos adicionales se turnen en la misma CPU (ralentizando su trabajo).
</td></tr>
<tr>
<td>-J <name>, --jobname=<name></td>
<td>Especifica un nombre a tu trabajo.
</td></tr>
<tr>
<td>--mail-type=BEGIN,END,FAIL,ALL<b> and </b>--mail-user=<emailAddress></td>
<td>Enviar por correo electrónico cuando su trabajo comienza / termina / falla. Puede especificar varios valores para esto (separados por comas) si es necesario.
</td></tr>
<tr>
<td>-o <STDOUT_log>, --output=<STDOUT_log></td>
<td>Redirija la salida a los archivos de registro que especifique. Por defecto, ambos, STDOUT and STDERR son enviados a este archivo. Puedes especificar %j como parte del nombre de archivo de registro para indicar la ID del trabajo (como ejemplo, "#SBATCH -o ouptut_%j.o" redirigiría la salida a "output_123456.o").
</td></tr>
<tr>
<td>-e <STDERR_log>, --error=<STDERR_log></td>
<td>Redireccionar STDERR a un archivo separado. Funciona exactamente igual que "-o".
</td></tr>
<tr>
<td>-t <days-hours:minutes:seconds></td>
<td>Walltime para tu trabajo. La duración del Walltime es el tiempo que espera que su trabajo se ejecute.
</td></tr>
<tr>
<td>-a, --array=<índices></td>
<td>Envía una lista (arreglo) de trabajos identicos. Solo aplica para sbatch.
</td></tr></table>

Los scripts de trabajo especifican los recursos solicitados y otras consideraciones especiales con comentarios especiales "#SBATCH" en la parte superior de un script de trabajo. Aunque muchas de estas opciones son opcionales, las varibles que se ocupan de solicitudes de recursos (CPU, memoria y tiempo) son obligatorias. Todas las variables deben agregarse a sus scripts de la siguiente manera:

<pre>#SBATCH <variable></pre>
Para especificar un nombre al job, por ejemplo, debe agregar lo siguiente a su secuencia de comandos:

<pre>#SBATCH --job-name=nombreDeTrabajo</pre>

===Enviar un script===
<pre>
#!/bin/bash
#SBATCH -J example
#SBATCH -p general
#SBATCH -n 1
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J example
</pre>

Nombre la partición donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos casos (verificar opciones arriba):
<pre>
#SBATCH --mail-type=ALL
</pre>

=== Programar tarea (uso de scrontab) ===
'''scrontab''' es una implementación del clásico planificador de tareas de linux '''crontab''' donde se guarda un listado de comandos a ejecutar en un tiempo determinado por el usuario.

Para acceder a scrontab utilice el siguiente comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -e
</pre>

Esto le permitirá editar su archivo scrontab, asignando recursos como también el momento en que desea ejecutar su tarea. La estructura base a utilizar es la siguiente:
<pre>
#SCRON -J mi_tarea
#SCRON -p main
#SCRON -n 1
#SCRON -c 1
#SCRON --mem-per-cpu=2300
#SCRON --mail-user=foo@bar.com
#SCRON --mail-type=ALL
#SCRON -o mi_tarea_%j.out
#SCRON -e mi_tarea_%j.err
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * command to be executed
</pre>

* '''minute''' - Corresponde al minuto en que se va a ejecutar el script, valor de 0 a 59.
* '''hour''' - Hora de ejecución, formato 24 horas, valor de 0 a 23, donde 0 son las 12:00 AM.
* '''day of month''' - Día del mes, la tarea se puede ejecutar cada x día, valor de 1 a 31.
* '''month''' - La tarea se puede ejecutar cada x mes, valor de 1 a 12.
* '''day of week''' - Día de la semana, valor de 0 a 6, donde 0 es Domingo.
* '''command to be executed''' - Script a ejecutar por el usuario.

Ejemplo envío de trabajo slurm:

Para la asignación de recursos, utilizaremos la directriz '''#SCRON''', que utiliza los mismos parámetros usados por '''#SBATCH'''.

Luego de asignar los recursos debemos especificar el tiempo, en este caso la tarea será ejecutada todos los días cada 20 minutos, luego debemos indicar el script enviado por el usuario y guardamos los cambios en el archivo.

<pre>
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Es importante destacar que el script a lanzar '''/home/prueba/ejemplo/script.sh''' debe tener permisos de ejecución.

Para revisar el listado de tareas existentes en nuestro scrontab, ejecutamos el comando:
<pre>
[prueba@leftraru1 ~]$ scrontab -l
*/20 * * * * /home/prueba/ejemplo/script.sh
</pre>

Para borrar el contenido de nuestro scrontab:
<pre>
[prueba@leftraru1 ~]$ scrontab -r
</pre>

'''Información a considerar:'''

* Generar archivos de salida correctamente
** Para que el archivo error y out de tu script se generen en el directorio solicitado, ejemplo, /home/prueba/ejemplo/ en tu script debe estar presente el comando cd “/home/prueba/ejemplo”, esto hará que scrontab se posicione dentro del directorio de salida.
* Es distinto el tiempo de programar el envío de una tarea (scrontab) a que una tarea inicie en el clúster (running), ya que esto dependerá de los recursos libres que existan en ese momento en el clúster.
* Para revisar las tareas programadas debe ejecutar en cualquier nodo login el comando '''scrontab -l''' o revisar con el comando '''squeue''':

<pre>
[prueba@leftraru1 ~]$ squeue
24293471 main /home/eg prueba PD 0:00 1 (BeginTime)
</pre>

== Checkpointing ==
Es la acción de guardar el estado de un proceso en ejecución en un archivo de imagen de punto de control. Este proceso se puede reiniciar más tarde desde el archivo del punto de control, continuando la ejecución desde donde se detuvo, en la misma computadora o en una diferente.

=== ¿Por qué utilizarlo? ===
* Permite ejecuciones de tarea largas que superen el tiempo de ejecución permitido en el cluster (30 días)
* Estar preparados ante fallas del sistema que nos puedan hacer perder resultados de nuestras simulaciones

=== Utilización ===
Lo primero que debemos hacer en nuestro script es cargar el módulo de Mana:
<pre>
ml mana/3.0.0
</pre>
Este módulo provee 3 ejecutables que necesitaremos:

* '''mana_coordinator:''' Coordina los checkpoints entre los distintos procesos
* '''mana_launch:''' Inicia un proceso con checkpoint
* '''mana_restart:''' Reinicia la ejecución desde una imagen del checkpoint

Necesitaremos 2 scripts para trabajar con checkpoints: Inicio y reinicio

=== Script de inicio (inicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Ejecutamos nuestra tarea con checkpointing
srun mana_launch ./ejecutable
</pre>

=== Script de reinicio (reinicio.sh) ===
<pre>
#!/bin/bash
##---------------SLURM Parameters - NLHPC ----------------
#SBATCH -J Testcheckpoint
#SBATCH -p general
#SBATCH -n 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4363
#SBATCH --mail-user=test@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH -o Testcheckpoint_%j.out
#SBATCH -e Testcheckpoint_%j.err

# ----------------Modules----------------------------
ml mana/3.0.0
# ----------------Command--------------------------
#Checkpointing cada 1 hora
mana_cooridinator -i3600
#Reiniciar nuestra tarea desde los archivos de checkpoint
srun mana_restart
</pre>

Para correr estos scripts se puede hacer utilizando la funcionalidad de dependencias de SLURM:
<pre>
[test@leftraru2 test]$ sbatch inicio.sh
Submitted batch job 23574685
[test@leftraru2 test]$ sbatch --dependency=afterok:23574685 reinicio.sh
</pre>

== Trabajos ==
=== Trabajos paralelos ===
Muchos de los trabajos que se ejecutan en un clúster de producción implicarán más de un procesador (CPU, núcleo). Dichos trabajos paralelos deben solicitar la cantidad de recursos necesarios a través de opciones adicionales. Los más comunes son:

Para diferentes tipos de trabajos paralelos, se especificarán diferentes opciones. Los trabajos paralelos más comunes son trabajos de MPI (memoria distribuida), trabajos de subprocesos múltiples (memoria compartida) y los llamados híbridos que son una combinación de los dos. Analicemos por separado con un n ejemplo para cada uno.

=== Ejecución de programas con MPI ===
MPI (interfaz de paso de mensajes) es la API de comunicación estándar para trabajos paralelos de memoria distribuida capaz de implementarse en un clúster. Para programar dicho trabajo, es necesario especificar la cantidad de nodos del clúster que se utilizarán y la cantidad de procesos (tareas) que se ejecutarán en cada nodo.

El siguiente es un ejemplo de ejecución de un programa compilado con Open MPI:

#!/bin/bash
#SBATCH -J example_mpi
#SBATCH -p general
#SBATCH -n 264
#SBATCH --ntasks-per-node=44
#SBATCH --output=example_%j.out
#SBATCH --error=example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

srun ./mpi_test
A continuacion se explica línea por líneael script.

Como empieza un shell script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J example_mpi
</pre>

Nombre la particion donde se desea ejecutar el trabajo:
<pre>
#SBATCH -p general
</pre>

Número de tareas. Debe de ser un número múltiplo del número de CPUs máximo que tenga un node de la partición donde se lanza:
<pre>
#SBATCH -n 264
</pre>

Con esto se fuerza a que se lancen 44 tareas MPI en cada uno de los nodos, ocupando de este modo nodos completos. En este caso 6 nodos completos:
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Envía correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
srun ./mpi_test
</pre>

'''Nota''': no se carga específicamente el módulo "mpi" ya que se carga siempre por defecto.

Para enviarlo al clúster debe ejecutar el comando: ''sbatch script.sh''. El ejemplo anterior ejecutará una tarea OpenMPI con 264 procesos reservando 264 cores para ello.

=== Trabajos multiproceso OpenMP ===
Los trabajos paralelos diseñados para ejecutarse en un sistema multi-core (shared-memory) suelen ser "multi-threaded". La programación de un job de este tipo requiere especificar el número de núcleos que se utilizan para acomodar los subprocesos.

OpenMP es el conjunto común de variables de compilación para facilitar el desarrollo de programas multi-threaded. Un script típico de SLURM para un programa de este tipo se ve así:
<pre>
#!/bin/bash
#SBATCH -J OMPtest
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 44
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=1024
#SBATCH -o example_%j.out
#SBATCH -e example_%j.err
#SBATCH --mail-user=user@example.com
#SBATCH --mail-type=ALL

OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Como debe comenzar un script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del Job:
<pre>
#SBATCH -J OMPtest
</pre>

Nombre la particion donde desea ejecutar el Job:
<pre>
#SBATCH -p general
</pre>

Número de trabajos:
<pre>
#SBATCH -n 1
</pre>

Número de tareas:
<pre>
#SBATCH -c 44
</pre>

Con esto se fuerza a que se agrupen las 44 tareas en un nodo (en OpenMP no hay comunicación entre nodos, por lo que todas las tareas deben estar en el mismo nodo o no funcionaría):
<pre>
#SBATCH --ntasks-per-node=44
</pre>

Memoria por core (MBytes):
<pre>
#SBATCH --mem-per-cpu=1024
</pre>

Log de salida:
<pre>
#SBATCH -o example_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e example_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Programa para ejecutar:
<pre>
OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK time ./omp-program
</pre>

Cuando se utiliza un programa OpenMP, el número de subprocesos (y, por lo tanto, el número requerido de núcleos) se especifica a través de la variable de entorno OMP_NUM_THREADS que, por lo tanto, aparece en el script frente a la llamada al programa. Lo estamos configurando en la variable interna SLURM_CPUS_PER_TASK que se establece a través de la opción "-c" (a 44 en nuestro ejemplo, que sería el número total de cores de un nodo de la partición "general").

La opción "-n" se mantiene en 1 para indicar un único trabajo principal que tiene 44 tareas. Para asegurarnos que todas las tareas se ejecutan en el mismo nodo, se añade la opción "--ntasks-per-node" con el máximo número de cores que tiene un nodo de la partición donde se está lanzando el trabajo.

=== Ejecución de tareas en GPUs ===
<pre>
#!/bin/bash
#SBATCH -J ejemplo_gpus
#SBATCH -p v100
#SBATCH -n 1
#SBATCH -o ejemplo_%j.out
#SBATCH -e ejemplo_%j.err
#SBATCH --mail-user=correo@gmail.com
#SBATCH --mail-type=ALL
#SBATCH --mem-per-cpu=4300
#SBATCH --gres=gpu:1

./programa
</pre>

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre del trabajo:
<pre>
#SBATCH -J ejemplo_gpus
</pre>

Nombre la partición donde se ejecuta el trabajo:
<pre>
#SBATCH --partition=v100
</pre>

Número de tareas:
<pre>
#SBATCH -n 1
</pre>

Log de salida:
<pre>
#SBATCH -o ejemplo_%j.out
</pre>

Log de error:
<pre>
#SBATCH -e ejemplo_%j.err
</pre>

Correo para notificaciones:
<pre>
#SBATCH --mail-user=user@example.com
</pre>

Enviar correo en todos los casos:
<pre>
#SBATCH --mail-type=ALL
</pre>

Memoria por CPU (MB):
<pre>
#SBATCH --mem-per-cpu=4365
</pre>

Cantidad utilizada de GPUs. El parámetro gpu:1 indica la cantidad de tarjetas a utilizar (cada nodo tiene 2 GPUs):
<pre>
#SBATCH --gres=gpu:1
</pre>

Programa para ejecutar:
<pre>
./programa
</pre>

=== Job Arrays ===
Cuando se ejecutan cientos o miles de simulaciones que utilizan la misma cantidad de recursos, puede ser una ventaja ejecutar estas simulaciones como un "job array". Los job array le permiten enviar miles de dichos trabajos (llamados "job steps") con un solo script. A cada simulación se le asignará un valor único para la variable de entorno SLURM_ARRAY_TASK_ID. Puede usar esta variable para leer parámetros para pasos individuales de una línea dada de un archivo.

=== Caso de uso de un Script Job Array (Gaussian) ===
Tenemos usuarios que actualmente envían varias simulaciones al clúster que son similares en cuanto al uso de recursos, pero, la diferencia es que solo cambia la entrada que le entregan al programa. Para esta situación, recomendamos hacer uso de un script Job Array.

En este ejemplo crearemos un script job array para el software Gaussian, el cual, realizará 63 simulaciones, cada una de estas utilizará 8 cores y podrá alcanzar un uso máximo de 8 Gb de memoria ram. Para este caso utilizaremos la partición general donde cada nodo tiene 46 Gb de memoria ram y 20 cores.

Script:
<pre>
#!/bin/bash
# ----------------SLURM Parameters----------------
#SBATCH -J prueba
#SBATCH -p general
#SBATCH -n 1
#SBATCH -c 8
#SBATCH --mem-per-cpu=1000
#SBATCH --mail-user=prueba@nlhpc.cl
#SBATCH --mail-type=ALL
#SBATCH --array=1-63
#SBATCH -o prueba_%A_%a.out
#SBATCH -e prueba_%A_%a.err
#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
# ----------------Módulos-----------------------------
ml g16/B.01
# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>

'''
Descripción de comandos utilizados en script:'''

Inicio de un bash script en Linux:
<pre>
#!/bin/bash
</pre>

Nombre de la simulación:
<pre>
#SBATCH -J prueba
</pre>

Nombre la partición donde se ejecuta la simulación:
<pre>
#SBATCH -p general
</pre>

Número de tareas (1 tarea va a ejecutar 63 simulaciones):
<pre>
#SBATCH -n 1
</pre>

Core’s por tareas (cada tarea utilizará un máximo 8 cores):
<pre>
#SBATCH -c 8
</pre>

Memoria ram por cpu (cada tarea utilizará un máximo 8 Gb de ram):
<pre>
#SBATCH –mem-per-cpu=1000
</pre>

Correo para activar el envío de notificaciones:
<pre>
#SBATCH --mail-user=prueba@nlhpc.cl
</pre>

Permitir envío de notificaciones:
<pre>
#SBATCH --mail-type=ALL
</pre>

Se generan 63 simulaciones diferentes:
<pre>
#SBATCH --array=1-63
</pre>

Log de salida: (ejemplo: prueba_18455017_1.out)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.
<pre>
#SBATCH -o prueba_%A_%a.out
</pre>

Log de errores: (ejemplo: prueba_18455017_1.err)

* %A corresponde al Job ID de nuestra tarea que le asignará Slurm → 18455017.
* %a corresponde a la simulación X de nuestra tarea que le asignará Slurm → 1.

<pre>
#SBATCH -e prueba_%A_%a.err
Toolchain: en este apartado, limpiaremos nuestro entorno de software no deseados y luego escogemos la herramienta informática con la cual está compilado el software Gaussian (nosotros utilizamos el compilador Intel/2019b).

#-----------------Toolchain---------------------------
ml purge
ml intel/2019b
Módulos: cargamos el software Gaussian versión 16/B.0.

# ----------------Módulos-----------------------------
ml g16/B.01
Comandos: aquí definimos los comandos a ejecutar.

# ----------------Comandos--------------------------
file=$(ls Child_10_*.com | sed -n ${SLURM_ARRAY_TASK_ID}p)
srun g16 $file
</pre>
file= variable que va a listar los archivos de entrada que comiencen por Child_10_ y terminen en .com

[[Archivo:Child.png|no]]

sed -n ${SLURM_ARRAY_TASK_ID}p) ← Sed imprimirá las líneas de cada archivo de entrada y la variable $SLURM_ARRAY_TASK_ID asumirá estas entradas como matriz de simulación en nuestro job array, en este ejemplo tenemos 63 archivos de entrada.

Para más detalles sobre los archivos stdin, stdout y stderr de una simulación % A será reemplazado por el valor de SLURM_ARRAY_JOB_ID que es el Job ID de nuestra tarea y %a será reemplazado por el valor de SLURM_ARRAY_TASK_ID que corresponde a la simulación X de nuestra tarea.

Srun g16 $file: ejecutará el comando gaussian g16 interpretando la variable $file en los nodos de cómputo asignados.

Enviar el script:
<pre>
[prueba@leftraru1 ~]$ sbatch prueba.sh
</pre>

=== Ejecución de una tarea que ocupa mucha RAM por CPU ===
Debemos tener en cuenta que la RAM que SLURM reserva por defecto son 1000 MB. Un típico error de cancelación de tarea por falta de memoria es el siguiente:
<pre>
/tmp/slurmd/job136839939/slurm_script: line 15: 23547 Killed ./programa.sh
slurmstepd: error: Detected 1 oom-kill event(s) in step 136839939.batch cgroup. Some of your processes
may have been killed by the cgroup out-of-memory handler.
</pre>

Si su tarea ocupa más de la memoria por defecto, puede utilizar el siguiente parámetro:
<pre>
#SBATCH --mem-per-cpu=2300 #Máxima RAM por CPU
</pre>
Esto hará que SLURM reserve más RAM por CPU para sus tareas.

Tenga en cuenta que nuestros nodos tienen 46 GB de memoria RAM (Partición slims), 187 GB (Partición general) y 765 GB (Partición largemem) por nodo. [https://wiki.nlhpc.cl/Hardware_Disponible Más información].

Otra forma de reservar memoria es utilizando el siguiente parámetro:

<pre>
#SBATCH --mem=2300
</pre>
En este caso SLURM realizará una reserva de memoria de 2300 MB pero por la totalidad del trabajo.

Los parámetros anteriores al igual que el número de CPUs que se van a usar, hay que afinarlos lo mejor posible. Para ello lo que se puede hacer es hacer pruebas en los nodos logins, sin lanzar en las colas, y así estudiar el uso de RAM y CPU por parte de sus procesos.

=== Ejecución de una tarea con Dependencias ===
Las dependencias de trabajos se utilizan para aplazar el inicio de un trabajo hasta que se satisfagan las dependencias especificadas. Se especifican con la opción --dependency en el siguiente formato:
<pre>
sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> ...
</pre>
Los tipos de dependencias son las siguientes:

* '''after''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados comiencen
* '''afterany''':jobid[:jobid...] - el trabajo puede empezar después de que los trabajos especificados terminen
* '''afternotok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan fallidamente
* '''afterok''':jobid[:jobid...] - el trabajo puede empezar después que los trabajos especificados terminan exitósamente

La manera más simple de usar una dependencia del tipo afterok:
<pre>
[prueba@leftraru1 ~]$ sbatch job1.sh
Submitted batch job 21363626
[prueba@leftraru1 ~]$ sbatch --dependency=afterok:21363626 job2.sh
</pre>

Ahora cuando job1.sh termine correctamente, el job2.sh entrará en ejecución. Si job1.sh termina fallidamente, job2.sh no entrará en ejecución nunca pero sí quedará en cola (debe cancelarse manualmente el trabajo).

==== Capturando el Job ID para facilitar la ejecución de varias tareas con dependencias ====
Es posible capturar en una variable el Job ID de cada tarea para poder lanzar varias tareas sin conocer el Job ID previamente.

Por ejemplo, si se desea lanzar 4 tareas que sean dependientes con la anterior, se comenzará lanzando la primera tarea y capturando en la variable '''$JOB1''', el que será utilizado como dependencia en la tarea '''$JOB2''', y así sucesivamente.

<pre>
JOB1=$(sbatch job_1.sbatch 2>&1 | awk '{print $4}')
JOB2=$(sbatch --dependency=afterok:$JOB1 job_2.sbatch 2>&1 | awk '{print $4}')
JOB3=$(sbatch --dependency=afterok:$JOB2 job_3.sbatch 2>&1 | awk '{print $4}')
JOB4=$(sbatch --dependency=afterok:$JOB3 job_4.sbatch 2>&1 | awk '{print $4}')
</pre>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
<table class="wikitable" style="width: 60%;">
<tr>
<td><b>Comando SLURM</b></td>
<td><b>Descripción</b>
</td></tr>
<tr>
<td>Edad</td>
<td>la cantidad de tiempo que el trabajo ha estado esperando en la cola.
</td></tr>
<tr>
<td>Tamaño de la tarea</td>
<td>número de nodos solicitados por el trabajo.
</td></tr>
<tr>
<td>Partición</td>
<td>prioridad para una partición determinada.
</td></tr>
<tr>
<td>Prioridad Baja</td>
<td>Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
</td></tr>
<tr>
<td>Prioridad Alta</td>
<td>Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
</td></tr></table>

== Prioridad de tarea ==
Cómo ver la prioridad del trabajo. Los factores que determinan la prioridad del trabajo, incluyendo la fórmula y pesos.

=== Factores que determinan prioridad de tarea ===
* Edad - la cantidad de tiempo que el trabajo ha estado esperando en la cola
* Tamaño Oficio - número de nodos solicitados por el trabajo
* Partición - prioridad para una partición determinada
* Contribución de prioridades basada en los recursos informáticos utilizados por los miembros de un grupo de investigación en los últimos 30 días - Fairshare.
* Mientras más tareas se ejecuten en el cluster, menor será la prioridad.
* Mientras menos tareas se ejecuten en el clúster, más alta es la prioridad.
Fórmula Prioridad de tarea
<pre>
Job_priority =
(PriorityWeightAge) * (age_factor) +
(PriorityWeightFairshare) * (fair-share_factor) +
(PriorityWeightJobSize) * (job_size_factor) +
(PriorityWeightPartition) * (partition_factor) +
(PriorityWeightQOS) * (QOS_factor)
</pre>

== Visualización de sus Tareas ==
Si Ud. necesita visualizar información acerca de sus tareas de forma interactiva, puede utilizar el comando smap:

smap -i 3

[[Archivo:Smap.png|no|700px]]

De esta forma, tendrá una actualización cada 3 segundos de sus tareas en ejecución incluyendo los nodos en los cuales se encuentran ejecutándose.

== Bibliografía ==
[http://slurm.schedmd.com/documentation.html Manual Oficial de Slurm]

[https://slurm.schedmd.com/scrontab.html Documentación scrontab]

Monitoreo

2025-04-22T14:54:19Z

Administrador: /* seff */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando '''seff''' muestra la eficiencia de un trabajo en SLURM.
Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

''seff <job_id>''

<pre>
[dbowman@sn009]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:53:07Z

Administrador: /* seff */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando seff <job_id> muestra la eficiencia de un trabajo en SLURM. Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

<pre>
[dbowman@sn009]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:52:22Z

Administrador: /* seff */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando seff <job_id> muestra la eficiencia de un trabajo en SLURM. Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

<pre>
[dbowman@sn009 LDAP]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 2-12:18:23
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:51:48Z

Administrador: /* seff */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando seff <job_id> muestra la eficiencia de un trabajo en SLURM. Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

<pre>
[dbowman@sn009 LDAP]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 1-10:30:36
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
</pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:51:06Z

Administrador: /* seff */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando seff <job_id> muestra la eficiencia de un trabajo en SLURM. Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

<pre>
[dbowman@sn009 LDAP]# seff 12863561
Job ID: 12863561
Cluster: leftraru
User/Group: dbowman/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 1-10:30:36
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.
<!pre>



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:49:40Z

Administrador: /* seff */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando seff <job_id> muestra la eficiencia de un trabajo en SLURM. Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.

[dbowman@sn009 LDAP]# seff 47911921
Job ID: 47911921
Cluster: leftraru
User/Group: smiranda/users
State: RUNNING
Nodes: 1
Cores per node: 20
CPU Utilized: 00:00:00
CPU Efficiency: 0.00% of 28-18:12:00 core-walltime
Job Wall-clock time: 1-10:30:36
Memory Utilized: 0.00 MB
Memory Efficiency: 0.00% of 3.91 GB (200.00 MB/core)
WARNING: Efficiency statistics can only be obtained after the job has ended as seff tool is based on the accounting database data.



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:48:14Z

Administrador: /* * seff */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== seff ====
El comando seff <job_id> muestra la eficiencia de un trabajo en SLURM. Funciona tanto con trabajos en ejecución como finalizados, pero mientras corre, los datos son parciales. No entrega información útil si el job está pendiente.



=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:43:23Z

Administrador: /* * htop */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== * seff ====

.


=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:43:01Z

Administrador: /* User Stats */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script desarrollado por el equipo NLHPC permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== * seff ====

.


=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:42:30Z

Administrador: /* * User Stats */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== * seff ====

.


=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:41:08Z

Administrador: /* ¿Como monitoreo los recursos utilizados por mi tarea? */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>


==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== * seff ====

.


=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:40:41Z

Administrador: /* Cantidad de procesos por core */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>



==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== * seff ====

.


=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:02:24Z

Administrador: /* * uptime */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>



==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== * seff ====

.


=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:01:03Z

Administrador: /* La memoria por core (en kb) */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@sn009 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[dbowman@sn009 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== * seff ====

.


=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T14:00:34Z

Administrador: /* Conectándose al nodo */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que reside en el nodo sn009, debemos ingresar a este mediante el comando ssh descrito a continuación

<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@leftraru1 ~]#
</pre>

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[dbowman@leftraru1 ~]# ssh sn009
[dbowman@sn009 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

==== * seff ====

.


=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T13:55:28Z

Administrador: /* Conectándose al nodo */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.
Por ejemplo, si deseamos revisar el uso de recursos de la tarea que tenemos en el nodo sn009

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[usuario@leftraru1 ~]# ssh cn109
usuario@cn000 s password:
[usuario@cn000 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

.


=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T13:52:11Z

Administrador: /* ¿Como listo las tareas? */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[dbowman@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
12863561 general test05 dbowman R 2-12:18:23 1 sn009
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[usuario@leftraru1 ~]# ssh cn109
usuario@cn000 s password:
[usuario@cn000 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

.

=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T13:50:56Z

Administrador: /* ¿Como listo las tareas? */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[usuario@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002
12863541 largemem test02 dbowman R 3-19:03:58 1 fn008
12863789 main test03 dbowman PD 00:00 2 mn[015-016]
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[usuario@leftraru1 ~]# ssh cn109
usuario@cn000 s password:
[usuario@cn000 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

.

=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T13:43:38Z

Administrador: /* ¿Como listo las tareas? */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">

[usuario@leftraru1 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
12863561 general test04 dbowman R 20:39 1 sn002

</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[usuario@leftraru1 ~]# ssh cn109
usuario@cn000 s password:
[usuario@cn000 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

.

=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T13:39:35Z

Administrador: /* ¿Como listo las tareas? */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: auto; white-space: pre-wrap; word-wrap: break-word;">
[usuario@leftraru1 ~]$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.2t %.10q %.4C %.2D %.7W %N " -S -t,-Q

JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME ST QOS CPUS NO LICENSE NODELIST
12863561 general test04 2024-02-08T13:57:53 1-20:25:20 1-03:34:40 2018-07-08T13:57:26 R 120 5 1 (null) cn000
12864082 general test02 2024-02-09T10:44:15 23:38:58 2-00:21:02 2018-07-09T10:43:51 R 120 10 1 (null) cn001
12865333 general test01 2024-02-10T17:16:38 0:00 3-00:00:00 2018-07-10T09:30:22 PD 120 10 1 (null)
12865334 general test06 2024-02-10T17:49:42 0:00 3-00:00:00 2018-07-10T09:38:13 PD 120 10 1 (null)
12865335 general test09 2024-02-11T07:42:16 0:00 3-00:00:00 2018-07-10T09:28:05 PD 120 20 1 (null)
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[usuario@leftraru1 ~]# ssh cn109
usuario@cn000 s password:
[usuario@cn000 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

.

=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T13:38:45Z

Administrador: /* ¿Como listo las tareas? */

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre style="overflow-x: >
[usuario@leftraru1 ~]$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.2t %.10q %.4C %.2D %.7W %N " -S -t,-Q

JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME ST QOS CPUS NO LICENSE NODELIST
12863561 general test04 2024-02-08T13:57:53 1-20:25:20 1-03:34:40 2018-07-08T13:57:26 R 120 5 1 (null) cn000
12864082 general test02 2024-02-09T10:44:15 23:38:58 2-00:21:02 2018-07-09T10:43:51 R 120 10 1 (null) cn001
12865333 general test01 2024-02-10T17:16:38 0:00 3-00:00:00 2018-07-10T09:30:22 PD 120 10 1 (null)
12865334 general test06 2024-02-10T17:49:42 0:00 3-00:00:00 2018-07-10T09:38:13 PD 120 10 1 (null)
12865335 general test09 2024-02-11T07:42:16 0:00 3-00:00:00 2018-07-10T09:28:05 PD 120 20 1 (null)
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[usuario@leftraru1 ~]# ssh cn109
usuario@cn000 s password:
[usuario@cn000 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

.

=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

Monitoreo

2025-04-22T13:27:50Z

Administrador:

== ¿Como listo las tareas? ==
Ejecuto el comando [https://slurm.schedmd.com/squeue.html squeue] para conocer por ejemplo el estado, tiempo de ejecución e identificador de los trabajos [https://wiki.nlhpc.cl/SISTEMA_GESTOR_DE_RECURSOS SLURM]
<pre>
[usuario@leftraru1 ~]$ squeue -o "%.15i %.6P %.8j %.20S %.11M %.11L %.20V %.2t %.10q %.4C %.2D %.7W %N " -S -t,-Q

JOBID PARTIT NAME START_TIME TIME TIME_LEFT SUBMIT_TIME ST QOS CPUS NO LICENSE NODELIST
12863561 general test04 2024-02-08T13:57:53 1-20:25:20 1-03:34:40 2018-07-08T13:57:26 R 120 5 1 (null) cn000
12864082 general test02 2024-02-09T10:44:15 23:38:58 2-00:21:02 2018-07-09T10:43:51 R 120 10 1 (null) cn001
12865333 general test01 2024-02-10T17:16:38 0:00 3-00:00:00 2018-07-10T09:30:22 PD 120 10 1 (null)
12865334 general test06 2024-02-10T17:49:42 0:00 3-00:00:00 2018-07-10T09:38:13 PD 120 10 1 (null)
12865335 general test09 2024-02-11T07:42:16 0:00 3-00:00:00 2018-07-10T09:28:05 PD 120 20 1 (null)
</pre>

== ¿Como monitoreo los recursos utilizados por mi tarea? ==
=== Conectándose al nodo ===
Siempre y cuando tengamos tareas corriendo en un nodo, podemos entrar en este vía SSH.

==== * uptime ====
Para conocer la carga del nodo, cuantos procesos por core existen actualmente.
<pre>
[usuario@leftraru1 ~]# ssh cn109
usuario@cn000 s password:
[usuario@cn000 ~]# uptime
10:40:59 up 27 days, 16:46, 1 user, load average: 17.04, 13.76, 13.09
</pre>

==== * User Stats ====
Este script permite revisar:

===== La memoria por core (en kb) =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh mem
00 371695616
01 373268480
02 367038464
03 363290624
04 367382528
</pre>

===== Cantidad de procesos por core =====
<pre>
[usuario@cn000 ~]$ /home/apps/nlhpc/bin/user_stats.sh load
00 1
01 2
02 1
03 1
04 1
</pre>

==== * htop ====
Es un visor de procesos en linux, basado en ncurses.
<pre>
[usuario@cn109 ~]# htop
</pre>

[[Archivo:Htop.png|no|htop]]

.

=== A través de [http://dashboard.nlhpc.cl/ Dashboard] ===
Panel de visualización del estado de los nodos. Muestra una vista rápida del estado de los nodos (de login y de cómputo) y uso general del cluster, ademas de encontrar el listado de tareas en ejecución, pendientes, históricos.

=== En el correo de notificación ===
Al terminar una tarea se adjuntan las siguientes gráficas:

==== Porcentaje de uso por core ====
[[Archivo:Correo CPU.png|no]]

==== Memoria utilizada por core ====
[[Archivo:Correo MEMxCPU.png|no]]

==== Archivo report.log ====
<pre>
job_id=12668XXX user=usuario mail=None start_time=2018-07-09T06:51:34 running_time=3:53:28 cores_total=10 nodes_raw=cn094 alarm_cpu=True alarm_memory=False watch|avg|std|ptotal=10800|30|20|50 ptcw=70 command=/home/usuario/tarea.sh nodes={'cn094': {'mem': '10000', 'cpu': [0, 2, 3, 4, 5, 6, 7, 8, 9, 10]}} alarm_count=1 last_time=1531147611 iter=2 job_cancel=None modules=[]
n=cn094

mem max:3586 resv:10000
cpu=10 avg=91.00 std=45.77 / all avg=0.00 std=0.00
cpu= 0 avg=98.19 std=44.53 / all avg=0.00 std=0.00
* cpu= 3 avg=0.56 std=0.50 / all avg=0.47 std=0.50
* cpu= 2 avg=0.86 std=0.35 / all avg=0.66 std=0.47
* cpu= 5 avg=0.64 std=0.48 / all avg=0.49 std=0.50
* cpu= 4 avg=0.53 std=0.50 / all avg=0.40 std=0.49
cpu= 7 avg=82.11 std=48.93 / all avg=0.00 std=0.00
* cpu= 6 avg=0.56 std=0.50 / all avg=0.45 std=0.50
* cpu= 9 avg=0.47 std=0.50 / all avg=0.36 std=0.48
* cpu= 8 avg=0.72 std=0.45 / all avg=0.79 std=0.41
</pre>

* En mem max:'''3586''' resv:10000 se destaca que el máximo de memoria utilizada por la tarea ha sido de 3568M
* Por cada una de los cores se despliega: el uso promedio de cada core, la desviación estándar en las últimas 3 horas / del total de tiempo de ejecución.

VLLM API con apptainer

2025-04-11T16:55:47Z

Administrador: /* Lanzar el servicio vLLM */

== Introducción ==

En el contexto del NLHPC, se ofrecen dos herramientas principales para desplegar y realizar inferencia con LLMs: Ollama y vLLM. La elección entre ambas dependerá del formato del modelo y de los requisitos específicos de la implementación:

* Ollama: Recomendado para utilizar modelos cuantizados. Recomendado para usuarios que no estén familiarizados con el despliegue de LLM’s dado la facilidad de uso que presenta la herramienta.
* vLLM: Ideal para ejecutar modelos descargados desde Hugging Face en formato <code>.safetensors</code>, ofreciendo un alto rendimiento y eficiencia. Recomendado a usuarios con experiencia en el despliegue de LLM’s, dado la gran cantidad de parámetros ajustables que presenta la herramienta.

vLLM es un motor de inferencia y servicio de LLM’s, diseñado para ofrecer alto rendimiento y eficiencia en memoria. Su arquitectura optimizada permite ejecutar modelos de lenguaje a gran escala con aceleración GPU maximizando la respuesta en inferencias. Sin embargo, su uso es complicado dada la cantidad de parámetros a tomar en cuenta para su correcta y eficiente ejecución.

En el siguiente artículo se le enseñará a:

# Desplegar el servicio de vLLM en el cluster utilizando apptainer.
# Conectarse a la API del servicio desplegado desde su computadora local.
# Utilizar la API para realizar cargas de trabajo de inferencia.

== Cargar módulo apptainer ==

Para utilizar la imagen vLLM con compatibilidad AMD carga el módulo correspondiente:

ml apptainer/1.3.6-zen4-i

== Lanzar el servicio vLLM ==

Ejemplo de script SBATCH para iniciar el servicio:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J vllm_serve
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH -c 8
#SBATCH -t 0:10:00
#SBATCH --mem=4090MB
#SBATCH -o logs/vllm_serve_%j.out
#SBATCH -e logs/vllm_serve_%j.err
#-----------------Toolchain--------------------------
ml purge
# ----------------Modulos----------------------------
ml apptainer/1.3.6-zen4-i
# ----------------Comando--------------------------
apptainer exec --rocm --fakeroot --bind /home/ai_inference_db:/home/ai_inference_db --bind /home/$USER:/home/$USER
$IMAGES/rocm6.3.2_mi210_ubuntu22.04_py3.12_vllm_0.7.1.dev103_ib.sif /bin/bash -c
export HF_HOME=/home/ai_inference_db/models/
export HF_DATASETS_CACHE=/home/ai_inference_db/data/
vllm serve gpt2 --served-model-name gpt2 --distributed-executor-backend mp --tensor-parallel-size 1 --host 0.0.0.0

== ⚠️ Consideraciones importantes ==

* Terminar el servicio de vLLM

El servicio de vLLM '''no termina''' automáticamente, recuerde siempre cancelar la tarea con <cancel>scancel</cancel> para evitar subutilización de recursos de cómputo.

* Memoria RAM

La cantidad de RAM que se está reservando debe ser acorde a la cantidad de memoria que necesita el modelo a lanzar. Se puede utilizar la siguiente fórmula para estimar el peso en GB

<cantidad de parámetros> * <cantidad de bits> / (8 * 10 ^ 9)

Por ejemplo, si su modelo tiene 14 billones de parámetros y está cuantizado a 4 bits, entonces requerirá 7GB de memoria para lanzarse, por tanto debe reservar siete o más gigabytes de memoria.

* Reserva de GPU’s

Cada GPU MI210 tiene 64 GB de memoria VRAM. Si su modelo utiliza más memoria,
entonces solicitar más GPU’s adicionales con <code>--gres</code>.

También debe agregar la flag --tensor-parallel-size <NUM_GPUS> a vllm serve.

Notar que, al solicitar más GPU’s el rendimiento en tokens/s no mejora. Además, se
recomienda pedir 8 CPU’s por GPU solicitada.

* Flags de ejecución:

vLLM cuenta con una variada gama de flags para lanzar su servicio. A continuación, la guía oficial: [https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html?ref=blog.mozilla.ai OpenAI-Compatible Server — vLLM]

* Puerto de escucha

El puerto por defecto es 8000. Se recomienda utilizar otro (ej. 1journal1434) para evitar utilizar un puerto ya desplegado.

Se especifica con:

--port <Num_puerto>

al comando <code>vllm serve</code>.

* Directorio de descarga de modelos

Los modelos se descargan automáticamente de HuggingFace Hub en el directorio <code>/home/ai_inference_db/models/</code>. Para usar y descargar modelos en su carpeta de usuario, cambie las variables de entorno:

unset HF_HOME
unset HF_DATASETS_CACHE

Ademas, si su modelo requiere permisos para utilizarse, puede realizar login a su cuenta utilizando:

huggingface-cli login

Por otro lado, puede comunicarse con el soporte de NLHPC vía tickets para solicitar el grupo <code><practica-gpu></code> y descargar modelos en la carpeta compartida.

* Uso de modelos propios

Para utilizar un modelo propio o fine tunned, se debe especificar la ruta al archivo de su modelo agregando la flag:

--model /ruta/a/tu/modelo

al comando <code>vllm serve</code>.

Notar que, si utiliza <code>.gguf</code>, el modelo debe estar en un único archivo y no dividido por partes.

== Identificar el nodo de ejecución ==

Usa <code>squeue</code> para encontrar el nodo asignado:

[usuario@leftraru2 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
38922125 mi210 vllm_serve usuario R 0:03 1 gn004

Importante recordarlo pues lo usaremos más tarde.

== Creación de túnel de acceso ==

Sabiendo el nodo en que ejecutó nuestra tarea. Crearemos un túnel de acceso desde el cluster hacia nuestra computadora. Para esto, en una nueva terminal, ejecutar cambiando los valores:

ssh usuario@leftraru.nlhpc.cl -p 4603 -L [puerto_local]:[nodo]:[puerto_vllm]

por ejemplo:

ssh intern02@leftraru.nlhpc.cl -p 4603 -L 4466:gn004:8000

Con esto podremos utilizar el <puerto_local> para lanzar consultas a la API de vLLM.

== Ejemplo de uso ==

Una vez realizado el túnel de acceso, podemos utilizar la API de vLLM en nuestra computadora personal, utilizando herramientas como Python o Curl.

He aqui una guia de uso para la [https://platform.openai.com/docs/api-reference/chat API de vLLM].

A continuación unos ejemplos:

=== Python: ===

import requests, json
url = "<http://localhost:[puerto_local]/v1/completions>"
headers = {"Content-Type": "application/json"}
payload = {
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}
response = requests.post(url, json=payload, headers=headers)
data = response.json()
print(data["choices"][0]["text"])

=== CURL: ===

curl -X POST "<http://localhost:[puerto_local]/v1/completions>" \
-H "Content-Type: application/json" \
-d '{
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}'

== TroubleShooting ==

=== ¿Por qué el modelo no carga? ===

Pueden haber múltiples razones:
# La cantidad de GPU’s solicitadas no es divisor de la cantidad de cabezas de atención del modelo. Se recomienda que la cantidad de GPU’s sea potencia de 2.
# El modelo es demasiado grande y no cabe en la cantidad de GPU’s solicitadas. Se recomienda ver la documentación del modelo en hugging face y calcular cuanto pesa. Posteriormente aumentar la cantidad de GPU’s solicitadas.
# El modelo no está descargado en la carpeta compartida <code>/home/ai_inference/db/models</code>. Cambiar la carpeta utilizando <code>unset HF_HOME</code> y <code>unset HF_CACHE</code>. Pedir el grupo <practica-gpu> al soporte NLHPC para descargar modelos en la carpeta compartida.

=== ¿Puedo utilizar modelos cuantizados en vLLM? ===

Es posible, utilizando la flag <code>--model /ruta/a/tu/modelo</code> es posible cargar un LLM en formato gguf (cuantizado). Sin embargo debe ser un único archivo.

No es lo recomendado dado que vLLM está optimizado para realizar inferencia con precisión completa o media.

== Otros Enlaces ==

[[OLLAMA API]]

[[ Diffusers ]]

[[ vLLM API con módulos de software ]]

VLLM API con apptainer

2025-04-11T16:55:34Z

Administrador: /* Cargar módulo apptainer */

== Introducción ==

En el contexto del NLHPC, se ofrecen dos herramientas principales para desplegar y realizar inferencia con LLMs: Ollama y vLLM. La elección entre ambas dependerá del formato del modelo y de los requisitos específicos de la implementación:

* Ollama: Recomendado para utilizar modelos cuantizados. Recomendado para usuarios que no estén familiarizados con el despliegue de LLM’s dado la facilidad de uso que presenta la herramienta.
* vLLM: Ideal para ejecutar modelos descargados desde Hugging Face en formato <code>.safetensors</code>, ofreciendo un alto rendimiento y eficiencia. Recomendado a usuarios con experiencia en el despliegue de LLM’s, dado la gran cantidad de parámetros ajustables que presenta la herramienta.

vLLM es un motor de inferencia y servicio de LLM’s, diseñado para ofrecer alto rendimiento y eficiencia en memoria. Su arquitectura optimizada permite ejecutar modelos de lenguaje a gran escala con aceleración GPU maximizando la respuesta en inferencias. Sin embargo, su uso es complicado dada la cantidad de parámetros a tomar en cuenta para su correcta y eficiente ejecución.

En el siguiente artículo se le enseñará a:

# Desplegar el servicio de vLLM en el cluster utilizando apptainer.
# Conectarse a la API del servicio desplegado desde su computadora local.
# Utilizar la API para realizar cargas de trabajo de inferencia.

== Cargar módulo apptainer ==

Para utilizar la imagen vLLM con compatibilidad AMD carga el módulo correspondiente:

ml apptainer/1.3.6-zen4-i

== Lanzar el servicio vLLM ==

Ejemplo de script SBATCH para iniciar el servicio:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J vllm_serve
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH -c 8
#SBATCH -t 0:10:00
#SBATCH --mem=4090MB
#SBATCH -o logs/vllm_serve_%j.out
#SBATCH -e logs/vllm_serve_%j.err
#-----------------Toolchain--------------------------
ml purge
# ----------------Modulos----------------------------
ml apptainer
# ----------------Comando--------------------------
apptainer exec --rocm --fakeroot --bind /home/ai_inference_db:/home/ai_inference_db --bind /home/$USER:/home/$USER
$IMAGES/rocm6.3.2_mi210_ubuntu22.04_py3.12_vllm_0.7.1.dev103_ib.sif /bin/bash -c
export HF_HOME=/home/ai_inference_db/models/
export HF_DATASETS_CACHE=/home/ai_inference_db/data/
vllm serve gpt2 --served-model-name gpt2 --distributed-executor-backend mp --tensor-parallel-size 1 --host 0.0.0.0

== ⚠️ Consideraciones importantes ==

* Terminar el servicio de vLLM

El servicio de vLLM '''no termina''' automáticamente, recuerde siempre cancelar la tarea con <cancel>scancel</cancel> para evitar subutilización de recursos de cómputo.

* Memoria RAM

La cantidad de RAM que se está reservando debe ser acorde a la cantidad de memoria que necesita el modelo a lanzar. Se puede utilizar la siguiente fórmula para estimar el peso en GB

<cantidad de parámetros> * <cantidad de bits> / (8 * 10 ^ 9)

Por ejemplo, si su modelo tiene 14 billones de parámetros y está cuantizado a 4 bits, entonces requerirá 7GB de memoria para lanzarse, por tanto debe reservar siete o más gigabytes de memoria.

* Reserva de GPU’s

Cada GPU MI210 tiene 64 GB de memoria VRAM. Si su modelo utiliza más memoria,
entonces solicitar más GPU’s adicionales con <code>--gres</code>.

También debe agregar la flag --tensor-parallel-size <NUM_GPUS> a vllm serve.

Notar que, al solicitar más GPU’s el rendimiento en tokens/s no mejora. Además, se
recomienda pedir 8 CPU’s por GPU solicitada.

* Flags de ejecución:

vLLM cuenta con una variada gama de flags para lanzar su servicio. A continuación, la guía oficial: [https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html?ref=blog.mozilla.ai OpenAI-Compatible Server — vLLM]

* Puerto de escucha

El puerto por defecto es 8000. Se recomienda utilizar otro (ej. 1journal1434) para evitar utilizar un puerto ya desplegado.

Se especifica con:

--port <Num_puerto>

al comando <code>vllm serve</code>.

* Directorio de descarga de modelos

Los modelos se descargan automáticamente de HuggingFace Hub en el directorio <code>/home/ai_inference_db/models/</code>. Para usar y descargar modelos en su carpeta de usuario, cambie las variables de entorno:

unset HF_HOME
unset HF_DATASETS_CACHE

Ademas, si su modelo requiere permisos para utilizarse, puede realizar login a su cuenta utilizando:

huggingface-cli login

Por otro lado, puede comunicarse con el soporte de NLHPC vía tickets para solicitar el grupo <code><practica-gpu></code> y descargar modelos en la carpeta compartida.

* Uso de modelos propios

Para utilizar un modelo propio o fine tunned, se debe especificar la ruta al archivo de su modelo agregando la flag:

--model /ruta/a/tu/modelo

al comando <code>vllm serve</code>.

Notar que, si utiliza <code>.gguf</code>, el modelo debe estar en un único archivo y no dividido por partes.

== Identificar el nodo de ejecución ==

Usa <code>squeue</code> para encontrar el nodo asignado:

[usuario@leftraru2 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
38922125 mi210 vllm_serve usuario R 0:03 1 gn004

Importante recordarlo pues lo usaremos más tarde.

== Creación de túnel de acceso ==

Sabiendo el nodo en que ejecutó nuestra tarea. Crearemos un túnel de acceso desde el cluster hacia nuestra computadora. Para esto, en una nueva terminal, ejecutar cambiando los valores:

ssh usuario@leftraru.nlhpc.cl -p 4603 -L [puerto_local]:[nodo]:[puerto_vllm]

por ejemplo:

ssh intern02@leftraru.nlhpc.cl -p 4603 -L 4466:gn004:8000

Con esto podremos utilizar el <puerto_local> para lanzar consultas a la API de vLLM.

== Ejemplo de uso ==

Una vez realizado el túnel de acceso, podemos utilizar la API de vLLM en nuestra computadora personal, utilizando herramientas como Python o Curl.

He aqui una guia de uso para la [https://platform.openai.com/docs/api-reference/chat API de vLLM].

A continuación unos ejemplos:

=== Python: ===

import requests, json
url = "<http://localhost:[puerto_local]/v1/completions>"
headers = {"Content-Type": "application/json"}
payload = {
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}
response = requests.post(url, json=payload, headers=headers)
data = response.json()
print(data["choices"][0]["text"])

=== CURL: ===

curl -X POST "<http://localhost:[puerto_local]/v1/completions>" \
-H "Content-Type: application/json" \
-d '{
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}'

== TroubleShooting ==

=== ¿Por qué el modelo no carga? ===

Pueden haber múltiples razones:
# La cantidad de GPU’s solicitadas no es divisor de la cantidad de cabezas de atención del modelo. Se recomienda que la cantidad de GPU’s sea potencia de 2.
# El modelo es demasiado grande y no cabe en la cantidad de GPU’s solicitadas. Se recomienda ver la documentación del modelo en hugging face y calcular cuanto pesa. Posteriormente aumentar la cantidad de GPU’s solicitadas.
# El modelo no está descargado en la carpeta compartida <code>/home/ai_inference/db/models</code>. Cambiar la carpeta utilizando <code>unset HF_HOME</code> y <code>unset HF_CACHE</code>. Pedir el grupo <practica-gpu> al soporte NLHPC para descargar modelos en la carpeta compartida.

=== ¿Puedo utilizar modelos cuantizados en vLLM? ===

Es posible, utilizando la flag <code>--model /ruta/a/tu/modelo</code> es posible cargar un LLM en formato gguf (cuantizado). Sin embargo debe ser un único archivo.

No es lo recomendado dado que vLLM está optimizado para realizar inferencia con precisión completa o media.

== Otros Enlaces ==

[[OLLAMA API]]

[[ Diffusers ]]

[[ vLLM API con módulos de software ]]

VASP

2025-04-09T13:58:02Z

Administrador: /* Script de Ejemplo (128 núcleos) */

== ¿Qué es? ==

VASP (Vienna Ab initio Simulation Package) es un paquete de mecánica cuántica para simulaciones de dinámica molecular a nivel ab initio, utilizando pseudopotenciales o el método Projector-Augmented Wave (PAW) y una base de ondas planas.

La metodología usada en este software se basa en la aproximación local de la densidad (LDA) y una evaluación exacta del estado fundamental en cada paso de la dinámica molecul
== Modulos ==

VASP se encuentra disponible en varias versiones, tanto para infraestructura INTEL como para AMD.

Las últimas versiones disponibles son:

* 6.2.1
* 6.3.2
* 6.4.3

Puede buscar las versiones de VASP para intel ejecutando:

<pre>
intelsoftware
ml spider VASP
</pre>

Y para buscar las versiones de AMD puede ejecutar:

<pre>
amdsoftware
ml spider vasp
</pre>

== Definir entorno ==
En el archivo INCAR configuramos las siguientes variables respecto a la reserva que hagamos para tener idealmente de 1 átomo por core.

<pre>
NPAR = 5 #cantidad de nodos
NCORE = 20 #cantidad de cores por nodo

#evitar exceso de carga en I/O
LWAVE = .FALSE.
LCHARG = .FALSE.
LVTOT = .FALSE.
</pre>
== Ejemplo de Lanzador ==

=== Para INTEL ===
Ejemplo de SBATCH para enviar a particiones ''general'' y ''largemem'':

<pre>
#!/bin/bash
#SBATCH -J ejemplo
#SBATCH -p general
#SBATCH -n 88
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4200
#SBATCH --mail-user=usuario@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o %j_%x.out
#SBATCH -e %j_%x.err

ml purge
ml intel/2022.00
ml VASP/6.3.2

export OMP_NUM_THREADS=1
export MKL_NUM_THREADS=1
export MKL_DYNAMIC=FALSE

#vasp_std for standard NVT calculation and non-gamma k-points
#vasp_gam for standard NVT calculation and only gamma-point
#vasp_ncl for NPT ensemble and non-gamma-point calculations

EXEC=vasp_gam
BINVASP="${EXEC}"
export BINVASP
srun $BINVASP
</pre>

=== Para AMD ===
El siguiente ejemplo muestra la versión de VASP 6.4.3 para ser ejecutada en un nodo de la partición '''main'''.

Es importante destacar que al momemento de cargar estos módulos se generan avisos de tipo ''Warning'', por lo que se recomienda monitorear la tarea y su comportamiento.

<pre>
#!/bin/bash
#SBATCH --job-name="TareaVASP"
#SBATCH --partition="main"
#SBATCH -n 1
#SBATCH -c 256
#SBATCH --mem-per-cpu=2839
##SBATCH --ntasks-per-node=64

#SBATCH --output=TareaVASP-%j.out #
#SBATCH --mail-type=ALL

ml aocc
ml openmpi/5.0.5-zen4-j
ml amdfftw/4.2-mpi-openmp-zen4-tjgyk3c
ml vasp/6.4.3-mpi-openmp-zen4-e

export OMPI_MCA_mtl=ofi
export OMP_NUM_THREADS=256
export OMP_PLACES=cores

srun vasp_std
</pre>

==== Pruebas y recomendaciones de ejecución AMD ====
Los ejemplos descritos a continuación describen la configuración recomendada para ejecutar simulaciones con VASP (Vienna Ab initio Simulation Package) de manera eficiente (procesos) utilizando el paradigma MPI por sobre OpenMP o configuraciones híbridas (MPI + OpenMP)..

A continuación, compartimos configuraciones recomendadas para distintos números de núcleos, que podrían ser útiles para mejorar el rendimiento de tus simulaciones.

=====Script de Ejemplo (24 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 24 # Total de procesos MPI
#SBATCH --ntasks-per-node=24 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=30000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 6
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (64 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 64 # Total de procesos MPI
#SBATCH --ntasks-per-node=64 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=60000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 16
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (128 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 128 # Total de procesos MPI
#SBATCH --ntasks-per-node=128 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=90000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 32
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

====Recomendaciones Adicionales====

=====Optimización de NPAR y KPAR=====

{| class="wikitable" style="width: 80%; margin: 1em auto;"
! style="background-color: #d9edf7; text-align: center;" | Núcleos
! style="background-color: #d9edf7; text-align: center;" | NPAR
! style="background-color: #d9edf7; text-align: center;" | KPAR
! style="background-color: #d9edf7; text-align: center;" | Notas
|-
| style="text-align: center;" | 24
| style="text-align: center;" | 6
| style="text-align: center;" | 4
| rowspan="3" style="padding: 10px;" | '''Regla general''':<br><code>NPAR × KPAR ≈ Núcleos totales</code><br><br>'''Ejemplo para 24 nucleos''':<br>6 × 4 = 24 (configuración óptima)<br><br>'''Alternativa''':<br>8 × 8 = 64 (Configuración alternativa)
|-
| style="text-align: center;" | 64
| style="text-align: center;" | 16
| style="text-align: center;" | 4
|-
| style="text-align: center;" | 128
| style="text-align: center;" | 32
| style="text-align: center;" | 4
|}

===== Evitar OpenMP e Hibrido =====
<div style="background-color: #FFF3F3; border-left: 4px solid #FF8080; padding: 0.5em 1em; margin: 1em 0;">
'''Nota importante''': Las pruebas muestran que '''MPI puro''' es significativamente más rápido que configuraciones híbridas (MPI + OpenMP) o solo OpenMP.
</div>

===== Monitoreo de Rendimiento =====
'''Pasos recomendados''':
# Verificar el archivo <code>OUTCAR</code> (buscar "Maximum memory used")
# Ajustar <code>NPAR</code>/<code>KPAR</code> si se observan:
:* Cuellos de botella en E/S
:* Problemas de comunicación
:* Bajo rendimiento

<div style="background-color: #F0F8FF; border-left: 4px solid #4682B4; padding: 0.5em 1em; margin: 1em 0;">
'''Tip''': Para sistemas grandes (>200 átomos), considerar aumentar NPAR en un 10-20%.
</div>

== Uso de software licenciado ==

El uso de este software está restringido a los usuarios que dispongan de una licencia válida de VASP, la cual deben enviar al correo de soporte.

== Referencias ==
* [https://www.vasp.at/ The VASP site]
* [https://www.pdc.kth.se/software/software/VASP/cpe21.11/6.2.1-vanilla/index_using.html How to use VASP]
* [https://hpc-uit.readthedocs.io/en/latest/applications/chemistry/VASP/firsttime_vasp.html First time you run a VASP job?]
* [https://wiki.bwhpc.de/e/JUSTUS2/Software/VASP VASP bwHPC]
* [https://www.vasp.at/wiki/index.php/NCORE VASP Wiki-Ncore]

VLLM API con módulos de software

2025-04-09T13:22:47Z

Administrador: /* Lanzar el servicio vLLM */

== Introducción ==

En el contexto del NLHPC, se ofrecen dos herramientas principales para desplegar y realizar inferencia con LLMs: Ollama y vLLM. La elección entre ambas dependerá del formato del modelo y de los requisitos específicos de la implementación:

* Ollama: Recomendado para utilizar modelos cuantizados. Recomendado para usuarios que no estén familiarizados con el despliegue de LLM’s dado la facilidad de uso que presenta la herramienta.
* vLLM: Ideal para ejecutar modelos descargados desde Hugging Face en formato <code>.safetensors</code>, ofreciendo un alto rendimiento y eficiencia. Recomendado a usuarios con experiencia en el despliegue de LLM’s, dado la gran cantidad de parámetros ajustables que presenta la herramienta.

vLLM es un motor de inferencia y servicio de LLM’s, diseñado para ofrecer alto rendimiento y eficiencia en memoria. Su arquitectura optimizada permite ejecutar modelos de lenguaje a gran escala con aceleración GPU maximizando la respuesta en inferencias. Sin embargo, su uso es complicado dada la cantidad de parámetros a tomar en cuenta para su correcta ejecución.

En el siguiente artículo se le enseñará a:

# Desplegar el servicio de vLLM en el cluster utilizando módulos de software.
# Conectarse a la API del servicio desplegado desde su computadora local.
# Utilizar la API para realizar cargas de trabajo de inferencia.

== Cargar módulo vLLM ==

Para utilizar vLLM con compatibilidad AMD realiza el export del MODULEPATH y luego carga el módulo correspondiente:
export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack/linux-rocky9-x86_64/aocc/5.0.0

ml ai-inference

El cual contiene todos paquetes de software necesarios para realizar inferencia con modelos de difusión y LLM’s.

Entre los paquetes se encuentran:

* Pytorch,
* Ollama,
* vLLM,
* diffusers,
* huggingface-cli,
* transformers,
* etc

== Lanzar el servicio vLLM ==

Ejemplo de script SBATCH para iniciar el servicio:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J vllm_serve
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH -c 8
#SBATCH -t 0:10:00
#SBATCH --mem=4090MB
#SBATCH -o logs/vllm_serve_%j.out
#SBATCH -e logs/vllm_serve_%j.err
#-----------------Toolchain--------------------------
ml purge
# ----------------Modulos----------------------------
export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack /linux-rocky9-x86_64/aocc/5.0.0
ml ai-inference
# ----------------Comando--------------------------
vllm serve gpt2 --served-model-name gpt2 --distributed-executor-backend mp --tensor-parallel-size 1 --host 0.0.0.0

== ⚠️ Consideraciones importantes ==

* Terminar el servicio de vLLM

El servicio de vLLM '''no termina automáticamente''', recuerde siempre cancelar la tarea con <code>scancel</code> para evitar subutilización de recursos de cómputo

* Memoria RAM

La cantidad de RAM que se está reservando debe ser acorde a la cantidad de memoria que necesita el modelo a lanzar. Se puede utilizar la siguiente fórmula para estimar el peso en GB

<cantidad de parámetros> * <cantidad de bits> / (8 * 10 ^ 9)

Por ejemplo, si su modelo tiene 14 billones de parámetros y está cuantizado a 4 bits, entonces requerirá 7GB de memoria para lanzarse, por tanto debe reservar siete o más gigabytes de memoria.

* Reserva de GPU’s

Cada GPU MI210 tiene 64 GB de memoria VRAM. Si su modelo utiliza más memoria, entonces solicitar más GPU’s adicionales con <code>--gres</code>.

También debe agregar la flag <code>--tensor-parallel-size <NUM_GPUS></code> a <code>vllm serve</code>.

Notar que, al solicitar más GPU’s el rendimiento en tokens/s no mejora. Además, se recomienda pedir 8 CPU’s por GPU solicitada.

* Flags de ejecución

vLLM cuenta con una variada gama de flags para lanzar su servicio. A continuación, la guía oficial: [https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html?ref=blog.mozilla.ai OpenAI-Compatible Server — vLLM].

* Puerto de escucha

El puerto por defecto es 8000. Se recomienda utilizar otro (ej. 11434) para evitar utilizar un
puerto ya desplegado.

Se especifica con:

--port <Num_puerto>

al comando <code>vllm serve</code>.

* Directorio de descarga de modelos

Los modelos se descargan automáticamente de HuggingFace Hub en el directorio <code>/home/ai_inference_db/models/</code>. Para usar y descargar modelos en su carpeta de usuario, cambie las variables de entorno:

unset HF_HOME
unset HF_DATASETS_CACHE

Además, si su modelo requiere permisos para utilizarse, puede realizar login a su cuenta utilizando:

huggingface-cli login

Por otro lado, puede comunicarse con el soporte de NLHPC vía tickets para solicitar el grupo <practica-gpu> y descargar modelos en la carpeta compartida.

* Uso de modelos propios

Para utilizar un modelo propio o fine tunned, se debe especificar la ruta al archivo de su modelo agregando la flag <code>--model /ruta/a/tu/modelo</code> al comando <code>vllm serve</code>.

Notar que, si utiliza <code>.gguf</code>, el modelo debe estar en un único archivo y no dividido por partes.

== Identificar el nodo de ejecución ==

Usa squeue para encontrar el nodo asignado:

[usuario@leftraru2 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
38922125 mi210 vllm_serve usuario R 0:03 1 gn004

Importante recordarlo pues lo usaremos más tarde.

== Creación de túnel de acceso ==

Sabiendo el nodo en que ejecutó nuestra tarea. Crearemos un túnel de acceso desde el cluster hacia nuestra computadora. Para esto, en una nueva terminal, ejecutar cambiando los valores:

ssh usuario@leftraru.nlhpc.cl -p 4603 -L [puerto_local]:[nodo]:[puerto_vllm]

por ejemplo:

ssh intern02@leftraru.nlhpc.cl -p 4603 -L 4466:gn004:8000

Con esto podremos utilizar el <puerto_local> para lanzar consultas a la API de vLLM

== Ejemplo de uso ==

Una vez realizado el túnel de acceso, podemos utilizar la API de vLLM en nuestra computadora personal, utilizando herramientas como Python o Curl.

He aqui una guia de uso para la [https://platform.openai.com/docs/api-reference/chat API de vLLM].

A continuación unos ejemplos:

=== Python ===

import requests, json
url = "<http://localhost:[puerto_local]/v1/completions>"
headers = {"Content-Type": "application/json"}
payload = {
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}
response = requests.post(url, json=payload, headers=headers)
data = response.json()
print(data["choices"][0]["text"])

=== CURL ===

curl -X POST "<http://localhost:[puerto_local]/v1/completions>" \
-H "Content-Type: application/json" \
squeue-d '{
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}'

== TroubleShooting ==

* ¿Por qué el modelo no carga?

Pueden haber múltiples razones:

# La cantidad de GPU’s solicitadas no es divisor de la cantidad de cabezas de atención del modelo. Se recomienda que la cantidad de GPU’s sea potencia de 2.
# El modelo es demasiado grande y no cabe en la cantidad de GPU’s solicitadas. Se recomienda ver la documentación del modelo en hugging face y calcular cuanto pesa. Posteriormente aumentar la cantidad de GPU’s solicitadas.
# El modelo no está descargado en la carpeta compartida <code>/home/ai_inference/db/models</code>. Cambiar la carpeta utilizando <code>unset HF_HOME</code> y <code>unset HF_CACHE</code>. Pedir el grupo <practica-gpu> a soporte NLHPC para descargar modelos en la carpeta compartida.

* ¿Puedo utilizar modelos cuantizados en vLLM?

Es posible, utilizando la flag <code>--model /ruta/a/tu/modelo</code> es posible cargar un LLM en formato gguf (cuantizado). Sin embargo debe ser un único archivo.

No es lo recomendado dado que vLLM está optimizado para realizar inferencia con precisión completa o media.

== Otros Enlaces ==

[[OLLAMA API]]

[[VLLM API con módulos de software]]

[[VLLM API con apptainer]]

[[ Diffusers ]]

VLLM API con módulos de software

2025-04-09T13:22:32Z

Administrador: /* Lanzar el servicio vLLM */

== Introducción ==

En el contexto del NLHPC, se ofrecen dos herramientas principales para desplegar y realizar inferencia con LLMs: Ollama y vLLM. La elección entre ambas dependerá del formato del modelo y de los requisitos específicos de la implementación:

* Ollama: Recomendado para utilizar modelos cuantizados. Recomendado para usuarios que no estén familiarizados con el despliegue de LLM’s dado la facilidad de uso que presenta la herramienta.
* vLLM: Ideal para ejecutar modelos descargados desde Hugging Face en formato <code>.safetensors</code>, ofreciendo un alto rendimiento y eficiencia. Recomendado a usuarios con experiencia en el despliegue de LLM’s, dado la gran cantidad de parámetros ajustables que presenta la herramienta.

vLLM es un motor de inferencia y servicio de LLM’s, diseñado para ofrecer alto rendimiento y eficiencia en memoria. Su arquitectura optimizada permite ejecutar modelos de lenguaje a gran escala con aceleración GPU maximizando la respuesta en inferencias. Sin embargo, su uso es complicado dada la cantidad de parámetros a tomar en cuenta para su correcta ejecución.

En el siguiente artículo se le enseñará a:

# Desplegar el servicio de vLLM en el cluster utilizando módulos de software.
# Conectarse a la API del servicio desplegado desde su computadora local.
# Utilizar la API para realizar cargas de trabajo de inferencia.

== Cargar módulo vLLM ==

Para utilizar vLLM con compatibilidad AMD realiza el export del MODULEPATH y luego carga el módulo correspondiente:
export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack/linux-rocky9-x86_64/aocc/5.0.0

ml ai-inference

El cual contiene todos paquetes de software necesarios para realizar inferencia con modelos de difusión y LLM’s.

Entre los paquetes se encuentran:

* Pytorch,
* Ollama,
* vLLM,
* diffusers,
* huggingface-cli,
* transformers,
* etc

== Lanzar el servicio vLLM ==

Ejemplo de script SBATCH para iniciar el servicio:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J vllm_serve
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH -c 8
#SBATCH -t 0:10:00
#SBATCH --mem=4090MB
#SBATCH -o logs/vllm_serve_%j.out
#SBATCH -e logs/vllm_serve_%j.err
#-----------------Toolchain--------------------------
ml purge
# ----------------Modulos----------------------------
export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack /linux-rocky9-x86_64/aocc/5.0.0

ml ai-inference
# ----------------Comando--------------------------
vllm serve gpt2 --served-model-name gpt2 --distributed-executor-backend mp --tensor-parallel-size 1 --host 0.0.0.0

== ⚠️ Consideraciones importantes ==

* Terminar el servicio de vLLM

El servicio de vLLM '''no termina automáticamente''', recuerde siempre cancelar la tarea con <code>scancel</code> para evitar subutilización de recursos de cómputo

* Memoria RAM

La cantidad de RAM que se está reservando debe ser acorde a la cantidad de memoria que necesita el modelo a lanzar. Se puede utilizar la siguiente fórmula para estimar el peso en GB

<cantidad de parámetros> * <cantidad de bits> / (8 * 10 ^ 9)

Por ejemplo, si su modelo tiene 14 billones de parámetros y está cuantizado a 4 bits, entonces requerirá 7GB de memoria para lanzarse, por tanto debe reservar siete o más gigabytes de memoria.

* Reserva de GPU’s

Cada GPU MI210 tiene 64 GB de memoria VRAM. Si su modelo utiliza más memoria, entonces solicitar más GPU’s adicionales con <code>--gres</code>.

También debe agregar la flag <code>--tensor-parallel-size <NUM_GPUS></code> a <code>vllm serve</code>.

Notar que, al solicitar más GPU’s el rendimiento en tokens/s no mejora. Además, se recomienda pedir 8 CPU’s por GPU solicitada.

* Flags de ejecución

vLLM cuenta con una variada gama de flags para lanzar su servicio. A continuación, la guía oficial: [https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html?ref=blog.mozilla.ai OpenAI-Compatible Server — vLLM].

* Puerto de escucha

El puerto por defecto es 8000. Se recomienda utilizar otro (ej. 11434) para evitar utilizar un
puerto ya desplegado.

Se especifica con:

--port <Num_puerto>

al comando <code>vllm serve</code>.

* Directorio de descarga de modelos

Los modelos se descargan automáticamente de HuggingFace Hub en el directorio <code>/home/ai_inference_db/models/</code>. Para usar y descargar modelos en su carpeta de usuario, cambie las variables de entorno:

unset HF_HOME
unset HF_DATASETS_CACHE

Además, si su modelo requiere permisos para utilizarse, puede realizar login a su cuenta utilizando:

huggingface-cli login

Por otro lado, puede comunicarse con el soporte de NLHPC vía tickets para solicitar el grupo <practica-gpu> y descargar modelos en la carpeta compartida.

* Uso de modelos propios

Para utilizar un modelo propio o fine tunned, se debe especificar la ruta al archivo de su modelo agregando la flag <code>--model /ruta/a/tu/modelo</code> al comando <code>vllm serve</code>.

Notar que, si utiliza <code>.gguf</code>, el modelo debe estar en un único archivo y no dividido por partes.

== Identificar el nodo de ejecución ==

Usa squeue para encontrar el nodo asignado:

[usuario@leftraru2 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
38922125 mi210 vllm_serve usuario R 0:03 1 gn004

Importante recordarlo pues lo usaremos más tarde.

== Creación de túnel de acceso ==

Sabiendo el nodo en que ejecutó nuestra tarea. Crearemos un túnel de acceso desde el cluster hacia nuestra computadora. Para esto, en una nueva terminal, ejecutar cambiando los valores:

ssh usuario@leftraru.nlhpc.cl -p 4603 -L [puerto_local]:[nodo]:[puerto_vllm]

por ejemplo:

ssh intern02@leftraru.nlhpc.cl -p 4603 -L 4466:gn004:8000

Con esto podremos utilizar el <puerto_local> para lanzar consultas a la API de vLLM

== Ejemplo de uso ==

Una vez realizado el túnel de acceso, podemos utilizar la API de vLLM en nuestra computadora personal, utilizando herramientas como Python o Curl.

He aqui una guia de uso para la [https://platform.openai.com/docs/api-reference/chat API de vLLM].

A continuación unos ejemplos:

=== Python ===

import requests, json
url = "<http://localhost:[puerto_local]/v1/completions>"
headers = {"Content-Type": "application/json"}
payload = {
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}
response = requests.post(url, json=payload, headers=headers)
data = response.json()
print(data["choices"][0]["text"])

=== CURL ===

curl -X POST "<http://localhost:[puerto_local]/v1/completions>" \
-H "Content-Type: application/json" \
squeue-d '{
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}'

== TroubleShooting ==

* ¿Por qué el modelo no carga?

Pueden haber múltiples razones:

# La cantidad de GPU’s solicitadas no es divisor de la cantidad de cabezas de atención del modelo. Se recomienda que la cantidad de GPU’s sea potencia de 2.
# El modelo es demasiado grande y no cabe en la cantidad de GPU’s solicitadas. Se recomienda ver la documentación del modelo en hugging face y calcular cuanto pesa. Posteriormente aumentar la cantidad de GPU’s solicitadas.
# El modelo no está descargado en la carpeta compartida <code>/home/ai_inference/db/models</code>. Cambiar la carpeta utilizando <code>unset HF_HOME</code> y <code>unset HF_CACHE</code>. Pedir el grupo <practica-gpu> a soporte NLHPC para descargar modelos en la carpeta compartida.

* ¿Puedo utilizar modelos cuantizados en vLLM?

Es posible, utilizando la flag <code>--model /ruta/a/tu/modelo</code> es posible cargar un LLM en formato gguf (cuantizado). Sin embargo debe ser un único archivo.

No es lo recomendado dado que vLLM está optimizado para realizar inferencia con precisión completa o media.

== Otros Enlaces ==

[[OLLAMA API]]

[[VLLM API con módulos de software]]

[[VLLM API con apptainer]]

[[ Diffusers ]]

VLLM API con módulos de software

2025-04-09T13:20:43Z

Administrador: /* Cargar módulo vLLM */

== Introducción ==

En el contexto del NLHPC, se ofrecen dos herramientas principales para desplegar y realizar inferencia con LLMs: Ollama y vLLM. La elección entre ambas dependerá del formato del modelo y de los requisitos específicos de la implementación:

* Ollama: Recomendado para utilizar modelos cuantizados. Recomendado para usuarios que no estén familiarizados con el despliegue de LLM’s dado la facilidad de uso que presenta la herramienta.
* vLLM: Ideal para ejecutar modelos descargados desde Hugging Face en formato <code>.safetensors</code>, ofreciendo un alto rendimiento y eficiencia. Recomendado a usuarios con experiencia en el despliegue de LLM’s, dado la gran cantidad de parámetros ajustables que presenta la herramienta.

vLLM es un motor de inferencia y servicio de LLM’s, diseñado para ofrecer alto rendimiento y eficiencia en memoria. Su arquitectura optimizada permite ejecutar modelos de lenguaje a gran escala con aceleración GPU maximizando la respuesta en inferencias. Sin embargo, su uso es complicado dada la cantidad de parámetros a tomar en cuenta para su correcta ejecución.

En el siguiente artículo se le enseñará a:

# Desplegar el servicio de vLLM en el cluster utilizando módulos de software.
# Conectarse a la API del servicio desplegado desde su computadora local.
# Utilizar la API para realizar cargas de trabajo de inferencia.

== Cargar módulo vLLM ==

Para utilizar vLLM con compatibilidad AMD realiza el export del MODULEPATH y luego carga el módulo correspondiente:
export MODULEPATH=/home/lmod/modules/all/spack/linux-rocky9-x86_64/openmpi/5.0.6-54a6qv3/aocc/5.0.0:/home/lmod/modules/all/spack/linux-rocky9-x86_64/aocc/5.0.0

ml ai-inference

El cual contiene todos paquetes de software necesarios para realizar inferencia con modelos de difusión y LLM’s.

Entre los paquetes se encuentran:

* Pytorch,
* Ollama,
* vLLM,
* diffusers,
* huggingface-cli,
* transformers,
* etc

== Lanzar el servicio vLLM ==

Ejemplo de script SBATCH para iniciar el servicio:

#!/bin/bash
#---------------Script SBATCH - NLHPC ----------------
#SBATCH -J vllm_serve
#SBATCH -p mi210
#SBATCH --gres=gpu:1
#SBATCH -n 1
#SBATCH --ntasks-per-node=1
#SBATCH -c 8
#SBATCH -t 0:10:00
#SBATCH --mem=4090MB
#SBATCH -o logs/vllm_serve_%j.out
#SBATCH -e logs/vllm_serve_%j.err
#-----------------Toolchain--------------------------
ml purge
# ----------------Modulos----------------------------
ml ai-inference
# ----------------Comando--------------------------
vllm serve gpt2 --served-model-name gpt2 --distributed-executor-backend mp --tensor-parallel-size 1 --host 0.0.0.0

== ⚠️ Consideraciones importantes ==

* Terminar el servicio de vLLM

El servicio de vLLM '''no termina automáticamente''', recuerde siempre cancelar la tarea con <code>scancel</code> para evitar subutilización de recursos de cómputo

* Memoria RAM

La cantidad de RAM que se está reservando debe ser acorde a la cantidad de memoria que necesita el modelo a lanzar. Se puede utilizar la siguiente fórmula para estimar el peso en GB

<cantidad de parámetros> * <cantidad de bits> / (8 * 10 ^ 9)

Por ejemplo, si su modelo tiene 14 billones de parámetros y está cuantizado a 4 bits, entonces requerirá 7GB de memoria para lanzarse, por tanto debe reservar siete o más gigabytes de memoria.

* Reserva de GPU’s

Cada GPU MI210 tiene 64 GB de memoria VRAM. Si su modelo utiliza más memoria, entonces solicitar más GPU’s adicionales con <code>--gres</code>.

También debe agregar la flag <code>--tensor-parallel-size <NUM_GPUS></code> a <code>vllm serve</code>.

Notar que, al solicitar más GPU’s el rendimiento en tokens/s no mejora. Además, se recomienda pedir 8 CPU’s por GPU solicitada.

* Flags de ejecución

vLLM cuenta con una variada gama de flags para lanzar su servicio. A continuación, la guía oficial: [https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html?ref=blog.mozilla.ai OpenAI-Compatible Server — vLLM].

* Puerto de escucha

El puerto por defecto es 8000. Se recomienda utilizar otro (ej. 11434) para evitar utilizar un
puerto ya desplegado.

Se especifica con:

--port <Num_puerto>

al comando <code>vllm serve</code>.

* Directorio de descarga de modelos

Los modelos se descargan automáticamente de HuggingFace Hub en el directorio <code>/home/ai_inference_db/models/</code>. Para usar y descargar modelos en su carpeta de usuario, cambie las variables de entorno:

unset HF_HOME
unset HF_DATASETS_CACHE

Además, si su modelo requiere permisos para utilizarse, puede realizar login a su cuenta utilizando:

huggingface-cli login

Por otro lado, puede comunicarse con el soporte de NLHPC vía tickets para solicitar el grupo <practica-gpu> y descargar modelos en la carpeta compartida.

* Uso de modelos propios

Para utilizar un modelo propio o fine tunned, se debe especificar la ruta al archivo de su modelo agregando la flag <code>--model /ruta/a/tu/modelo</code> al comando <code>vllm serve</code>.

Notar que, si utiliza <code>.gguf</code>, el modelo debe estar en un único archivo y no dividido por partes.

== Identificar el nodo de ejecución ==

Usa squeue para encontrar el nodo asignado:

[usuario@leftraru2 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
38922125 mi210 vllm_serve usuario R 0:03 1 gn004

Importante recordarlo pues lo usaremos más tarde.

== Creación de túnel de acceso ==

Sabiendo el nodo en que ejecutó nuestra tarea. Crearemos un túnel de acceso desde el cluster hacia nuestra computadora. Para esto, en una nueva terminal, ejecutar cambiando los valores:

ssh usuario@leftraru.nlhpc.cl -p 4603 -L [puerto_local]:[nodo]:[puerto_vllm]

por ejemplo:

ssh intern02@leftraru.nlhpc.cl -p 4603 -L 4466:gn004:8000

Con esto podremos utilizar el <puerto_local> para lanzar consultas a la API de vLLM

== Ejemplo de uso ==

Una vez realizado el túnel de acceso, podemos utilizar la API de vLLM en nuestra computadora personal, utilizando herramientas como Python o Curl.

He aqui una guia de uso para la [https://platform.openai.com/docs/api-reference/chat API de vLLM].

A continuación unos ejemplos:

=== Python ===

import requests, json
url = "<http://localhost:[puerto_local]/v1/completions>"
headers = {"Content-Type": "application/json"}
payload = {
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}
response = requests.post(url, json=payload, headers=headers)
data = response.json()
print(data["choices"][0]["text"])

=== CURL ===

curl -X POST "<http://localhost:[puerto_local]/v1/completions>" \
-H "Content-Type: application/json" \
squeue-d '{
"model": "[nombre_modelo]",
"prompt": "[tu_prompt]",
"max_tokens": 100,
"temperature": 0.7
}'

== TroubleShooting ==

* ¿Por qué el modelo no carga?

Pueden haber múltiples razones:

# La cantidad de GPU’s solicitadas no es divisor de la cantidad de cabezas de atención del modelo. Se recomienda que la cantidad de GPU’s sea potencia de 2.
# El modelo es demasiado grande y no cabe en la cantidad de GPU’s solicitadas. Se recomienda ver la documentación del modelo en hugging face y calcular cuanto pesa. Posteriormente aumentar la cantidad de GPU’s solicitadas.
# El modelo no está descargado en la carpeta compartida <code>/home/ai_inference/db/models</code>. Cambiar la carpeta utilizando <code>unset HF_HOME</code> y <code>unset HF_CACHE</code>. Pedir el grupo <practica-gpu> a soporte NLHPC para descargar modelos en la carpeta compartida.

* ¿Puedo utilizar modelos cuantizados en vLLM?

Es posible, utilizando la flag <code>--model /ruta/a/tu/modelo</code> es posible cargar un LLM en formato gguf (cuantizado). Sin embargo debe ser un único archivo.

No es lo recomendado dado que vLLM está optimizado para realizar inferencia con precisión completa o media.

== Otros Enlaces ==

[[OLLAMA API]]

[[VLLM API con módulos de software]]

[[VLLM API con apptainer]]

[[ Diffusers ]]

VASP

2025-04-08T19:41:02Z

Administrador: /* Script de Ejemplo (64 núcleos) */

== ¿Qué es? ==

VASP (Vienna Ab initio Simulation Package) es un paquete de mecánica cuántica para simulaciones de dinámica molecular a nivel ab initio, utilizando pseudopotenciales o el método Projector-Augmented Wave (PAW) y una base de ondas planas.

La metodología usada en este software se basa en la aproximación local de la densidad (LDA) y una evaluación exacta del estado fundamental en cada paso de la dinámica molecul
== Modulos ==

VASP se encuentra disponible en varias versiones, tanto para infraestructura INTEL como para AMD.

Las últimas versiones disponibles son:

* 6.2.1
* 6.3.2
* 6.4.3

Puede buscar las versiones de VASP para intel ejecutando:

<pre>
intelsoftware
ml spider VASP
</pre>

Y para buscar las versiones de AMD puede ejecutar:

<pre>
amdsoftware
ml spider vasp
</pre>

== Definir entorno ==
En el archivo INCAR configuramos las siguientes variables respecto a la reserva que hagamos para tener idealmente de 1 átomo por core.

<pre>
NPAR = 5 #cantidad de nodos
NCORE = 20 #cantidad de cores por nodo

#evitar exceso de carga en I/O
LWAVE = .FALSE.
LCHARG = .FALSE.
LVTOT = .FALSE.
</pre>
== Ejemplo de Lanzador ==

=== Para INTEL ===
Ejemplo de SBATCH para enviar a particiones ''general'' y ''largemem'':

<pre>
#!/bin/bash
#SBATCH -J ejemplo
#SBATCH -p general
#SBATCH -n 88
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4200
#SBATCH --mail-user=usuario@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o %j_%x.out
#SBATCH -e %j_%x.err

ml purge
ml intel/2022.00
ml VASP/6.3.2

export OMP_NUM_THREADS=1
export MKL_NUM_THREADS=1
export MKL_DYNAMIC=FALSE

#vasp_std for standard NVT calculation and non-gamma k-points
#vasp_gam for standard NVT calculation and only gamma-point
#vasp_ncl for NPT ensemble and non-gamma-point calculations

EXEC=vasp_gam
BINVASP="${EXEC}"
export BINVASP
srun $BINVASP
</pre>

=== Para AMD ===
El siguiente ejemplo muestra la versión de VASP 6.4.3 para ser ejecutada en un nodo de la partición '''main'''.

Es importante destacar que al momemento de cargar estos módulos se generan avisos de tipo ''Warning'', por lo que se recomienda monitorear la tarea y su comportamiento.

<pre>
#!/bin/bash
#SBATCH --job-name="TareaVASP"
#SBATCH --partition="main"
#SBATCH -n 1
#SBATCH -c 256
#SBATCH --mem-per-cpu=2839
##SBATCH --ntasks-per-node=64

#SBATCH --output=TareaVASP-%j.out #
#SBATCH --mail-type=ALL

ml aocc
ml openmpi/5.0.5-zen4-j
ml amdfftw/4.2-mpi-openmp-zen4-tjgyk3c
ml vasp/6.4.3-mpi-openmp-zen4-e

export OMPI_MCA_mtl=ofi
export OMP_NUM_THREADS=256
export OMP_PLACES=cores

srun vasp_std
</pre>

==== Pruebas y recomendaciones de ejecución AMD ====
Los ejemplos descritos a continuación describen la configuración recomendada para ejecutar simulaciones con VASP (Vienna Ab initio Simulation Package) de manera eficiente (procesos) utilizando el paradigma MPI por sobre OpenMP o configuraciones híbridas (MPI + OpenMP)..

A continuación, compartimos configuraciones recomendadas para distintos números de núcleos, que podrían ser útiles para mejorar el rendimiento de tus simulaciones.

=====Script de Ejemplo (24 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 24 # Total de procesos MPI
#SBATCH --ntasks-per-node=24 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=30000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 6
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (64 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 64 # Total de procesos MPI
#SBATCH --ntasks-per-node=64 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=60000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 16
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (128 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 128 # Total de procesos MPI
#SBATCH --ntasks-per-node=128 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=160000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 32
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

====Recomendaciones Adicionales====

=====Optimización de NPAR y KPAR=====

{| class="wikitable" style="width: 80%; margin: 1em auto;"
! style="background-color: #d9edf7; text-align: center;" | Núcleos
! style="background-color: #d9edf7; text-align: center;" | NPAR
! style="background-color: #d9edf7; text-align: center;" | KPAR
! style="background-color: #d9edf7; text-align: center;" | Notas
|-
| style="text-align: center;" | 24
| style="text-align: center;" | 6
| style="text-align: center;" | 4
| rowspan="3" style="padding: 10px;" | '''Regla general''':<br><code>NPAR × KPAR ≈ Núcleos totales</code><br><br>'''Ejemplo para 24 nucleos''':<br>6 × 4 = 24 (configuración óptima)<br><br>'''Alternativa''':<br>8 × 8 = 64 (Configuración alternativa)
|-
| style="text-align: center;" | 64
| style="text-align: center;" | 16
| style="text-align: center;" | 4
|-
| style="text-align: center;" | 128
| style="text-align: center;" | 32
| style="text-align: center;" | 4
|}

===== Evitar OpenMP e Hibrido =====
<div style="background-color: #FFF3F3; border-left: 4px solid #FF8080; padding: 0.5em 1em; margin: 1em 0;">
'''Nota importante''': Las pruebas muestran que '''MPI puro''' es significativamente más rápido que configuraciones híbridas (MPI + OpenMP) o solo OpenMP.
</div>

===== Monitoreo de Rendimiento =====
'''Pasos recomendados''':
# Verificar el archivo <code>OUTCAR</code> (buscar "Maximum memory used")
# Ajustar <code>NPAR</code>/<code>KPAR</code> si se observan:
:* Cuellos de botella en E/S
:* Problemas de comunicación
:* Bajo rendimiento

<div style="background-color: #F0F8FF; border-left: 4px solid #4682B4; padding: 0.5em 1em; margin: 1em 0;">
'''Tip''': Para sistemas grandes (>200 átomos), considerar aumentar NPAR en un 10-20%.
</div>

== Uso de software licenciado ==

El uso de este software está restringido a los usuarios que dispongan de una licencia válida de VASP, la cual deben enviar al correo de soporte.

== Referencias ==
* [https://www.vasp.at/ The VASP site]
* [https://www.pdc.kth.se/software/software/VASP/cpe21.11/6.2.1-vanilla/index_using.html How to use VASP]
* [https://hpc-uit.readthedocs.io/en/latest/applications/chemistry/VASP/firsttime_vasp.html First time you run a VASP job?]
* [https://wiki.bwhpc.de/e/JUSTUS2/Software/VASP VASP bwHPC]
* [https://www.vasp.at/wiki/index.php/NCORE VASP Wiki-Ncore]

VASP

2025-04-08T18:57:19Z

Administrador: /* Evitar OpenMP e Hibrido */

== ¿Qué es? ==

VASP (Vienna Ab initio Simulation Package) es un paquete de mecánica cuántica para simulaciones de dinámica molecular a nivel ab initio, utilizando pseudopotenciales o el método Projector-Augmented Wave (PAW) y una base de ondas planas.

La metodología usada en este software se basa en la aproximación local de la densidad (LDA) y una evaluación exacta del estado fundamental en cada paso de la dinámica molecul
== Modulos ==

VASP se encuentra disponible en varias versiones, tanto para infraestructura INTEL como para AMD.

Las últimas versiones disponibles son:

* 6.2.1
* 6.3.2
* 6.4.3

Puede buscar las versiones de VASP para intel ejecutando:

<pre>
intelsoftware
ml spider VASP
</pre>

Y para buscar las versiones de AMD puede ejecutar:

<pre>
amdsoftware
ml spider vasp
</pre>

== Definir entorno ==
En el archivo INCAR configuramos las siguientes variables respecto a la reserva que hagamos para tener idealmente de 1 átomo por core.

<pre>
NPAR = 5 #cantidad de nodos
NCORE = 20 #cantidad de cores por nodo

#evitar exceso de carga en I/O
LWAVE = .FALSE.
LCHARG = .FALSE.
LVTOT = .FALSE.
</pre>
== Ejemplo de Lanzador ==

=== Para INTEL ===
Ejemplo de SBATCH para enviar a particiones ''general'' y ''largemem'':

<pre>
#!/bin/bash
#SBATCH -J ejemplo
#SBATCH -p general
#SBATCH -n 88
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4200
#SBATCH --mail-user=usuario@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o %j_%x.out
#SBATCH -e %j_%x.err

ml purge
ml intel/2022.00
ml VASP/6.3.2

export OMP_NUM_THREADS=1
export MKL_NUM_THREADS=1
export MKL_DYNAMIC=FALSE

#vasp_std for standard NVT calculation and non-gamma k-points
#vasp_gam for standard NVT calculation and only gamma-point
#vasp_ncl for NPT ensemble and non-gamma-point calculations

EXEC=vasp_gam
BINVASP="${EXEC}"
export BINVASP
srun $BINVASP
</pre>

=== Para AMD ===
El siguiente ejemplo muestra la versión de VASP 6.4.3 para ser ejecutada en un nodo de la partición '''main'''.

Es importante destacar que al momemento de cargar estos módulos se generan avisos de tipo ''Warning'', por lo que se recomienda monitorear la tarea y su comportamiento.

<pre>
#!/bin/bash
#SBATCH --job-name="TareaVASP"
#SBATCH --partition="main"
#SBATCH -n 1
#SBATCH -c 256
#SBATCH --mem-per-cpu=2839
##SBATCH --ntasks-per-node=64

#SBATCH --output=TareaVASP-%j.out #
#SBATCH --mail-type=ALL

ml aocc
ml openmpi/5.0.5-zen4-j
ml amdfftw/4.2-mpi-openmp-zen4-tjgyk3c
ml vasp/6.4.3-mpi-openmp-zen4-e

export OMPI_MCA_mtl=ofi
export OMP_NUM_THREADS=256
export OMP_PLACES=cores

srun vasp_std
</pre>

==== Pruebas y recomendaciones de ejecución AMD ====
Los ejemplos descritos a continuación describen la configuración recomendada para ejecutar simulaciones con VASP (Vienna Ab initio Simulation Package) de manera eficiente (procesos) utilizando el paradigma MPI por sobre OpenMP o configuraciones híbridas (MPI + OpenMP)..

A continuación, compartimos configuraciones recomendadas para distintos números de núcleos, que podrían ser útiles para mejorar el rendimiento de tus simulaciones.

=====Script de Ejemplo (24 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 24 # Total de procesos MPI
#SBATCH --ntasks-per-node=24 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=30000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 6
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (64 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 64 # Total de procesos MPI
#SBATCH --ntasks-per-node=64 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=80000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 16
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (128 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 128 # Total de procesos MPI
#SBATCH --ntasks-per-node=128 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=160000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 32
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

====Recomendaciones Adicionales====

=====Optimización de NPAR y KPAR=====

{| class="wikitable" style="width: 80%; margin: 1em auto;"
! style="background-color: #d9edf7; text-align: center;" | Núcleos
! style="background-color: #d9edf7; text-align: center;" | NPAR
! style="background-color: #d9edf7; text-align: center;" | KPAR
! style="background-color: #d9edf7; text-align: center;" | Notas
|-
| style="text-align: center;" | 24
| style="text-align: center;" | 6
| style="text-align: center;" | 4
| rowspan="3" style="padding: 10px;" | '''Regla general''':<br><code>NPAR × KPAR ≈ Núcleos totales</code><br><br>'''Ejemplo para 24 nucleos''':<br>6 × 4 = 24 (configuración óptima)<br><br>'''Alternativa''':<br>8 × 8 = 64 (Configuración alternativa)
|-
| style="text-align: center;" | 64
| style="text-align: center;" | 16
| style="text-align: center;" | 4
|-
| style="text-align: center;" | 128
| style="text-align: center;" | 32
| style="text-align: center;" | 4
|}

===== Evitar OpenMP e Hibrido =====
<div style="background-color: #FFF3F3; border-left: 4px solid #FF8080; padding: 0.5em 1em; margin: 1em 0;">
'''Nota importante''': Las pruebas muestran que '''MPI puro''' es significativamente más rápido que configuraciones híbridas (MPI + OpenMP) o solo OpenMP.
</div>

===== Monitoreo de Rendimiento =====
'''Pasos recomendados''':
# Verificar el archivo <code>OUTCAR</code> (buscar "Maximum memory used")
# Ajustar <code>NPAR</code>/<code>KPAR</code> si se observan:
:* Cuellos de botella en E/S
:* Problemas de comunicación
:* Bajo rendimiento

<div style="background-color: #F0F8FF; border-left: 4px solid #4682B4; padding: 0.5em 1em; margin: 1em 0;">
'''Tip''': Para sistemas grandes (>200 átomos), considerar aumentar NPAR en un 10-20%.
</div>

== Uso de software licenciado ==

El uso de este software está restringido a los usuarios que dispongan de una licencia válida de VASP, la cual deben enviar al correo de soporte.

== Referencias ==
* [https://www.vasp.at/ The VASP site]
* [https://www.pdc.kth.se/software/software/VASP/cpe21.11/6.2.1-vanilla/index_using.html How to use VASP]
* [https://hpc-uit.readthedocs.io/en/latest/applications/chemistry/VASP/firsttime_vasp.html First time you run a VASP job?]
* [https://wiki.bwhpc.de/e/JUSTUS2/Software/VASP VASP bwHPC]
* [https://www.vasp.at/wiki/index.php/NCORE VASP Wiki-Ncore]

VASP

2025-04-08T18:56:58Z

Administrador: /* Monitoreo de Rendimiento */

== ¿Qué es? ==

VASP (Vienna Ab initio Simulation Package) es un paquete de mecánica cuántica para simulaciones de dinámica molecular a nivel ab initio, utilizando pseudopotenciales o el método Projector-Augmented Wave (PAW) y una base de ondas planas.

La metodología usada en este software se basa en la aproximación local de la densidad (LDA) y una evaluación exacta del estado fundamental en cada paso de la dinámica molecul
== Modulos ==

VASP se encuentra disponible en varias versiones, tanto para infraestructura INTEL como para AMD.

Las últimas versiones disponibles son:

* 6.2.1
* 6.3.2
* 6.4.3

Puede buscar las versiones de VASP para intel ejecutando:

<pre>
intelsoftware
ml spider VASP
</pre>

Y para buscar las versiones de AMD puede ejecutar:

<pre>
amdsoftware
ml spider vasp
</pre>

== Definir entorno ==
En el archivo INCAR configuramos las siguientes variables respecto a la reserva que hagamos para tener idealmente de 1 átomo por core.

<pre>
NPAR = 5 #cantidad de nodos
NCORE = 20 #cantidad de cores por nodo

#evitar exceso de carga en I/O
LWAVE = .FALSE.
LCHARG = .FALSE.
LVTOT = .FALSE.
</pre>
== Ejemplo de Lanzador ==

=== Para INTEL ===
Ejemplo de SBATCH para enviar a particiones ''general'' y ''largemem'':

<pre>
#!/bin/bash
#SBATCH -J ejemplo
#SBATCH -p general
#SBATCH -n 88
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4200
#SBATCH --mail-user=usuario@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o %j_%x.out
#SBATCH -e %j_%x.err

ml purge
ml intel/2022.00
ml VASP/6.3.2

export OMP_NUM_THREADS=1
export MKL_NUM_THREADS=1
export MKL_DYNAMIC=FALSE

#vasp_std for standard NVT calculation and non-gamma k-points
#vasp_gam for standard NVT calculation and only gamma-point
#vasp_ncl for NPT ensemble and non-gamma-point calculations

EXEC=vasp_gam
BINVASP="${EXEC}"
export BINVASP
srun $BINVASP
</pre>

=== Para AMD ===
El siguiente ejemplo muestra la versión de VASP 6.4.3 para ser ejecutada en un nodo de la partición '''main'''.

Es importante destacar que al momemento de cargar estos módulos se generan avisos de tipo ''Warning'', por lo que se recomienda monitorear la tarea y su comportamiento.

<pre>
#!/bin/bash
#SBATCH --job-name="TareaVASP"
#SBATCH --partition="main"
#SBATCH -n 1
#SBATCH -c 256
#SBATCH --mem-per-cpu=2839
##SBATCH --ntasks-per-node=64

#SBATCH --output=TareaVASP-%j.out #
#SBATCH --mail-type=ALL

ml aocc
ml openmpi/5.0.5-zen4-j
ml amdfftw/4.2-mpi-openmp-zen4-tjgyk3c
ml vasp/6.4.3-mpi-openmp-zen4-e

export OMPI_MCA_mtl=ofi
export OMP_NUM_THREADS=256
export OMP_PLACES=cores

srun vasp_std
</pre>

==== Pruebas y recomendaciones de ejecución AMD ====
Los ejemplos descritos a continuación describen la configuración recomendada para ejecutar simulaciones con VASP (Vienna Ab initio Simulation Package) de manera eficiente (procesos) utilizando el paradigma MPI por sobre OpenMP o configuraciones híbridas (MPI + OpenMP)..

A continuación, compartimos configuraciones recomendadas para distintos números de núcleos, que podrían ser útiles para mejorar el rendimiento de tus simulaciones.

=====Script de Ejemplo (24 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 24 # Total de procesos MPI
#SBATCH --ntasks-per-node=24 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=30000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 6
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (64 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 64 # Total de procesos MPI
#SBATCH --ntasks-per-node=64 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=80000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 16
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (128 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 128 # Total de procesos MPI
#SBATCH --ntasks-per-node=128 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=160000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 32
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

====Recomendaciones Adicionales====

=====Optimización de NPAR y KPAR=====

{| class="wikitable" style="width: 80%; margin: 1em auto;"
! style="background-color: #d9edf7; text-align: center;" | Núcleos
! style="background-color: #d9edf7; text-align: center;" | NPAR
! style="background-color: #d9edf7; text-align: center;" | KPAR
! style="background-color: #d9edf7; text-align: center;" | Notas
|-
| style="text-align: center;" | 24
| style="text-align: center;" | 6
| style="text-align: center;" | 4
| rowspan="3" style="padding: 10px;" | '''Regla general''':<br><code>NPAR × KPAR ≈ Núcleos totales</code><br><br>'''Ejemplo para 24 nucleos''':<br>6 × 4 = 24 (configuración óptima)<br><br>'''Alternativa''':<br>8 × 8 = 64 (Configuración alternativa)
|-
| style="text-align: center;" | 64
| style="text-align: center;" | 16
| style="text-align: center;" | 4
|-
| style="text-align: center;" | 128
| style="text-align: center;" | 32
| style="text-align: center;" | 4
|}

===== Evitar OpenMP e Hibrido =====
<div style="background-color: #FFF3F3; border-left: 4px solid #FF8080; padding: 0.5em 1em; margin: 1em 0;">
'''Nota importante''': Las pruebas muestran que '''MPI puro''' es significativamente más rápido que configuraciones híbridas (MPI + OpenMP) o solo OpenMP.
</div>

== Uso de software licenciado ==

El uso de este software está restringido a los usuarios que dispongan de una licencia válida de VASP, la cual deben enviar al correo de soporte.

== Referencias ==
* [https://www.vasp.at/ The VASP site]
* [https://www.pdc.kth.se/software/software/VASP/cpe21.11/6.2.1-vanilla/index_using.html How to use VASP]
* [https://hpc-uit.readthedocs.io/en/latest/applications/chemistry/VASP/firsttime_vasp.html First time you run a VASP job?]
* [https://wiki.bwhpc.de/e/JUSTUS2/Software/VASP VASP bwHPC]
* [https://www.vasp.at/wiki/index.php/NCORE VASP Wiki-Ncore]

VASP

2025-04-08T18:56:43Z

Administrador: /* Monitoreo de Rendimiento */

== ¿Qué es? ==

VASP (Vienna Ab initio Simulation Package) es un paquete de mecánica cuántica para simulaciones de dinámica molecular a nivel ab initio, utilizando pseudopotenciales o el método Projector-Augmented Wave (PAW) y una base de ondas planas.

La metodología usada en este software se basa en la aproximación local de la densidad (LDA) y una evaluación exacta del estado fundamental en cada paso de la dinámica molecul
== Modulos ==

VASP se encuentra disponible en varias versiones, tanto para infraestructura INTEL como para AMD.

Las últimas versiones disponibles son:

* 6.2.1
* 6.3.2
* 6.4.3

Puede buscar las versiones de VASP para intel ejecutando:

<pre>
intelsoftware
ml spider VASP
</pre>

Y para buscar las versiones de AMD puede ejecutar:

<pre>
amdsoftware
ml spider vasp
</pre>

== Definir entorno ==
En el archivo INCAR configuramos las siguientes variables respecto a la reserva que hagamos para tener idealmente de 1 átomo por core.

<pre>
NPAR = 5 #cantidad de nodos
NCORE = 20 #cantidad de cores por nodo

#evitar exceso de carga en I/O
LWAVE = .FALSE.
LCHARG = .FALSE.
LVTOT = .FALSE.
</pre>
== Ejemplo de Lanzador ==

=== Para INTEL ===
Ejemplo de SBATCH para enviar a particiones ''general'' y ''largemem'':

<pre>
#!/bin/bash
#SBATCH -J ejemplo
#SBATCH -p general
#SBATCH -n 88
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4200
#SBATCH --mail-user=usuario@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o %j_%x.out
#SBATCH -e %j_%x.err

ml purge
ml intel/2022.00
ml VASP/6.3.2

export OMP_NUM_THREADS=1
export MKL_NUM_THREADS=1
export MKL_DYNAMIC=FALSE

#vasp_std for standard NVT calculation and non-gamma k-points
#vasp_gam for standard NVT calculation and only gamma-point
#vasp_ncl for NPT ensemble and non-gamma-point calculations

EXEC=vasp_gam
BINVASP="${EXEC}"
export BINVASP
srun $BINVASP
</pre>

=== Para AMD ===
El siguiente ejemplo muestra la versión de VASP 6.4.3 para ser ejecutada en un nodo de la partición '''main'''.

Es importante destacar que al momemento de cargar estos módulos se generan avisos de tipo ''Warning'', por lo que se recomienda monitorear la tarea y su comportamiento.

<pre>
#!/bin/bash
#SBATCH --job-name="TareaVASP"
#SBATCH --partition="main"
#SBATCH -n 1
#SBATCH -c 256
#SBATCH --mem-per-cpu=2839
##SBATCH --ntasks-per-node=64

#SBATCH --output=TareaVASP-%j.out #
#SBATCH --mail-type=ALL

ml aocc
ml openmpi/5.0.5-zen4-j
ml amdfftw/4.2-mpi-openmp-zen4-tjgyk3c
ml vasp/6.4.3-mpi-openmp-zen4-e

export OMPI_MCA_mtl=ofi
export OMP_NUM_THREADS=256
export OMP_PLACES=cores

srun vasp_std
</pre>

==== Pruebas y recomendaciones de ejecución AMD ====
Los ejemplos descritos a continuación describen la configuración recomendada para ejecutar simulaciones con VASP (Vienna Ab initio Simulation Package) de manera eficiente (procesos) utilizando el paradigma MPI por sobre OpenMP o configuraciones híbridas (MPI + OpenMP)..

A continuación, compartimos configuraciones recomendadas para distintos números de núcleos, que podrían ser útiles para mejorar el rendimiento de tus simulaciones.

=====Script de Ejemplo (24 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 24 # Total de procesos MPI
#SBATCH --ntasks-per-node=24 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=30000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 6
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (64 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 64 # Total de procesos MPI
#SBATCH --ntasks-per-node=64 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=80000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 16
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (128 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 128 # Total de procesos MPI
#SBATCH --ntasks-per-node=128 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=160000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 32
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

====Recomendaciones Adicionales====

=====Optimización de NPAR y KPAR=====

{| class="wikitable" style="width: 80%; margin: 1em auto;"
! style="background-color: #d9edf7; text-align: center;" | Núcleos
! style="background-color: #d9edf7; text-align: center;" | NPAR
! style="background-color: #d9edf7; text-align: center;" | KPAR
! style="background-color: #d9edf7; text-align: center;" | Notas
|-
| style="text-align: center;" | 24
| style="text-align: center;" | 6
| style="text-align: center;" | 4
| rowspan="3" style="padding: 10px;" | '''Regla general''':<br><code>NPAR × KPAR ≈ Núcleos totales</code><br><br>'''Ejemplo para 24 nucleos''':<br>6 × 4 = 24 (configuración óptima)<br><br>'''Alternativa''':<br>8 × 8 = 64 (Configuración alternativa)
|-
| style="text-align: center;" | 64
| style="text-align: center;" | 16
| style="text-align: center;" | 4
|-
| style="text-align: center;" | 128
| style="text-align: center;" | 32
| style="text-align: center;" | 4
|}

===== Evitar OpenMP e Hibrido =====
<div style="background-color: #FFF3F3; border-left: 4px solid #FF8080; padding: 0.5em 1em; margin: 1em 0;">
'''Nota importante''': Las pruebas muestran que '''MPI puro''' es significativamente más rápido que configuraciones híbridas (MPI + OpenMP) o solo OpenMP.
</div>

== Monitoreo de Rendimiento ==
'''Pasos recomendados''':
# Verificar el archivo <code>OUTCAR</code> (buscar "Maximum memory used")
# Ajustar <code>NPAR</code>/<code>KPAR</code> si se observan:
:* Cuellos de botella en E/S
:* Problemas de comunicación
:* Bajo rendimiento

<div style="background-color: #F0F8FF; border-left: 4px solid #4682B4; padding: 0.5em 1em; margin: 1em 0;">
'''Tip''': Para sistemas grandes (>200 átomos), considerar aumentar NPAR en un 10-20%.
</div>

== Uso de software licenciado ==

El uso de este software está restringido a los usuarios que dispongan de una licencia válida de VASP, la cual deben enviar al correo de soporte.

== Referencias ==
* [https://www.vasp.at/ The VASP site]
* [https://www.pdc.kth.se/software/software/VASP/cpe21.11/6.2.1-vanilla/index_using.html How to use VASP]
* [https://hpc-uit.readthedocs.io/en/latest/applications/chemistry/VASP/firsttime_vasp.html First time you run a VASP job?]
* [https://wiki.bwhpc.de/e/JUSTUS2/Software/VASP VASP bwHPC]
* [https://www.vasp.at/wiki/index.php/NCORE VASP Wiki-Ncore]

VASP

2025-04-08T18:56:29Z

Administrador: /* Evitar OpenMP */

== ¿Qué es? ==

VASP (Vienna Ab initio Simulation Package) es un paquete de mecánica cuántica para simulaciones de dinámica molecular a nivel ab initio, utilizando pseudopotenciales o el método Projector-Augmented Wave (PAW) y una base de ondas planas.

La metodología usada en este software se basa en la aproximación local de la densidad (LDA) y una evaluación exacta del estado fundamental en cada paso de la dinámica molecul
== Modulos ==

VASP se encuentra disponible en varias versiones, tanto para infraestructura INTEL como para AMD.

Las últimas versiones disponibles son:

* 6.2.1
* 6.3.2
* 6.4.3

Puede buscar las versiones de VASP para intel ejecutando:

<pre>
intelsoftware
ml spider VASP
</pre>

Y para buscar las versiones de AMD puede ejecutar:

<pre>
amdsoftware
ml spider vasp
</pre>

== Definir entorno ==
En el archivo INCAR configuramos las siguientes variables respecto a la reserva que hagamos para tener idealmente de 1 átomo por core.

<pre>
NPAR = 5 #cantidad de nodos
NCORE = 20 #cantidad de cores por nodo

#evitar exceso de carga en I/O
LWAVE = .FALSE.
LCHARG = .FALSE.
LVTOT = .FALSE.
</pre>
== Ejemplo de Lanzador ==

=== Para INTEL ===
Ejemplo de SBATCH para enviar a particiones ''general'' y ''largemem'':

<pre>
#!/bin/bash
#SBATCH -J ejemplo
#SBATCH -p general
#SBATCH -n 88
#SBATCH --ntasks-per-node=44
#SBATCH --mem-per-cpu=4200
#SBATCH --mail-user=usuario@correo.cl
#SBATCH --mail-type=ALL
#SBATCH -o %j_%x.out
#SBATCH -e %j_%x.err

ml purge
ml intel/2022.00
ml VASP/6.3.2

export OMP_NUM_THREADS=1
export MKL_NUM_THREADS=1
export MKL_DYNAMIC=FALSE

#vasp_std for standard NVT calculation and non-gamma k-points
#vasp_gam for standard NVT calculation and only gamma-point
#vasp_ncl for NPT ensemble and non-gamma-point calculations

EXEC=vasp_gam
BINVASP="${EXEC}"
export BINVASP
srun $BINVASP
</pre>

=== Para AMD ===
El siguiente ejemplo muestra la versión de VASP 6.4.3 para ser ejecutada en un nodo de la partición '''main'''.

Es importante destacar que al momemento de cargar estos módulos se generan avisos de tipo ''Warning'', por lo que se recomienda monitorear la tarea y su comportamiento.

<pre>
#!/bin/bash
#SBATCH --job-name="TareaVASP"
#SBATCH --partition="main"
#SBATCH -n 1
#SBATCH -c 256
#SBATCH --mem-per-cpu=2839
##SBATCH --ntasks-per-node=64

#SBATCH --output=TareaVASP-%j.out #
#SBATCH --mail-type=ALL

ml aocc
ml openmpi/5.0.5-zen4-j
ml amdfftw/4.2-mpi-openmp-zen4-tjgyk3c
ml vasp/6.4.3-mpi-openmp-zen4-e

export OMPI_MCA_mtl=ofi
export OMP_NUM_THREADS=256
export OMP_PLACES=cores

srun vasp_std
</pre>

==== Pruebas y recomendaciones de ejecución AMD ====
Los ejemplos descritos a continuación describen la configuración recomendada para ejecutar simulaciones con VASP (Vienna Ab initio Simulation Package) de manera eficiente (procesos) utilizando el paradigma MPI por sobre OpenMP o configuraciones híbridas (MPI + OpenMP)..

A continuación, compartimos configuraciones recomendadas para distintos números de núcleos, que podrían ser útiles para mejorar el rendimiento de tus simulaciones.

=====Script de Ejemplo (24 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 24 # Total de procesos MPI
#SBATCH --ntasks-per-node=24 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=30000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 6
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (64 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 64 # Total de procesos MPI
#SBATCH --ntasks-per-node=64 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=80000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 16
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

=====Script de Ejemplo (128 núcleos)=====
<pre>
#!/bin/bash
#SBATCH --job-name="MPI"
#SBATCH -p main
#SBATCH -n 128 # Total de procesos MPI
#SBATCH --ntasks-per-node=128 # Procesos por nodo (ajustar según arquitectura)
#SBATCH -c 1 # 1 thread por proceso (MPI puro)
#SBATCH --mem=160000 # Memoria en MB (ajustar según necesidades)
#SBATCH --output=MiTareaVASP-log/%j.out
#SBATCH --error=MiTareaVASP-log/%j.err

# Cargar módulos necesarios
ml gcc/14.2.0-zen4-y
ml vasp/6.4.3-mpi-openmp-h5-zen4-c

# Limpiar archivos previos
rm -f DOSCAR PROCAR XDATCAR OSZICAR OUTCAR vasprun.xml REPORT

# Configuración MPI (opcional)
export OMPI_MCA_mtl=ofi

# Medir tiempo de ejecución
echo "Inicio: $(date)"
/usr/bin/time -v srun vasp_std
echo "Fin: $(date)"
</pre>

Parámetros Clave en el INCAR
{| class="wikitable"
! style="background-color:#d9edf7;" | Parámetro
! Valor recomendado (24 núcleos)
! Descripción
|-
| style="background-color:#d9edf7;" | NPAR
| 32
| Número de bandas calculadas en paralelo.
|-
| style="background-color:#d9edf7;" | NCORE
| 1
| Evita OpenMP (MPI puro es más eficiente).
|-
| style="background-color:#d9edf7;" | KPAR
| 4
| División de la malla k-point.
|}

====Recomendaciones Adicionales====

=====Optimización de NPAR y KPAR=====

{| class="wikitable" style="width: 80%; margin: 1em auto;"
! style="background-color: #d9edf7; text-align: center;" | Núcleos
! style="background-color: #d9edf7; text-align: center;" | NPAR
! style="background-color: #d9edf7; text-align: center;" | KPAR
! style="background-color: #d9edf7; text-align: center;" | Notas
|-
| style="text-align: center;" | 24
| style="text-align: center;" | 6
| style="text-align: center;" | 4
| rowspan="3" style="padding: 10px;" | '''Regla general''':<br><code>NPAR × KPAR ≈ Núcleos totales</code><br><br>'''Ejemplo para 24 nucleos''':<br>6 × 4 = 24 (configuración óptima)<br><br>'''Alternativa''':<br>8 × 8 = 64 (Configuración alternativa)
|-
| style="text-align: center;" | 64
| style="text-align: center;" | 16
| style="text-align: center;" | 4
|-
| style="text-align: center;" | 128
| style="text-align: center;" | 32
| style="text-align: center;" | 4
|}

===== Evitar OpenMP e Hibrido =====
<div style="background-color: #FFF3F3; border-left: 4px solid #FF8080; padding: 0.5em 1em; margin: 1em 0;">
'''Nota importante''': Las pruebas muestran que '''MPI puro''' es significativamente más rápido que configuraciones híbridas (MPI + OpenMP) o solo OpenMP.
</div>

== Monitoreo de Rendimiento ==
'''Pasos recomendados''':
# Verificar el archivo <code>OUTCAR</code> (buscar "Maximum memory used")
# Ajustar <code>NPAR</code>/<code>KPAR</code> si se observan:
:* Cuellos de botella en E/S
:* Problemas de comunicación
:* Bajo rendimiento

<div style="background-color: #F0F8FF; border-left: 4px solid #4682B4; padding: 0.5em 1em; margin: 1em 0;">
'''Tip''': Para sistemas grandes (>200 átomos), considerar aumentar NPAR en un 10-20%.
</div>

== Monitoreo de Rendimiento ==
'''Pasos recomendados''':
# Verificar el archivo {{mono|OUTCAR}} (buscar "Maximum memory used")
# Ajustar {{mono|NPAR}}/{{mono|KPAR}} si se observan:
** Cuellos de botella en E/S
** Problemas de comunicación entre nodos
** Bajo rendimiento

{{tip|Para sistemas grandes (>200 átomos), considerar aumentar NPAR en un 10-20%}}

== Uso de software licenciado ==

El uso de este software está restringido a los usuarios que dispongan de una licencia válida de VASP, la cual deben enviar al correo de soporte.

== Referencias ==
* [https://www.vasp.at/ The VASP site]
* [https://www.pdc.kth.se/software/software/VASP/cpe21.11/6.2.1-vanilla/index_using.html How to use VASP]
* [https://hpc-uit.readthedocs.io/en/latest/applications/chemistry/VASP/firsttime_vasp.html First time you run a VASP job?]
* [https://wiki.bwhpc.de/e/JUSTUS2/Software/VASP VASP bwHPC]
* [https://www.vasp.at/wiki/index.php/NCORE VASP Wiki-Ncore]