.. _melhorando_o_script_de_submissao:

================================
Melhorando o Script de Submissão
================================

.. contents:: Nesta seção:
   :local:
   :depth: 2

Esta seção detalha a construção de scripts de submissão robustos e eficientes, incorporando as melhores práticas e todos os recursos disponíveis no GridUnesp.

Opções do SBATCH
================

O SLURM oferece dezenas de diretivas para controlar a execução dos jobs. Abaixo as mais importantes:

.. list-table:: Principais diretivas SBATCH
   :header-rows: 1
   :widths: 25 15 60

   * - Diretiva
     - Abrev.
     - Descrição
   * - ``--time``
     - ``-t``
     - Tempo máximo de execução (formato: ``min``, ``min:seg``, ``horas:min:seg``, ``dias-horas``, ``dias-horas:min:seg``)
   * - ``--cpus-per-task``
     - ``-c``
     - Número de CPUs por processo (para threads/OpenMP)
   * - ``--ntasks``
     - ``-n``
     - Número total de processos (para MPI)
   * - ``--nodes``
     - ``-N``
     - Número mínimo de nós
   * - ``--mem``
     - 
     - Memória por nó (ex: ``16G``, ``32768M``)
   * - ``--mem-per-cpu``
     - 
     - Memória por CPU (ex: ``4G``)
   * - ``--output``
     - ``-o``
     - Arquivo para saída padrão (stdout)
   * - ``--error``
     - ``-e``
     - Arquivo para saída de erros (stderr)
   * - ``--job-name``
     - ``-J``
     - Nome do job (aparece no ``squeue``)
   * - ``--partition``
     - ``-p``
     - Partição (``short``, ``medium``, ``long``, ``gpu``)
   * - ``--gres``
     - 
     - Recursos genéricos, como GPUs (``--gres=gpu:1``)
   * - ``--mail-type``
     - 
     - Quando enviar e-mail (``BEGIN``, ``END``, ``FAIL``, ``ALL``)
   * - ``--mail-user``
     - 
     - Endereço de e-mail para notificações

**Exemplos:**

.. code-block:: bash

   #SBATCH -t 24:00:00 -c 4
   #SBATCH --mem=16G
   #SBATCH --output=job_%j.out
   #SBATCH --mail-type=END,FAIL
   #SBATCH --mail-user=joao@unesp.br

.. tip::
   Use ``%j`` no nome do arquivo para incluir o Job ID automaticamente.

.. _script_job_nanny:

Script job-nanny
================

O **job-nanny** é um script essencial do GridUnesp que gerencia a transferência de dados entre o ``/home/`` e as áreas de trabalho temporárias.

Por que usar job-nanny?
------------------------

