.. _processando_simulacoes:
Processando Simulações
======================
A partir do servidor **access2.grid.unesp.br**, o usuário tem acesso a sua área de trabalho no ``/home/``. De lá ele pode preparar o ambiente de trabalho para realizar o processamento das simulações (jobs).
.. warning::
Os usuários não devem processar simulações diretamente no servidor **access2**. Esse servidor deve funcionar apenas como ponto de acesso ao ``/home/``, a partir do qual as simulações devem ser preparadas para submissão de jobs. Somente pré e pós processamentos que demandem um curtíssimo tempo de execução e pouca memória é que podem ser executados no servidor **access2**. Ou seja, é uma exceção.
Em todas as demais situações, os usuários devem preparar os scripts de submissão de jobs para que as simulações sejam executadas nos nós de processamento. Por isso, caso a equipe do GridUnesp observe que o servidor **access2** esteja sendo usado para execução de aplicações que demandem muito tempo e CPU, elas serão imediatemente canceladas para evitar que impactem negativamente na utilização do cluster pelos demais usuários.
Entendimento básico
-------------------
Eis os passos que normalmente o usuário deverá seguir para realizar processamentos no GridUnesp:
* Inicialmente o usuário irá preparar a área de trabalho, criando ou transferindo arquivos para seu ``/home/`` de acordo com as explicações da seção :ref:`transferindo_arquivos`).
* Na sequência, é muito provável que tenha que instalar a(s) aplicação(ões) científica(s) necessária(s) ao trabalho que deseja realizar (veja a seção :ref:`instalando_aplicacoes`).
* Finalmente, deverá preparar um script de submissão de jobs (simulações). Esse script conterá as diretivas necessárias para a execução do job.
.. important::
O GridUnesp utiliza o `Slurm `_ para gerenciar os processos do cluster. Dessa forma esse script de submissão geralmente é um script em *bash* com algumas instruções específicas do *Slurm*. Esse script é um arquivo de texto, que pode ser editado em outro computador e transferido ou editado no próprio servidor **access2** com editores de texto como `nano `_, `vim `_ ou `emacs `_.
A imagem abaixo mostra uma simples ilustração do *workflow*: após o acesso ao servidor, o usuário prepara o ambiente de trabalho no ``/home/`` (organizando os arquivos e instalações necessários) e envia as simulações para processamento nos *worker nodes* (nós de processamento).
.. raw:: html
Vamos supor que que um usuário chamado *Spock* (cujo login no GridUnesp é **spock**) queira, como teste, criar um script denominado **vulcano.sh** que apenas tenha como resultado o dia e a hora. *Spock* então escreve um arquivo com o seguinte conteúdo:
.. code-block:: bash
#!/bin/bash
#SBATCH -t 5:00
date
sleep 60
Aqui, ``#SBATCH`` é uma instrução necessário do *Slurm* que deve estar presente em todos os scripts de submissão de jobs. O parâmetro ``-t 5:00`` significa que o tempo máximo de processamento será de 5 minutos a partir do momento em que o *worker node* iniciar a execução do job. E como *Spock* sabe que o comando ``date`` é muito simples e rápido de ser executado, ele também incluiu o comando ``sleep 60``, apenas para fazer o job demarar um tempinho (60 segundos) antes de finalizar, a fim de que pudesse verifcar o status do job na fila.
Para submeter essa "simulação" tão simples para processamento no nó, *Spock* informa o seguinte comando em seu terminal
.. code-block:: bash
[spock@access2 ~]$ sbatch vulcano.sh
O comando ``sbatch vulcano.sh`` envia o script para o escalonador de jobs (*Slurm*), o qual irá ler as diretivas do script de submissão e enviá-lo para uma fila a partir de uma classificação segundo uma determinada ordem de prioridade. À medida que os recursos vão sendo liberados, cada job na fila vai entrando em execução.
.. _monitorando_simulacoes:
Monitorando Simulações
----------------------
Para visualizar a ordem em que seu job aparece na fila, *Spock* utiliza o comando
.. code-block:: bash
[spock@access2 ~]$ squeue -a
Aparece então na tela o seguinte resultado:
::
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
2846439 short,med dobra2.sh kirk PD 0:00 1 (Priority)
2847404 medium dobra3.sh picard PD 0:00 1 (Priority)
2848556 short,med patrono.sh potter PD 0:00 1 (Priority)
2848557 short,med reparo.sh hermione PD 0:00 1 (Priority)
2848879 short vulcano.sh spock PD 0:00 1 (Priority)
2841620 long crucio.sh voldemort R 10-02:40:51 1 node018
2843891 medium force.sh yoda R 4-23:08:47 4 node[001,005,016,027]
2843895 medium dark.sh vader R 4-23:08:47 6 node[002,005-007,009-010]
2845557 long sabre.sh luke R 5:45:06 1 node044
*Spock* percebe então que há 9 jobs na fila, sendo que 5 deles estão aguardando que alguns dos outros 4 jobs em execução finalizem o processamento para que os recursos sejam liberados. Os status **PD** e **R** significam *PENDING* E *RUNNING* respectivamente. *Spock* ainda consegue notar que, dos 4 jobs que estão rodando (processando/executando):
* o job de número 2841620 está processando há 10 dias, 2 horas e 40 minutos em apenas 1 nó (node018);
* o job 2843891 está em execução há 4 dias e 23 horas em 4 nós (node001, node005, node016 e node017);
* o job 2843895 está em execução também há 4 dias e 23 horas usando 6 nós (node002, node005, node006, node007, node009 e node010);
* o job 2845557 está processando há apenas 5 horas e 45 minutos em um único nó (node044).
Finalmente, após algum tempo de espera, o job do *Spock* entrou em processamento. Para verificar o status apenas do seu job, ele executa o comando
.. code-block:: bash
[spock@access2 ~]$ squeue -u spock
cujo resultado é
::
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
2848879 short vulcano.sh spock R 0:09 1 node011
*Spock* ainda pensou em cancelar seu job, mas decidiu deixá-lo processar até o fim. Porém, caso quisesse realmente cancelar, sabia que bastaria usar o comando
.. code-block:: bash
scancel 2848879
E como estava interessado em ver mais detalhes do job, *Spock* executou o comando
.. code-block:: bash
[spock@access2 ~]$ scontrol show job 2848879
cujo resultado é
::
JobId=2848879 JobName=vulcano.sh
UserId=spock(11992) GroupId=enterprise(11006) MCS_label=N/A
Priority=310871 Nice=0 Account=ncc QOS=normal
JobState=RUNNING Reason=None Dependency=(null)
Requeue=1 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
RunTime=00:00:18 TimeLimit=00:05:00 TimeMin=N/A
SubmitTime=2022-04-01T18:47:30 EligibleTime=2022-04-01T18:47:30
AccrueTime=2022-04-01T18:47:30
StartTime=2022-04-01T18:47:30 EndTime=2022-04-01T18:52:30 Deadline=N/A
SuspendTime=None SecsPreSuspend=0 LastSchedEval=2022-04-01T18:47:30
Partition=short AllocNode:Sid=access2:32492
ReqNodeList=(null) ExcNodeList=(null)
NodeList=node011
BatchHost=node011
NumNodes=1 NumCPUs=2 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
TRES=cpu=2,node=1,billing=2
Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*
MinCPUsNode=1 MinMemoryCPU=2G MinTmpDiskNode=0
Features=(null) DelayBoot=00:00:00
OverSubscribe=OK Contiguous=0 Licenses=(null) Network=(null)
Command=/home/spock/vulcano.sh
WorkDir=/home/spock
StdErr=/home/spock/slurm-2848879.out
StdIn=/dev/null
StdOut=/home/spock/slurm-2848879.out
Power=
MailUser=(null) MailType=NONE
Por fim, após o término do processamento do job de teste, *Spock* visualiza o contéudo do arquivo de saída (*slurm-2848879.out*):
::
Sex Abr 1 18:47:31 -03 2022
Satisfeito com o teste por ter-lhe provido o conhecimento básico de como criar um script, submiter um job e monitorar o processamento, *Spock* sente-se agora mais confiante e preparado para avançar com as simulações de seu projeto de pesquisa.
Resumo dos comandos básicos
---------------------------
* Enviando para a fila de execução
.. code-block:: bash
sbatch submit_job.sh
* Verificando status de todos os jobs na fila
.. code-block:: bash
squeue -a
* Verificando status apenas dos jobs de um usuário em específico
.. code-block:: bash
squeue -u username
* Obtendo detalhes de um processo
.. code-block:: bash
scontrol show jobid
* Cancelando processo
.. code-block:: bash
scancel