Gerenciando simulações

O procedimento básico para a execução de uma simulação envolve:

  1. Transferir os arquivos de entrada (como descrito em Transferindo com uma máquina Linux/Unix/MacOS
  2. Acessar o servidor access.grid.unesp.br (descrito em Acessando de uma máquina com Linux/Unix/MacOS)
  3. Criar um arquivo de envio (script de submissão de jobs)
  4. Enviar o processo
  5. Verificar seu estado na fila
  6. Copiar os resultados quando a simulação acabar

Para enviar a simulação para o processamento, é necessário criar um arquivo de de envio (script) que coordenará a execução do processo quando o recurso computacional for alocado. Isso significa que é esse script que será executado no servidor de processamento e ele deve ter as instruções para iniciar o aplicativo desejado.

O GridUnesp utiliza o SLURM para gerenciar os processos do cluster. Dessa forma esse script 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 access com editores de texto como nano, vim ou emacs.

Script de exemplo

simulacao.sh:

#!/bin/sh
#SBATCH --time=1
/bin/hostname

Comandos básicos

  • Enviando para fila de execução
sbatch simulacao.sh
  • Verificando status
squeue -u <nome_de_usuario>
  • Detalhes de um processo
scontrol show jobid <id_do_job>
  • Cancelando processo
scancel <id_do_job>
  • Histórico de processos
sacct <id_do_job>

Opções SBATCH

comando abreviação significado
--time -t tempo máximo de execução (min, min:seg, horas:min:seg, dias-horas)
--cpus-per-task -c número de processos por servidor
--ntasks -n número total de processos
--nodes -N número mínimo de servidores
--output -o arquivo com o stdout (mensagens de saída)
--error -e arquivo com o stderr (mensagens de erro)
--mem   memória por nó em MB (máximo de 16 MB por nó)
--mem-per-cpu   memória por CPU em MB (máximo de 8 cores por CPU)

Script goo-job-nanny

Os processos precisam evitar utilizar o /home para a execução da simulação, pois isso diminui a performance de todo o cluster. Para isso foi criado um script que auxilia a tarefa de:

  1. criar um diretório temporário
  2. copiar os arquivos de entrada
  3. executar a simulação
  4. copiar os arquivos de saída
  5. apagar os arquivos temporários

Esse script chama goo-job-nanny. Para usar, basta preceder o comando de simulação com o termo goo-job-nanny.

Por exemplo:

#!/bin/bash
#SBATCH -n 2

goo-job-nanny srun -n 2 ./hello

Opções:

INPUT:
(default="*") Arquivos copiados para a área temporária para iniciar a simulação.
OUTPUT:
(default="*") Arquivos copiados de volta para a pasta inicial (no /home) ao fim da simulação.
CHECKPOINT:
(default="$OUTPUT") Arquivos copiados sistematicamente para a pasta inicial.
WAIT:
(default="10800" -- 3horas) Intervalo entre a cópia dos arquivos de checkpoint, em segundos.
VERBOSE:
(default="0" -- False) Controla se informações sobre as operações do próprio script devem ser impressas no stdout
CHECKPOINT_FUNC:
Avançado: Usado apenas em casos específicos onde é necessário realizar alguma operação antes do checkpoint. Consule VASP
LARGE_FILES:
(defaults="false") Suporte a arquivos de simulação maiores que 8GB. Para ponto de montagem no /store, usar LARGE_FILES="true".
SHARED_FS
Utiliza um sistema de arquivos compartilhado (útil para aplicações MPI). Se SHARED_FS="true", é utilizado o ponto de montagem no /store.

Sempre que a simulação utilizar MPI, ou LARGE_FILES="true", ou SHARED_FS="true", o jobs serão executados a partir do /store. Para informações sobre a utilização do /home, /tmp ou /store, consulte Informações sobre o Storage.

Exemplo com opções:

#!/bin/bash
#SBATCH -n 2

export VERBOSE=1
export INPUT="arquivo_de_entrada.ext"

goo-job-nanny srun -n 2 ./hello

Environment Modules

O GridUNESP utiliza um sistema modular de carregamento de ambiente. Esse sistema permite que sejam disponibilizadas diversas versões de compiladores, bibliotacas e aplicações que de outra forma seriam incompatíveis.

Listar o ambiente atual

$ module list

Currently Loaded Modulefiles:
  1) intel/compilers/11.1(default)   2) intel/mpi/3.2.1(default)

Listar os módulos disponíveis

Eis os módulos disponíveis no servidor access2.grid.unesp.br:

$ module avail

------------------------------ /opt/gridunesp/modules -----------------------------------------------
anaconda2/5.1.0                   gamit/10.70(default)              namd/2.12-tcp
anaconda3/4.4.0(default)          gaussian/09(default)              namd/2.13-smp
beagle/2.1.2(default)             gaussian/09.lsm                   namd/2.13-tcp
beast/2.4.7(default)              gcc/5.3.0                         openfoam/4.1
boost/1.64.0(default)             gcc/7.2.0(default)                openfoam/5.x(default)
charmm/c26b2                      gdal/2.4.1                        openmpi/2.1.1(default)
charmm/c26b2-serial               ginac/1.7.2(default)              orca/4.0.1(default)
charmm/c37b2(default)             gmt/5.4.3(default)                partitionfinder/2.1.1(default)
charmm/c37b2-serial               gridunesp/1(default)              pfinderuce-swsc-en/1.0.0(default)
cln/1.3.4(default)                gromacs/2016.3(default)           phyluce/1.5.0(default)
clustalw/2.1(default)             gromacs/2018.2                    quantum-espresso/6.1(default)
clustalw-mpi/0.13(default)        gromacs/4.5.4                     raxml/8.2.11(default)
cmake/3.9.0(default)              gromacs/4.5.4-sbm1.0              rnxcmp/4.0.7(default)
crystal/17_v1.0.2(default)        gromacs/5.1.4                     root/6.10.02(default)
dirac/12.3-mpi(default)           hmmer/3.1b2(default)              rsem/1.2.25(default)
dirac/12.3-serial                 intel/compilers/2017(default)     siesta/4.1-b3(default)
dirac/12.3-smp                    intel/mpi/2017(default)           structure/2.3.4(default)
espresso/3.3.1(default)           java/1.8(default)                 su2/6.0.0(default)
exabayes/1.5(default)             lammps/20170331(default)          tesseract/4.00.00alpha(default)
exciting/carbon(default)          lammps/20180316                   udunits2/2.2.26
foam-extend/4.0(default)          mathematica/9.0(default)          weka/3.8.2(default)
gamess/2018(default)              mopac/17.162(default)
gamit/10.61                       namd/2.12(default)

Carregando módulos

Por exemplo, para carregar a última versão das ferramentas de compilação da Intel:

module load intel/compilers
module load intel/mpi