Skip to content
Snippets Groups Projects
Commit 9f38a79f authored by Bruno Sime Ferreira Nunes's avatar Bruno Sime Ferreira Nunes
Browse files

Update 5 files 

- /source/components/nodes.rst
- /source/components/partitions.rst
- /source/pages/acesso.rst
- /source/pages/overview.rst
- /source/pages/quickstart.rst
parent 71e23ba6
No related branches found
No related tags found
No related merge requests found
Show whitespace changes
Inline Side-by-side
source/components/nodes.rst deleted 100644 → 0
+ 0
− 26
View file @ 71e23ba6
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| Nodo | Cores | Threads | Memória | Conexão | Dispositivos | Notas |
| | | por core | | | | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| node2 | 32 | 1 | 256 GB | IB 56 Gb/s + 1 Gb/s EHT | | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| node3 | 32 | 1 | 256 GB | IB 56 Gb/s + 1 Gb/s EHT | | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| node4 | 32 | 1 | 256 GB | IB 56 Gb/s + 1 Gb/s EHT | | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| node5 | 32 | 1 | 256 GB | IB 56 Gb/s + 1 Gb/s EHT | | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| node6 | 32 | 1 | 256 GB | IB 56 Gb/s + 1 Gb/s EHT | | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| node7 | 32 | 1 | 256 GB | IB 56 Gb/s + 1 Gb/s EHT | | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| proc1 | 32 | 1 | 512 GB | 1 Gb/s EHT | 1x intel xeon phi | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| proc2 | 32 | 1 | 512 GB | 1 Gb/s EHT | 2x intel xeon phi | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| pti | 32 | 2 | 512 GB | IB 56 Gb/s + 1 Gb/s EHT | 2x Tesla P100-SXM2-16GB | Scratch de 800 GB |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| vti1 | 8 | 2 | 190 GB | IB 56 Gb/s + 1 Gb/s EHT | 4x Tesla V100-PCIE-32GB | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
| vti2 | 8 | 2 | 190 GB | IB 56 Gb/s + 1 Gb/s EHT | 4x Tesla V100-PCIE-32GB | |
+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
source/components/partitions.rst deleted 100644 → 0
+ 0
− 27
View file @ 71e23ba6
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| Fila | Nodos | Descrição | Tempo de execução |
+================+==================================+===================================================+===================+
| 1h | nodo[2-7],proc[1-2],pti,vti[1-2] | Será depreciado em breve | 1 hora |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| 1d | nodo[2-7],proc[1-2],pti,vti[1-2] | Será depreciado em breve | 1 dia |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| 7d | nodo[2-7],proc[1-2],pti,vti[1-2] | Será depreciado em breve | 7 dias |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| 30d | nodo[2-7],proc[1-2],pti,vti[1-2] | Será depreciado em breve | 30 dias |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| gpu-testing | pti,vti[1-2] | Fila de teste, p/ jobs de gpu | 30 minutos |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| gpu | pti,vti[1-2] | Dedicado a jobs de gpu | 7 dias |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| bigmem-testing | pti,proc[1-2] | Fila de teste, p/ jobs de com alto consumo de ram | 30 minutos |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| bigmem | pti,proc[1-2] | Dedicado a jobs com alto consumo de ram | 7 dias |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| cpu-testing | node[2-7],pti,proc[1-2] | Fila de teste, p/ jobs de com alto consumo de cpu | 30 minutos |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| cpu | node[2-7],pti,proc[1-2] | Dedicado a jobs com alto consumo de cpu | 7 dias |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| nodes-testing | node[2-7] | Fila de testes de nodos homogeneos | 30 minuto |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
| nodes | node[2-7] | Fila de nodos homogeneos | 7 dias |
+----------------+----------------------------------+---------------------------------------------------+-------------------+
source/pages/acesso.rst deleted 100644 → 0
+ 0
− 164
View file @ 71e23ba6
Acesso
######
Esta página destina a mostrar meios de interagir com o cluster do C3SL. Acessar remotamente o cluster e copiar arquivos do computador pessoal para o cluster e depois copiar arquivos do cluster para computador pessoal.
.. contents:: Formas de acesso
:depth: 4
Acesso via ssh
**************
| A forma de acessar o cluster é por meio do protocolo de acesso ssh (secure shell).
| O nome do cluster para acesso é: c3hpc.c3sl.ufpr.br
Acesso ssh Linux
================
A principal forma de utilizar o *ssh* no Linux é por meio do terminal.
*ssh* terminal Linux
--------------------
| Abra o terminal e digite o comando: ``ssh <login>@c3hpc.c3sl.ufpr.br``.
| Onde:
- <login> é o seu usuário do cluster
Exemplo de acesso por terminal Linux
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: console
odair:~/ $ ssh odair@c3hpc.c3sl.ufpr.br
Linux c3hpc 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64
================================================================================
Suporte: c3hpc@c3sl.ufpr.br
===============================================================================
Last login: Wed Aug 31 19:28:56 2022 from 2801:82:80ff:8001:216:ccff:feaa:77
➜ ~
Acesso ssh windows
==================
TODO
Termius
-------
TODO
Copiar de arquivos para o cluster
*********************************
Para copiar arquivos para o cluster é possível utilizar os comandos: *scp* ou *rsync*
Comando *scp*
=============
| O comando scp (secure copy) funciona da mesma maneira que o comando *cp* só que precisa passar o servidor para onde está copiando.
| Para copiar um arquivo local para o cluster utilize o comando:
| ``scp <arquivo> <login>@c3hpc.c3sl.ufpr.br:~/<destino>``
| Onde:
* <arquivo> é o nome ou caminho para o arquivo que deseja copiar.
* <login> É o seu usuário no cluster.
* <destino> É o nome ou caminho de destino do arquivo no cluster.
| Para copiar diretórios é necessário passar a opção *-r*
| ``scp -r <diretório> <login>@c3hpc.c3sl.ufpr.br:~/<destino>``
Exemplo de cópia com *scp*
--------------------------
O exemplo a seguir mostra como copiar um arquivo ou diretório com scp para sua conta no cluster:
.. code-block:: console
[odair@zaros ~]$ scp -r experimentos/ odair@c3hpc.c3sl.ufpr.br:~/
exp2 100% 0 0.0KB/s 00:00
exp1 100% 0 0.0KB/s 00:00
script.sh 100% 0 0.0KB/s 00:00
[odair@zaros ~]$
Para copiar do cluster para sua máquina local é só inverter a ordem dos parâmetros:
.. code-block:: console
[odair@zaros ~]$ scp -r odair@c3hpc.c3sl.ufpr.br:~/experimentos resultados
[odair@zaros ~]$ ls resultados/
exp1 exp2 script.sh
[odair@zaros ~]$
Comando *rsync*
===============
| O comando rsync é mais robusto que o scp, e segue a mesma lógica de uso.
| Para copiar um arquivo local para o cluster use:
| ``rsync -avhHP <arquivo> <login>@c3hpc.c3sl.ufpr.br:~/<destino>``
| Para copiar um arquivo remoto do cluster para a sua máquina utilize:
| ``rsync -avhHP <login>@c3hpc.c3sl.ufpr.br:/<arquivo> <destino>``
Onde:
- ``<arquivo>`` É o nome ou caminho para o arquivo que deseja copiar.
- ``<login>`` É o seu usuário no cluster.
- ``<destino>`` É o nome ou caminho de destino do arquivo no cluster.
Os parâmetros utilizados no comando do ``rsync`` significam:
- ``-a`` Copiar tanto arquivo quanto diretório.
- ``-v`` Mostrar uma saída mais detalhada.
- ``-h`` Mostrar valores em unidades humanas, como MB, GB
- ``-H`` Copiar e manter hard-links.
- ``-P`` Mostrar o progresso durante a cópia
Exemplo de cópia com comando *rsync*
------------------------------------
Copiando diretório local para o cluster:
.. code-block:: console
[odair@zaros ~]$ rsync -avhHP experimentos_v2/ odair@c3hpc.c3sl.ufpr.br:~/experimentos_v2/
sending incremental file list
created directory /home/odair/experimentos_v2
./
exp1
0 100% 0,00kB/s 0:00:00 (xfr#1, to-chk=2/4)
exp2
0 100% 0,00kB/s 0:00:00 (xfr#2, to-chk=1/4)
script.sh
0 100% 0,00kB/s 0:00:00 (xfr#3, to-chk=0/4)
sent 233 bytes received 130 bytes 242,00 bytes/sec
total size is 0 speedup is 0,00
[odair@zaros ~]$
Copiando diretório remoto do cluster para máquina local
.. code-block:: console
[odair@zaros ~]$ rsync -avhHP odair@c3hpc.c3sl.ufpr.br:~/experimentos_v2/ resultados_2
receiving incremental file list
created directory resultados_2
./
exp1
0 100% 0,00kB/s 0:00:00 (xfr#1, to-chk=2/4)
exp2
0 100% 0,00kB/s 0:00:00 (xfr#2, to-chk=1/4)
script.sh
0 100% 0,00kB/s 0:00:00 (xfr#3, to-chk=0/4)
sent 88 bytes received 235 bytes 129,20 bytes/sec
total size is 0 speedup is 0,00
[odair@zaros ~]$ ls resultados_2/
exp1 exp2 script.sh
[odair@zaros ~]$
.. tip::
| Recomendo criar um alias no .bashrc ou .zshrc para comandos de cópias, uma sugestão de alias é:
| ``alias copy="rsync -ahH --info=progress2 --mkpath"``
| O parametro ``--mkpath`` cria subdiretórios no destino, caso ele não exista, consulte ``man rsync`` para mais informações
| Com esse alias basta fazer:
| ``copy <arquivo> <login>@c3hpc.c3sl.ufpr.br:<destino>``
| ``copy <login>@c3hpc.c3sl.ufpr.br:<arquivo> <destino>``
source/pages/overview.rst deleted 100644 → 0
+ 0
− 161
View file @ 71e23ba6
Visão geral do cluster
######################
A visão geral do cluster pode ser entendido pelos conceitos básicos de como funciona cada componente. Essa página se destina apenas introduzir os conceitos, que serão aprofundados em outras páginas.
.. contents:: :depth: 4
Fluxo de trabalho do HPC
************************
O primeiro passo é entender como o cluster e executar programas em computadores de alto desempenho funciona.
.. figure:: ../_static/hpc-slurm.svg
:alt: Diagrama de funcionamento de computação de alto desempenho.
O uso de HPC para realizar processamento paralelo e de alto desempenho consiste em:
#. Copiar o experimento para o HPC.
#. Acessar o nodo de acesso, representado na figura pelo quadrado azul.
#. Submeter o experimento para o gerenciador de trabalho do HPC, no caso o slurm. Representado na figura pelo retângulo verde.
#. O gerenciador de trabalho do HPC colocará o trabalho na fila e assim que tiver recursos disponíveis o gerenciador executará o *job* Representado na figura losango laranja.
#. A execução do seu experimento será feito em algum nodo de processamento *computing node*, o nodo escolhido será conforme as especificações do seu experimento. Os nodos de processamentos são representados pelo quadrado vermelhos.
Conceitos fundamentais
**********************
.. contents:: Os principais conceitos que precisam serem entendidos são:
:depth: 2
:local:
*Jobs*
======
Quando submete um programa para executar em um computador de processamento chamamos de jobs. Um jobs pode ter os seguintes estados:
* PENDING: está na fila para ser executado.
* RUNNING: está sendo executado
Partições
=========
| Partições *partitions* podem serem vistas como filas de trabalho do cluster. Um cluster pode ter várias partições, normalmente as partições representam uma divisão de recursos físicos ou lógicos. Por exemplo, uma partição contém somente servidoras com placas de vídeos.
| Para visualizar as partições utilize o comando ``sinfo``.
Exemplo de ``sinfo``: Visualizando partições:
---------------------------------------------
.. code-block:: console
odair@c3hpc:~$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
1d up 1-00:00:00 9 idle node[2-7],proc[1-2],pti
7d up 7-00:00:00 2 alloc vti[1-2]
7d up 7-00:00:00 9 idle node[2-7],proc[1-2],pti
... ... ... ...
cpu up 7-00:00:00 9 idle node[2-7],proc[1-2],pti
cpu-long up 30-00:00:0 9 idle node[2-7],proc[1-2],pti
maratona-testing up 15:00 9 idle node[2-7],proc[1-2],pti
maratona up 1-00:00:00 9 idle node[2-7],proc[1-2],pti
odair@c3hpc:~$
Filas
=====
| As filas mostram os trabalhos que estão em execução, aguardando recursos serem liberados para executar e trabalhos com falhas. O comando para visualizar as filas é:
| ``squeue``
Exemplo de ``squeue``
---------------------
.. code-block:: console
odair@c3hpc:~$ squeue -l
Mon Sep 26 23:47:07 2022
JOBID PARTITION NAME USER STATE TIME TIME_LIMI NODES NODELIST(REASON)
12139 gpu exp2 odair RUNNING 3:01 7-00:00:00 1 pti
12142 gpu exp2 odair RUNNING 3:01 7-00:00:00 1 pti
12138 gpu exp2 odair RUNNING 3:04 7-00:00:00 1 pti
12150 maratona exp4 odair PENDING 0:00 1-00:00:00 1 (Resources)
12151 maratona exp4 odair PENDING 0:00 1-00:00:00 1 (Priority)
12149 maratona exp4 odair RUNNING 1:57 1-00:00:00 4 node[6-7],proc[1-2]
12148 maratona exp4 odair RUNNING 2:12 1-00:00:00 4 node[4-7]
12147 maratona exp4 odair RUNNING 2:15 1-00:00:00 3 node[3-5]
12144 maratona exp3 odair RUNNING 2:47 1-00:00:00 1 node3
12143 maratona exp3 odair RUNNING 2:50 1-00:00:00 1 node3
odair@c3hpc:~$
No exemplo mostra trabalhos que estão sendo executados e os que não estão, além do motivo para não estar em execução. O comando ``squeue -l`` mostra de forma longa a saída.
.. tip::
| Recomenda adicionar o seguinte alias no seu ``.bashrc`` ou ``.zshrc``:
| ``alias sq="squeue -u ${USER}"``
| Esse, aliás faz com que só mostre *jobs* do seu usuário e não mostra de outros usuários.
Módulos
=======
| O cluster possui diversos softwares com diversas versões, para lidar com vários softwares com muitas versões se utiliza um mecanismo de módulo, onde o usuário carrega um software na versão X apenas para a sessão dele.
| Utilize o comando `module avail` para mostrar todos os módulos disponíveis. A saída será algo do gênero:
Em alguns casos algumas bibliotecas só funcionam em versões especifica do ``python`` ou do ``cuda``. Para o exemplo veremos qual a versão padrão do python3 e mudara para versão 3.8.4.
Mostrando módulos
-----------------
| Para mostrar todos os módulos disponíveis no cluster utilize o comando:
| ``module avail``
| A saída deve ser algo semelhante ao exemplo abaixo:
.. code-block:: console
odair@c3hpc:~$ module avail
----------------------- /usr/local/Modules/modulefiles --------------
applications/bazel/0.11.1 libraries/gdrcopy/gcc-6.4.0
applications/cmake/3.11.0 libraries/gdrcopy/gcc-7.3.0
... ...
interpreters/python/3.6.8 libraries/openblas/0.2.20-gcc-6.4.0
interpreters/python/3.8.14 libraries/openblas/0.2.20-gcc-7.3.0
libraries/boost/1.66.0-gcc-6.4.0 libraries/openmpi/4.0.0-gcc-6.4.0
... ...
libraries/cuda/10.1 tools/nvtop/1.0.0-cuda9.0
libraries/cuda/11.0 use.own
Key:
loaded modulepath
odair@c3hpc:~$
Carregando módulos
------------------
| Para carregar um módulo utilize o comando:
| ``module load <modulo>``
| Onde: ``<module>`` é o nome do módulo a ser carregado.
Exemplo carregando *python3* versão 3.8.14
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Para demostrar como funciona verificaremos a versão padrão do ``python3`` e carregar a versão ``3.8.14``
.. code-block:: console
testem@c3hpc:~$ python3 --version # verifica versão do login node
Python 3.9.2
testem@c3hpc:~$ srun python3 --version # verifica versão de um computer node
Python 3.9.2
testem@c3hpc:~$ module load interpreters/python/3.8.14 # carrega python3 versão 3.8.14
testem@c3hpc:~$ python3 --version # verifica versão do login node
Python 3.8.14
testem@c3hpc:~$ srun python3 --version # verifica versão de um computer node
Python 3.8.14
testem@c3hpc:~$
| Vejam que após executar o comando:
| ``module load interpreters/python/3.8.14``
| A versão do ``python3`` muda. Módulos são uteis principalmente quando se deseja utilizar diferentes versões de cuda e python.
Descarregando módulo
--------------------
| Para fazer o *unload* de um determinado módulo execute o comando:
| ``module unload <modulo>`` Onde ``modulo`` é o nome do módulo.
Requisitando módulos e softwares
--------------------------------
Para requisitar módulos, novas versões de softwares ou até mesmo a instalação de novas aplicações envie e-mail para c3hpc@c3sl.ufpr.br.
source/pages/quickstart.rst deleted 100644 → 0
+ 0
− 113
View file @ 71e23ba6
Guia rápido de submissão
************************
A submissão de *jobs* pode ser realizado por dois comandos do gerenciador do cluster: ``srun`` e ``sbatch``. O comando ``srun`` executa na linha de comando e é bloqueante, enquanto o comando ``sbatch`` executa um arquivo de configuração e não é bloqueante.
.. contents:: :depth: 4
Principais parâmetros de submissão:
===================================
* ``-p|--partition nome`` Especifica o nome da partição que o *job* será executado.
* ``-t|--time tempo`` Especifica um tempo limite para a execução do job. Caso o tempo limite especificado seja maior que o tempo da partição, o job ficará com o estado pendente (PENDING), possivelmente para sempre. Formatos de tempo aceitos: “minutos”, “minutos:segundos”, “horas:minutos:segundos”, “dias-horas”, “dias-horas:minutos” e “dias-horas:minutos:segundos”.
* ``-c|--cpus-per-task`` Especifica a quantidade de core/threads o seu programa utilizará.
* ``--mem tamano unidade`` Especifica quantidade de memória seu programa utilizará.
* ``-n NUM_PROCESSOS`` Especifica o número de processos a serem iniciados.
* ``-N NUM_NODOS`` Especifica que deverão ser alocados pelo menos NUM_NODOS nodos para a execução do job, ou seja, cada nodo vai executar NUM_PROCESSOS dividido por NUM_NODOS.
* ``–job-name=NOME`` Especifica o nome do Job que será executado. Este nome irá aparecer juntamente com o id do job na listagem de jobs do sistema.
* ``-e`` Especifica o redirecionamento do stderr. Exemplo:
``-e arquivoErros.txt``
* ``-o`` Especifica o redirecionamento do stdout. Caso ``-e`` não tenha sido especificado, stderr também será enviado para o arquivo especificado. Exemplo:
``-o arquivoSaida.txt`` ou ``--output arquivoSaida.txt``
Comando *srun*
==============
| O comando ``srun`` submete um *job* para o escalonador, por padrão esse comando é bloqueante. A sintaxe do comando é:
| ``srun executavel``
Exemplo: Execução simples do *srun*
-----------------------------------
O exemplo submete o programa ``/cluster/tests/omp/omp`` para fila de execução do cluster e será executado quando tiver recursos disponíveis.
.. code-block:: console
testem@c3hpc:~$ srun /cluster/tests/omp/omp
Missing arguments
Usage: /cluster/tests/omp/omp [-n|--nprocs] <cpus> [-t|--time] <time>
Examples:
Example 1: short options: To Execute program with 4 threads during 10 seconds:
/cluster/tests/omp/omp -n 4 -t 10
Example 2: long options: To Execute program with 8 threads during 15 seconds:
/cluster/tests/omp/omp --nprocs 8 --time 15
srun: error: node4: task 0: Exited with exit code 2
testem@c3hpc:~$ srun /cluster/tests/omp/omp --nprocs 4 -t 4
Time 4 Nproc 4
count: 258531857
count: 260249707
count: 262771821
count: 262113384
testem@c3hpc:~$
| Para especificar a quantidade de recurso que o *job* utilizará passe como argumentos antes do programa.
| ``srun <argumentos do srun> executavel``
Exemplo: Execução com argumentos *srun*
---------------------------------------
No exemplo abaixo, o executável é um programa em *openMP* que lança 4 threads, mas o srun só disponibiliza duas threads para ser executado. Portanto, as, quatro que as quatros threads tenham aceso a 4 núcleo de processamento é necessário passar o argumento ``--cpus-per-task 4``.
.. code-block::
testem@c3hpc:~$ srun --cpus-per-task 2 --mem 16G --partition maratona /cluster/tests/omp/omp --nprocs 4 -t 60
Time 60 Nproc 4
count: 430357224
count: -63444304
count: -21866144
count: -33171848
testem@c3hpc:~$
Comando *sbatch*
================
| O comando *sbatch* recebe como argumento um arquivo com as especificações do *jobs* que será executado. Sbatch é Uma opção mais comum é a utilização de um script, que contém as informações sobre o jobs que serão executados. No script, as opções de execução podem ser definidas utilizando-se o prefixo ``#SBATCH`` antes da opção.
| ``#SBATCH --time=1``
Abaixo, um exemplo de script que roda a aplicação “meuPrograma” que está no diretório bin. A aplicação irá executar por no máximo 7 dias e é solicitado 1 nodo para a execução.
.. code-block:: bash
#!/bin/sh
#SBATCH -p 7d
#SBATCH -t 7-00:00:00
#SBATCH -n 1
srun $HOME/meuPrograma
| Para submeter o script, salve-o como meuscript.sh, e execute-o utilizando o comando sbatch. Muitos dos parâmetros do comando srun também são válidos para o sbatch. Os parâmetros passados ao sbatch irão sobrescrever os parâmetros existentes no script sendo executado. Exemplo do comando:
| ``sbatch -o saida.txt meuscript.sh``
Modelo de arquivo *sbatch*
---------------------------
.. code-block:: bash
#!/bin/bash
#SBATCH -t 1-10:00:00
#SBATCH --cpus-per-task=NUM_CPUS_POR_PROCESSO
#SBATCH -o ARQUIVO_DE_SAIDA
#SBATCH --job-name=NOME_JOB
#SBATCH -p PARTICAO_ONDE_SERA_EXECUTADO
#SBATCH -n NUM_DE_PROCESSOS
#SBATCH -N NUM_NODOS_NECESSARIOS
srun $HOME/meuPrograma parametro1Programa parametro2Programa
| É possível sobrescrever os valores que estão no scripts pela linha de comando. Exemplo:
| ``sbatch -o saida.txt -t 5-00:00:00 meuscript.sh``
| Note que o comando acima sobrescreve o parâmetro -t que já está presente no meuscript.sh. Isso fará com que o parâmetro no meuscript.sh seja ignorado, sendo assim, ao executar a linha acima, o tempo limite para a execução será de 5 dias. No entanto, recomenda que todos os parâmetros estejam no script e que estes não sejam sobrecarregados pelo sbatch para facilitar a localização de erros e múltiplas execuções de um mesmo script.
Cancelando *jobs*
=================
| Para cancelar um job que está rodando ou que está na fila para execução, utilize o comando scancel. Modo de uso:
| ``scancel jobId``
.. note::
O **jobid** pode ser obitido através do comando **squeue**
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment