EM CONSTRUÇÃO

Página oficial do AMBER Documentação e tutoriais oficiais: Amber Tutorials

Recomenda-se começar pelo tutorial “Tutorial 0 - Introduction to LEaP” e os tutoriais “Amber Basic Tutorials”.

É extremamente recomendado o uso e somente uma GPU por Simulação de Dinâmica Molecular. Para entender melhor leia o tópico 🧠 Análise Comparativa de desempenho: 1 GPU vs 2 GPUs para uma única dinâmica com AMBER

Versão utilizada neste cluster: AmberTools 25 + Amber 24

Instalação do Amber 24 (com pmemd e AmberTools 25) localizada em:

/scratch/app/gpu/amber/24/

Utilize os comando abaixo para carregar e visualizar todos os módulos compatíveis com GPUs:

module load arch_gpu/current 
module avail 

---------------------------- /scratch/app/modulefiles_extra/gpu ----------------------------
                                                 gromacs/2024.5_openmpi-4.1_gnu        (D)
   amber/amber24+ambertools25             (D)    lammps/3Nov2022_nv_container
   cp2k/9.1_nv_container                         lammps/15Jun2023_nv_container
   cp2k/2023.1_nv_container                      lammps/2024.8_openmpi-5.0_gnu         (D)
   cp2k/2023.2_nv_container                      namd/2.13-multinode_nv_container
   cp2k/2025.1_openmpi-5.0.6              (D)    namd/2.13-singlenode_nv_container
   cuda/11.8                                     namd/3.0_nv_container
   cuda/12.2                                     namd/3.0.1_multicore_cuda             (D)
   cuda/12.9                              (D)    quantum-espresso/7.3_nv_container
   fftw/3.3_nvhpc                                quantum-espresso/7.4                  (D)
   gromacs/2022.1_nv_container                   tensorflow/23.12-tf2-py3_nv_container
   gromacs/2022.3_nv_container                   tensorflow/24.12-tf2-py3_nv_container
   gromacs/2023.2_nv_container                   tensorflow/25.02-tf2-py3_nv_container (D)
-------------------------------------------------------------------------------------------

Carregue o module o amber24+ambertools25 com o comando abaixo:

module load amber/amber24+ambertools25

• Obtenha um arquivo de estrutura molecular no banco de dados de proteínas Protein data bank no link -> PDB (exemplo: proteína pequena ou ligante).
• Use o comando pdb4amber para corrigir o arquivo, removendo heteroátomos indesejados e ajustando hidrogênios:

pdb4amber input.pdb -o cleaned.pdb

• Crie um script chamado leap.in com o seguinte conteúdo para carregar parâmetros e gerar arquivos do sistema:

source leaprc.protein.ff14SB   # Campo de força para proteínas
mol = loadpdb cleaned.pdb
solvateoct mol TIP3PBOX 10.0  # Adiciona água
addions mol Na+ 0             # Neutraliza carga
saveamberparm mol prmtop inpcrd
quit

• Execute o LEaP com o comando:

tleap -f leap.in

• Crie o arquivo min.in com o seguinte conteúdo:

Minimização
&cntrl
  imin=1, maxcyc=1000, ncyc=500,
  cut=8.0, ntb=1,
/

• Execute a minimização com:

pmemd -O -i min.in -o min.out -p prmtop -c inpcrd -r min.rst

• Isso remove colisões atômicas iniciais.

• Crie o arquivo heat.in com:

Aquecimento NVT
&cntrl
  imin=0, irest=0, ntx=1,
  nstlim=5000, dt=0.002,
  temp0=300, ntt=3, gamma_ln=2.0,
  cut=8.0, ntb=1,
  ntpr=500, ntwx=500,
/

• Execute:

pmemd -O -i heat.in -o heat.out -p prmtop -c min.rst -r heat.rst

• Crie o arquivo equil.in com:

&cntrl
  imin=0, irest=1, ntx=5,
  nstlim=10000, dt=0.002,
  temp0=300, ntt=3, gamma_ln=2.0,
  cut=8.0, ntb=2, ntp=1, taup=2.0,
  ntpr=500, ntwx=500,
/

• Execute:

pmemd -O -i equil.in -o equil.out -p prmtop -c heat.rst -r equil.rst

• Crie o arquivo prod.in para coleta de dados:

