diff --git a/source/components/nodes.rst b/source/components/nodes.rst
deleted file mode 100644
index fefdeb164a4ed5b482e3f9fe627750e7ec1ab59c..0000000000000000000000000000000000000000
--- a/source/components/nodes.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
-| 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 | |
-+-------+-------+----------+---------+-------------------------+-------------------------+-------------------+
diff --git a/source/components/partitions.rst b/source/components/partitions.rst
deleted file mode 100644
index f2e522c0b69d720b9ba3f46b31e09e28a16c4888..0000000000000000000000000000000000000000
--- a/source/components/partitions.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-+----------------+----------------------------------+---------------------------------------------------+-------------------+
-| 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 |
-+----------------+----------------------------------+---------------------------------------------------+-------------------+
diff --git a/source/pages/acesso.rst b/source/pages/acesso.rst
deleted file mode 100644
index 7b333f7af60f126101e3f8937868cd5e6c250fc3..0000000000000000000000000000000000000000
--- a/source/pages/acesso.rst
+++ /dev/null
@@ -1,164 +0,0 @@
-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>``
-
diff --git a/source/pages/overview.rst b/source/pages/overview.rst
deleted file mode 100644
index 9629a01636a55ecc1fec82d85a0e0752286e8d03..0000000000000000000000000000000000000000
--- a/source/pages/overview.rst
+++ /dev/null
@@ -1,161 +0,0 @@
-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.
-
diff --git a/source/pages/quickstart.rst b/source/pages/quickstart.rst
deleted file mode 100644
index 4344a3d7f968b41d94c97252ad610c6679392555..0000000000000000000000000000000000000000
--- a/source/pages/quickstart.rst
+++ /dev/null
@@ -1,113 +0,0 @@
-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**
-