1. **Evita sobrecarga no /home/** - Acesso direto ao /home/ durante a execução degrada o desempenho
2. **Otimiza performance** - Usa discos locais (``/tmp/`` ou  ``/store/``) que são muito mais rápidos
3. **Garante persistência** - Copia resultados de volta ao final
4. **Checkpoints automáticos** - Salva progresso periodicamente

.. warning::
   O script ``job-nanny`` é reconhecido ao carregar o módulo **gridunesp**.
   
   Quando o usuário faz login no cluster, esse módulo é carregado automaticamente.
   
   Caso tenha usado o comando ``module purge``, é preciso fazer
  
   .. code-block:: bash

      module load gridunesp
      
   para que o ``job-nanny`` esteja disponível.

Variáveis Obrigatórias
----------------------

O job-nanny **exige** a definição de duas variáveis:

.. code-block:: bash

   export INPUT="arquivo1.dat arquivo2.dat diretorio_entrada/"
   export OUTPUT="resultado.dat saida/"

- **INPUT:** Arquivos/diretórios que serão copiados para a área de trabalho temporária
- **OUTPUT:** Arquivos/diretórios que serão copiados de volta ao ``/home/`` ao final

Variáveis Opcionais
-------------------

.. list-table:: Variáveis do job-nanny
   :header-rows: 1
   :widths: 25 25 50

   * - Variável
     - Padrão
     - Descrição
   * - ``CHECKPOINT``
     - ``$OUTPUT``
     - Local para salvar checkpoints
   * - ``WAIT_CHECKPOINT``
     - 10800 (3h)
     - Intervalo entre checkpoints (segundos)
   * - ``VERBOSE``
     - 0
     - Ativa modo verboso (1) para debug
   * - ``SHARED_FS``
     - "false"
     - Se "false", usa ``/tmp/``; se "true", força uso do ``/store/``
   * - ``LARGE_FILES``
     - "false"
     - Se "true", força uso do ``/store/`` (para arquivos grandes)

Exemplos de Uso do job-nanny
----------------------------

**Exemplo 1: Job serial simples**

.. code-block:: bash
   :caption: job_simples.sh

   #!/bin/bash
   #SBATCH -J teste
   #SBATCH -n 1
   #SBATCH -t 01:00:00

   export INPUT="entrada.dat"
   export OUTPUT="resultado.dat"

   module load python/3.9
   job-nanny python script.py entrada.dat > resultado.dat

**Exemplo 2: Job com múltiplos arquivos**

.. code-block:: bash
   :caption: job_multiplo.sh

   #!/bin/bash
   #SBATCH -J simulacao
   #SBATCH -c 4
   #SBATCH -t 24:00:00

   export INPUT="parametros.in dados/ biblioteca.so"
   export OUTPUT="saida.dat logs/"

   module load gcc/10.2.0
   job-nanny ./programa -i parametros.in -o saida.dat

**Exemplo 3: Job com arquivos grandes**

.. code-block:: bash
   :caption: job_grande.sh

   #!/bin/bash
   #SBATCH -J big_data
   #SBATCH -n 1
   #SBATCH -t 12:00:00

   export INPUT="dataset_grande.bin"
   export OUTPUT="resultados/"
   export LARGE_FILES="true"      # Força uso do /store/

   job-nanny ./processador dataset_grande.bin

**Exemplo 4: Job com checkpoints frequentes**

.. code-block:: bash
   :caption: job_longo.sh

   #!/bin/bash
   #SBATCH -J long_job
   #SBATCH -n 8
   #SBATCH -t 20-00:00:00          # 20 dias

   export INPUT="entrada.dat"
   export OUTPUT="resultado_final.dat"
   export CHECKPOINT="checkpoints/"
   export WAIT_CHECKPOINT=3600      # Checkpoint a cada 1 hora

   module load meu_software
   job-nanny simular --restart checkpoints/

.. _parametros_do_job_nanny:

Escolha Entre /tmp/ e /store/
=============================

O job-nanny decide automaticamente onde executar:

**Usa /tmp/ (rápido, local) quando:**

- Job usa **apenas 1 nó** (``-N 1``)
- ``SHARED_FS`` não está definido ou é ``"false"``
- ``LARGE_FILES`` não está definido ou é ``"false"``

**Usa /store/ (compartilhado) quando:**

- Job usa **múltiplos nós** (``-N > 1``)
- ``SHARED_FS="true"``
- ``LARGE_FILES="true"``

.. tip::
   Para jobs de 1 nó com arquivos muito grandes (>100 GB), use ``LARGE_FILES="true"`` para forçar o uso do ``/store/``, que tem mais espaço disponível do que o ``/tmp/`` do nó de processamento.

.. _sistema_de_filas_detalhado:

Sistema de Filas (Detalhado)
============================

O tempo especificado determina automaticamente a partição:

.. list-table:: Relação tempo x partição
   :header-rows: 1
   :widths: 35 20 45

   * - Tempo solicitado
     - Partição
     - Prazo máximo de processamento
   * - Até 24 horas
     - short
     - 24 horas
   * - Até 24 horas (especificando ``-p gpu``)
     - gpu
     - 24 horas (executado no servidor de GPU)
   * - Entre 24h e 7 dias
     - medium
     - 7 dias
   * - Entre 7 e 30 dias
     - long
     - 30 dias
   * - Acima de 30 dias
     - (inválido)
     - Job não será aceito

.. important::
   Sempre especifique o tempo mais preciso possível. Jobs com tempo menor:
   
   - Têm **prioridade maior** na fila
   - Podem "encaixar" em janelas de recursos ociosos
   - Aumentam a eficiência do cluster para todos

Exemplos de Configuração de Tempo:

.. code-block:: bash

   # 30 minutos
   #SBATCH -t 30:00

   # 12 horas e 30 minutos
   #SBATCH -t 12:30:00

   # 2 dias e 6 horas
   #SBATCH -t 2-06:00:00

   # 30 dias (máximo permitido)
   #SBATCH -t 30-00:00:00

.. _informacao_sobre_o_storage:

Informações sobre o Storage (Detalhado)
=======================================

O GridUnesp possui três áreas principais de armazenamento, cada uma com características específicas:

.. list-table:: Comparação das partições
   :header-rows: 1
   :widths: 15 20 20 25 20

   * - Partição
     - Capacidade
     - Velocidade
     - Persistência
     - Uso recomendado
   * - ``/home/``
     - 120 TB
     - Média
     - Permanente
     - Scripts, código, dados pequenos
   * - ``/tmp/``
     - ~180 GB/nó
     - Muito rápida
     - Temporária (apenas durante o job)
     - I/O intensivo, arquivos temporários
   * - ``/store/``
     - 7 TB
     - Média-baixa
     - Temporária
     - Arquivos grandes, dados compartilhados

.. _particao_tmp_basico:

Partição /tmp/
--------------

O ``/tmp/`` é um diretório local em cada nó de processamento. Suas principais características:

- **Velocidade:** Altíssima (disco local SSD/HD)
- **Espaço:** Limitado (~180 GB por nó)
- **Escopo:** Visível apenas no nó onde o job está executando
- **Persistência:** **TEMPORÁRIA** - arquivos são removidos ao final do job

.. raw:: html

   <video width="640" height="360" controls>
     <source src="../_static/Access_to_tmp.mp4" type="video/mp4">
   </video>


**Quando usar /tmp/:**

- Jobs que fazem muita leitura/escrita em disco
- Dados temporários que podem ser recriados
- Processamento que cabe no espaço disponível
- Jobs de **um único nó** (padrão)

**Exemplo de uso explícito do /tmp/ (já é o padrão):**

.. code-block:: bash

   #!/bin/bash
   #SBATCH -J tmp_job
   #SBATCH -N 1
   #SBATCH -n 28
   #SBATCH -t 24:00:00

   export INPUT="dados_entrada/"
   export OUTPUT="resultados/"

   # job-nanny usará /tmp/ automaticamente (1 nó, sem flags)
   job-nanny ./programa

.. _particao_store_basico:

Partição /store/
----------------

O ``/store/`` é um sistema de arquivos compartilhado entre todos os nós:

- **Velocidade:** Média
- **Espaço:** Grande (7 TB)
- **Escopo:** Visível em todos os nós
- **Persistência:** **TEMPORÁRIA** (dados apagados após o término do job)

.. raw:: html

   <video width="640" height="360" controls>
     <source src="../_static/Access_to_store.mp4" type="video/mp4">
   </video>

**Quando usar /store/:**

- Jobs com **múltiplos nós** (MPI)
- Arquivos de entrada/saída muito grandes (>100 GB)
- Dados que precisam ser acessados por vários nós simultaneamente

**Exemplo de job multi-nó (usa /store/ automaticamente):**

.. code-block:: bash

   #!/bin/bash
   #SBATCH -J mpi_job
   #SBATCH -N 4
   #SBATCH -n 112
   #SBATCH -t 72:00:00

   export INPUT="dados_grandes/"
   export OUTPUT="resultados_mpi/"

   module load openmpi/4.1.5
   job-nanny mpirun -n 112 ./programa_mpi

**Exemplo forçando uso do /store/ em job de 1 nó:**

.. code-block:: bash

   #!/bin/bash
   #SBATCH -J big_job
   #SBATCH -N 1
   #SBATCH -n 28
   #SBATCH -t 48:00:00

   export INPUT="dataset_500GB/"
   export OUTPUT="resultados/"
   export LARGE_FILES="true"      # Força uso do /store/

   job-nanny ./processador

Considerações Importantes
=========================

1. **Nunca** processe jobs diretamente no servidor access
2. **Sempre** defina INPUT e OUTPUT ao usar job-nanny
3. **Estime** corretamente o tempo necessário (jobs mais curtos têm prioridade)
4. **Monitore** seus jobs com ``squeue`` e ``scontrol``
5. **Limpe** arquivos temporários após a conclusão

.. seealso::

   - :ref:`processando_simulacoes` - Conceitos básicos
   - :ref:`monitorando_simulacoes` - Monitoramento avançado
   - :ref:`guia_armazenamento` - Guia completo de storage
   - :ref:`boas_praticas` - Recomendações gerais