Produção NPT
&cntrl
  imin=0, irest=1, ntx=5,
  nstlim=50000, dt=0.002,
  temp0=300, ntt=3, gamma_ln=2.0,
  cut=8.0, ntb=2, ntp=1, taup=2.0,
  ntpr=1000, ntwx=1000, ntwr=5000,
/

• Execute a simulação de produção (use pmemd.cuda para GPU, se disponível):

pmemd.cuda -O -i prod.in -o prod.out -p prmtop -c equil.rst -r prod.rst -x prod.nc

• Para analisar a energia do sistema, use:

process_mdout.perl min.out heat.out equil.out prod.out

• Isso gera gráficos de energia no arquivo summary.EPTOT.
• Para análise da trajetória, use cpptraj:

cpptraj -p prmtop -y prod.nc -x traj.dcd

Este tutorial cobre as etapas básicas para montar um sistema pequeno e rodar uma dinâmica molecular rápida no Amber. Para mais detalhes e instruções de como analisar os dados gerados por favor, leia a documentação oficial de Tutoriais do Amber para construção de sistemas de MD no link -> Building Basic Systems

Simulação de dinâmica com pmemd e pmemd.cuda (Amber):

# Execução em CPU
pmemd -O -i mdin -o mdout -p prmtop -c inpcrd -r restrt -x traj.nc

# Execução com uma GPU
pmemd.cuda -O -i mdin -o mdout -p prmtop -c inpcrd -r restrt -x traj.nc

# Execução com múltiplas GPU com a flag -np N ( sendo N número de GPU disponíveis para uso)
mpirun -np 2 pmemd.cuda -O -i mdin -o mdout -p prmtop -c inpcrd -r restrt -x traj.nc

Exemplo 1 - Execução em CPU com pmemd.MPI

#!/bin/bash
#SBATCH --nodes=1            ### Solicita 1 nó de computação do cluster para o job
#SBATCH --ntasks-per-node=2  ### Solicita 2 tarefas (processos) por nó. Em contextos MPI, isso geralmente significa 2 processos MPI por nó.
#SBATCH --ntasks=2           ### Solicita um total de 2 tarefas para todo o job (equivalente a --ntasks-per-node quando usando 1 nó).
#SBATCH -p lncc-h100_dev     ### Especifica a partição/fila lncc-h100_dev (partição de desenvolvimento com GPUs H100 no LNCC)
#SBATCH -J AMBER-cpu         ### Define o nome do job como "AMBER-cpu" (aparece nos comandos squeue e no histórico).
#SBATCH -o outslurm.out      ### Redireciona a saída padrão (stdout) para o arquivo outslurm.out
#SBATCH -e erro.err          ### Redireciona a saída de erro (stderr) para o arquivo erro.err

cd $SLURM_SUBMIT_DIR
module load arch_gpu/current
module load amber/amber24+ambertools25

EXEC=pmemd.MPI
INPUT=mdin
OUTPUT=mdout
PRMTOP=myprotein.prmtop
INPCRD=myprotein.inpcrd
RESTART=restrt
TRAJ=traj.nc

srun $EXEC -O -i $INPUT -o $OUTPUT -p $PRMTOP -c $INPCRD -r $RESTART -x $TRAJ
#OU substitua o comando pela declarações explicitas abaixo:
srun pmemd.MPI -O -i mdin -o mdout -p prmtop -c inpcrd -r restrt -x traj.nc

Exemplo 2 - Execução em GPU com pmemd.cuda

#!/bin/bash
#SBATCH --nodes=1            ### Solicita 1 nó de computação do cluster para o job
#SBATCH --ntasks-per-node=2  ### Solicita 2 tarefas (processos) por nó. Em contextos MPI, isso geralmente significa 2 processos MPI por nó.
#SBATCH --ntasks=2           ### Solicita um total de 2 tarefas para todo o job (equivalente a --ntasks-per-node quando usando 1 nó).
#SBATCH --gpus-per-node=1    ### Solicita 1 GPU por nó. Para node com GPUs Nvidia H100, alocará uma GPU NVIDIA H100. 
#SBATCH -p lncc-h100_dev     ### Especifica a partição/fila lncc-h100_dev (partição de desenvolvimento com GPUs H100 no LNCC)
#SBATCH -J AMBER-gpu         ### Define o nome do job como "AMBER-gpu" (aparece nos comandos squeue e no histórico).
#SBATCH -o outslurm.out      ### Redireciona a saída padrão (stdout) para o arquivo outslurm.out
#SBATCH -e erro.err          ### Redireciona a saída de erro (stderr) para o arquivo erro.err

cd $SLURM_SUBMIT_DIR
module load arch_gpu/current
module load amber/amber24+ambertools25

###Define o valor das variavies que serão usadas no comando final. (Opcional.Pode ser utilizado o comando diretamente ao final do script)
EXEC=pmemd.cuda
INPUT=mdin
OUTPUT=mdout
PRMTOP=myprotein.prmtop
INPCRD=myprotein.inpcrd
RESTART=restrt
TRAJ=traj.nc

$EXEC -O -i $INPUT -o $OUTPUT -p $PRMTOP -c $INPCRD -r $RESTART -x $TRAJ
#OU substitua o comando pela declarações explicitas abaixo:
srun pmemd.cuda -O -i mdin -o mdout -p prmtop -c inpcrd -r restrt -x traj.nc

📥 Tabela 1 – Arquivos de Entrada

🎆 Tabela 2 – Arquivos de Saída

⚙️ Tabela 3 – Arquivos Internos e de Controle

Página oficial com tutoriais: Amber Tutorials Manual da versão Amber 24: disponível em /scratch/app/gpu/amber/24/doc/Amber24.pdf

Com o módulo carregado, acesse ajuda com o comando abaixo: SERÁ ADICIONADA INFORMAÇÃO AO HELP

module help amber/amber24+ambertools25

------------------------ Module Specific Help for "amber/amber24+ambertools25" ------------------------
Carrega o Amber 24 (pmemd) e AmberTools 25 com suporte a Python 3.12
Amber - Assisted Model Building with Energy Refinement

Este modulo carrega o Amber, um pacote de programas para simulações de
dinâmica molecular de biomoléculas.

Executáveis do pmemd disponíveis (compilados neste ambiente):
  pmemd                   - Versão padrão (serial)
  pmemd.MPI               - Versão paralela usando MPI
  pmemd.cuda              - Versão CUDA para GPU (precisao mista padrao)
  pmemd.cuda.MPI          - Versão CUDA paralela com MPI
  pmemd.cuda_SPFP         - CUDA com precisão mista (single-precision/fixed-point)
  pmemd.cuda_SPFP.MPI     - CUDA SPFP com suporte a MPI
  pmemd.cuda_DPFP         - CUDA com precisão dupla
  pmemd.cuda_DPFP.MPI     - CUDA DPFP com suporte a MPI
  pmemd.decomp            - Versão para decomposição de energia MM/GBSA

Exemplo de uso:
  mpirun -np 4 pmemd.MPI -O -i mdin -o mdout -p prmtop -c inpcrd -r restrt
  pmemd.cuda -O -i mdin -o mdout -p prmtop -c inpcrd -r restrt

É altamente recomendado que, ao utilizar o executável pmemd.cuda do Amber, seja usada uma GPU dedicada para cada simulação de dinâmica molecular (DM). Isso ocorre porque o Amber foi desenvolvido para aproveitar melhor o hardware quando cada simulação roda em uma GPU exclusiva. Para ilustrar, mostramos abaixo dois arquivos de saída chamados mdinfo, gerados após uma simulação teste. O sistema simulado contém cerca de 230.000 átomos, incluindo moléculas de água, uma bicamada lipídica, uma proteína transmembranar, DNA e um ligante. Comparamos o desempenho usando 1 GPU e 2 GPUs para essa simulação.

Arquivo mdinfo-1 com apenas uma GPU NVIDIA H100 e uma Thread de CPU.

[rafael.soares@sdumont2nd5 complex_md_228753_atoms]$ tail mdinfo_1-gpu
|     Elapsed(s) =      11.14 Per Step(ms) =       1.11
|         ns/day =     155.13   seconds/ns =     556.97
|
| Average timings for all steps:
|     Elapsed(s) =      11.14 Per Step(ms) =       1.11
|         ns/day =     155.13   seconds/ns =     556.97
|
|
| Estimated time remaining:      15.5 hours.
 ---------------------------------------------

Arquivo mdinfo_2-gpu com a utilização de 2 GPUs NVIDIA H100 e 2 Thread de CPU.

[rafael.soares@sdumont2nd5 complex_md_228753_atoms]$ tail mdinfo_2-gpus
|     Elapsed(s) =      65.12 Per Step(ms) =       0.81
|         ns/day =     212.29   seconds/ns =     406.98
|
| Average timings for all steps:
|     Elapsed(s) =     139.27 Per Step(ms) =       0.82
|         ns/day =     210.93   seconds/ns =     409.61
|
|
| Estimated time remaining:      11.3 hours.
 ------------------------------------------------------------------------------

💡 Eficiência de uso das GPUs

Apesar do uso de duas GPUs reduzir o tempo por passo e o tempo total da simulação, o ganho de desempenho não é linear. Espera-se que dobrar o número de GPUs traga o dobro de desempenho, mas isso não acontece devido a fatores como:

🧵 Overhead de comunicação entre GPUs

O que significa:

Quando usamos mais de uma GPU para uma mesma simulação (por exemplo, com mpirun -np 2 pmemd.cuda.MPI), é necessário dividir o sistema molecular entre as GPUs. Isso implica que as GPUs precisam trocar dados frequentemente entre si — por exemplo, informações sobre as posições dos átomos, forças e energia. Por que isso importa: Esse processo de troca de dados entre GPUs não é instantâneo. Ele gera um "custo adicional" (chamado overhead) em tempo, principalmente se as GPUs estiverem em sockets diferentes ou a interconexão entre elas não for NVLink, como ocorre em alguns clusters. Como resultado, o tempo economizado pelo paralelismo pode ser parcialmente perdido na comunicação entre as placas.

🔁 Sincronização entre os processos MPI

O que significa:

Quando usamos múltiplos processos MPI para distribuir uma simulação, o AMBER precisa sincronizar os processos frequentemente. Isso garante que cada parte da simulação (executada por uma GPU/processo) esteja na mesma etapa de tempo (timestep) e utilize dados consistentes.

Por que isso importa:

Esse processo de sincronização introduz barreiras de execução, onde um processo mais rápido precisa esperar o mais lento terminar sua parte antes de seguir. Isso limita a eficiência do paralelismo — especialmente se houver desequilíbrio na carga entre os processos ou se o sistema simulado for pequeno demais para justificar a divisão.

📉 Escalabilidade limitada do AMBER para um único sistema em múltiplas GPUs

O que significa:

"Escalabilidade" refere-se à capacidade de um software aproveitar recursos adicionais (como mais GPUs) para reduzir o tempo de execução. No caso do AMBER, quando se tenta simular um único sistema molecular em várias GPUs, o ganho de desempenho não cresce proporcionalmente.

Por que isso acontece:

O sistema molecular tem um número finito de átomos e interações que podem não ser suficientes para manter múltiplas GPUs ocupadas ao mesmo tempo. Além disso, conforme mencionado acima, o overhead de comunicação e sincronização pode anular os benefícios do uso de mais GPUs. O AMBER é muito eficiente em 1 GPU para uma única simulação. Usar mais GPUs pode causar perdas por ineficiência em vez de ganhos reais.

Resultado prático: Para a maioria dos casos em clusters, vale mais a pena rodar múltiplas réplicas simultâneas usando 1 GPU por simulação, do que dividir uma simulação em múltiplas GPUs.

💸 Custo-benefício computacional e Recomendação Prática

Se você tiver duas ou mais GPUs disponíveis, é mais vantajoso rodar duas réplicas independentes (por exemplo, simulações com diferentes sementes de velocidade (Réplicas), ou para análise de convergência) simultaneamente em cada GPU individual, pois em nosso exemplo seriam perdidos cerca de 100 ns/dia de produtividade computacional se usar duas GPUs para a mesma dinâmica. Em ambientes HPC com múltiplas GPUs (como o Cluster SDumont2nd com GPU H100), a melhor prática é alocar uma GPU por simulação independente, rodando réplicas ou sistemas diferentes, em vez de tentar acelerar uma única simulação com múltiplas GPUs.

📘 Observação técnica

O pmemd.cuda.MPI (usado com mpirun -np 2 pmemd.cuda.MPI) ainda possui limitações de escalabilidade em sistemas com comunicação inter-GPU pesada, mesmo com interconexões rápidas como NVLink e InfiniBand. Essas limitações tornam o uso de múltiplas GPUs mais adequado para análise de réplicas independentes (REMD, ensemble simulations), e não para acelerar uma única dinâmica.

REFERÊNCIAS DISPONIVEIS EM https://ambermd.org/doc12/Amber25.pdf