 Painel Issues Pull requests Explorar  Noti cações  Criar…  pricardo 

 root / MFSim  Observar 4  Remover favorito 2 Fork 0

 Código  Issues 4  Pull requests 4  Versões 2  Wiki  Atividade  Con gurações

Página: Utilização do Cluster  HTTP SSH http://www.m ab.mecanica.ufu.br/gite

Utilização do Cluster Editar Nova página Excluir página

MFLab editou esta página 6 dias atrás

Sumário
1. Instruções para leitura
2. Acesso aos clusters
3. Estrutura de diretórios
4. Quotas de usuários
5. Carregando as variáveis de ambiente
6. Submetendo jobs no cluster
7. Pinagem de cores reais

Instruções para leitura

Os comandos precedidos de $ devem ser executados com um usuário padrão do sistema (como o seu usuário) e devem
ser realizados em um terminal (console, konsole, xterm, putty, depende do seu sistema operacional).
Onde está escrito USUARIO em caixa-alta(CAPSLOCK) deve ser substituído pelo nome do seu usuário que foi enviado por
email.

Acesso aos clusters

Login na rede da UFU

navier:

$ ssh USUARIO@10.3.16.17

cluster 3:

$ ssh USUARIO@10.3.16.3

Login fora da rede da UFU

navier:

$ ssh USUARIO@mflab.mecanica.ufu.br -p 60005

cluster 3:

$ ssh USUARIO@mflab.mecanica.ufu.br -p 60003

Download na rede da UFU
navier:

$ scp USUARIO@10.3.16.17:/path_completo_do_arquivo_no_cluster path_local_download

$ spc -r USUARIO@10.3.16.17:/path_completo_da_pasta path_local_da_pasta

cluster 3:

$ scp USUARIO@10.3.16.3:/path_completo_do_arquivo_no_cluster path_local_download

$ spc -r USUARIO@10.3.16.3:/path_completo_da_pasta path_local_da_pasta

Upload na rede da UFU

navier:

$ scp path_arquivo_local USUARIO@10.3.16.17:/path_completo_do_arquivo_no_cluster

$ spc -r path_local_da_pasta USUARIO@10.3.16.17:/path_completo_da_pasta

cluster 3:

$ scp path_local_download USUARIO@10.3.16.3:/path_completo_do_arquivo_no_cluster

$ spc -r path_local_da_pasta USUARIO@10.3.16.3:/path_completo_da_pasta

Download fora da rede da UFU

navier:

$ scp -P 60005 USUARIO@mflab.mecanica.ufu.br:/path_completo_do_arquivo_no_cluster path_local_download

$ spc -r -P 60005 USUARIO@mflab.mecanica.ufu.br:/path_completo_da_pasta path_local_da_pasta

cluster 3:

$ scp -P 60003 USUARIO@mflab.mecanica.ufu.br:/path_completo_do_arquivo_no_cluster path_local_download

$ spc -r -P 60003 USUARIO@mflab.mecanica.ufu.br:/path_completo_da_pasta path_local_da_pasta

Upload fora da rede da UFU

navier:

$ scp -P 60005 path_arquivo_local USUARIO@mflab.mecanica.ufu.br:/path_completo_do_arquivo_no_cluster

$ spc -r -P 60005 path_local_da_pasta USUARIO@mflab.mecanica.ufu.br:/path_completo_da_pasta

cluster 3:

$ scp -P 60003 path_local_download USUARIO@mflab.mecanica.ufu.br:/path_completo_do_arquivo_no_cluster

$ spc -r -P 60003 path_local_da_pasta USUARIO@mflab.mecanica.ufu.br:/path_completo_da_pasta

Estrutura de diretórios
Em ambos os clusters existem diretórios específicos na home do seu usuário que no qual é montado o storage de cada cluster.
Assim é recomendável que você salve os resultados de cada job submetido em cada cluster no diretório dos respectivos
storages, caso contrário, seus jobs poderão sofrer um grande impacto de performance devido a forma como tais storages estão
interconectados ou até mesmo não conseguirem rodar.

cluster navier: /home/USUARIO/st_navier cluster3: /home/USUARIO/st_cluster3

Por exemplo, supondo que o user_a quer executar um job cujo resultado será salvo numa pasta chamada my_test no cluster3,
este deverá criar esta pasta no seguinte caminho: /home/USUARIO/st_cluster3/my_test

Caso o user_a queira submeter um job para o mesmo teste, porém no cluster navier, ele deverá copiar a pasta do teste dele
(my_test) do diretório st_cluster3 para o diretório st_navier no seu home, ou seja:

$ cp -rv /home/USUARIO/st_cluster3/my_test /home/USUARIO/st_navier/my_test

E então entrar nessa pasta e submeter seu job de lá:

$ cd /home/USUARIO/st_navier/my_test
$ qsub my_pbs_script.pbs

Ou caso não queria copiar a pasta do diretório st_cluster3, o usuário deverá informar ao PBS onde deseja salvar a saida do seu
job, redirecionando a saida do programa para o lugar correto no diretório st_navier ou então alterando no seu código para não
abrir o arquivo do diretório corrente e sim de um caminho específico.

Caso utilize windows, pode acessar os clusters utilizando um programa chamado Putty, ou algum outro cliente ssh.

Quotas de usuários
No cluster existe um sistema de quotas para cada usuário. A principio todos os usuários tem uma parcela igual de espaço em
disco para usufruir. O espaço foi calculado com base no número de usuários cadastrados e que utilizam os clusters.

Existem dois tipos de quota:

Soft limits (você está acima da quota, porém este limite é aceitável temporariamente):

permite que você ainda utilize os recursos do disco por um determinado tempo (período de carência) mesmo
tendo excedido a sua quota;
desta forma, proporciona uma certa flexibilidade a todos os usuários e processos, que precisam
ocasionalmente, ultrapassar o limite de spaço em disco;

Hard limits (previne que usuários acima do limite permitido continuem a utilizar espaço em disco):

qualquer tentativa de alocar mais espaço em disco, seja por um processo do usuário ou pelo próprio usuário,
irá falhar, pois o usuário atingiu o limite máximo de quota permitido a ele;
o usuário deve remover alguns arquivos existentes (ficando novamente abaixo da quota) para que assim
consiga criar novos arquivos/diretórios;

Atualmente os limites são:

Limit st_cluster3 st_navier home

soft 850 gb 2 tb 50 gb

hard 2 tb 4 tb 100 gb

total 19 tb 66 tb 6 tb

Os limites ainda são bem altos, e serão ajustados conforme necessário.

Caso necessite de uma quota de espaço em disco maior que o soft limit, é necessário me enviar um email
(johnatas@nibblelab.com ou mflab@nibblelab.com), com a tag [navier] ou [cluster3] no campo do assunto, e justificar o porque
da necessidade, bem como a quantidade que gostaria que fosse reservada, para que esta seja analisada.

Carregando as variáveis de ambiente

Depois de logado no cluster, você precisará carregar as variáveis de ambiente referentes aos compiladores, bibliotecas e
programas que você deseja utilizar para desenvolver seu software ou submeter um job, para tal, deve-se utilizar o software
chamado “lmod” instalado no cluster (você pode ter mais informações aqui: http://lmod.readthedocs.io/en/latest/) que irá
carregar as bibliotecas desejadas e coloca-las a sua disposição para uso. Caso necessite de algum outro software que não
esteja instalado, basta mandar um email solicitando a instalação, que este será instalado e será disponibilizado um modulo para
esse novo software.
Modules

Os módulos disponíveis em cada cluster são diferentes e podem ser verificados com o comando:

$ module avail

Esse comando irá listar todos os modulos (softwares) instalados, como por exemplo abaixo:

$ module avail

----------------------------------------------------------------
/opt/modulefiles/Core
boost/1.57 gcc/4.8.2 intel/12.1.0.032
metis/4.0.3 python/2.7.12 scons/2.3.3 szip/2.1
cmake/2.8.11 gcc/4.9.1 (D) intel/13.0.0.028 (D)
open64/4.5.2.1 python/3.4 (D) scons/2.4.1 (D)
xflow/90.0
cuda/6.0 glib/2.28.3 libnuma/2.0.9
parmetis/3.2.0 scalapack/0.96 starccm/7.6.12
zlib/1.2.6
gcc/4.3.4 hwloc/1.6.1 lis/1.2.53
python/2.7.5 scons/1.0.1 starccm/9.4.11 (D)

---------------------------------------------------------
/opt/sw/lmod/lmod/modulefiles/Core
lmod/5.8.1 settarg/5.8.1

Ou pelo comando:

$ module spider

que informa detalhes sobre cada software instalado:

-----------------------------------------------------------------
The following is a list of the modules currently available:
-----------------------------------------------------------------
gnu: gnu/5.4.0
GNU Compiler Family (C/C++/Fortran for x86_64)

hdf5: hdf5/1.8.17
A general purpose library and file format for storing scientific data

imb: imb/4.1
Intel MPI Benchmarks (IMB)

mpiP: mpiP/3.4.1
mpiP: a lightweight profiling library for MPI applications.

mpich: mpich/3.2
MPICH MPI implementation

mvapich2: mvapich2/2.2
OSU MVAPICH2 MPI implementation

openmpi: openmpi/1.10.4
A powerful implementation of MPI

papi: papi/5.4.3
Performance Application Programming Interface

pdtoolkit: pdtoolkit/3.22
PDT is a framework for analyzing source code

phdf5: phdf5/1.8.17
A general purpose library and file format for storing scientific data

prun: prun/1.1
job launch utility for multiple MPI families

scalasca: scalasca/2.3.1
 Toolset for performance analysis of large-scale parallel applications

scorep: scorep/3.0
Scalable Performance Measurement Infrastructure for Parallel Codes

sionlib: sionlib/1.7.0
Scalable Performance Measurement Infrastructure for Parallel Codes

tau: tau/2.26
Tuning and Analysis Utilities Profiling Package

valgrind: valgrind/3.11.0
Memory debugging utilities

Supondo que eu queira usar para desenvolver meu trabalho o compilador gcc, o openmpi compilado com esse compilador e o
hdf5, eu posso digitar o seguinte comando para carregar as bibliotecas que desejo:

$ module load gcc/4.9.1 openmpi/1.8.4 hdf5

A cada modulo carregado, novos podem ser mostrados no output com comando “module avail”, pois um módulo, pode
depender do outro, como pode ser observado na saída abaixo após carregar os três módulos acima:

$ module avail
----------------------------------------------------
/opt/modulefiles/MPI/gcc/4.9.1/openmpi/1.8.4
hdf5/1.8.14 petsc/3.5.2 petsc/3.7.5 (D) sundials/2.6.1
zoltan/3.81

---------------------------------------------------------
/opt/modulefiles/Compiler/gcc/4.9.1
cantera/2.2p glib/2.28.8 (D) lapack/3.6.0 openmpi/1.8.4
openmpi-fl/1.8.4 szip/2.1 (D) valgrind/3.9.0

----------------------------------------------------------------
/opt/modulefiles/Core
boost/1.57 gcc/4.8.2 intel/12.1.0.032
metis/4.0.3 python/2.7.12 scons/2.3.3 szip/2.1
cmake/2.8.11 gcc/4.9.1 (D) intel/13.0.0.028 (D)
open64/4.5.2.1 python/3.4 (D) scons/2.4.1 (D)
xflow/90.0
cuda/6.0 glib/2.28.3 libnuma/2.0.9
parmetis/3.2.0 scalapack/0.96 starccm/7.6.12
zlib/1.2.6
gcc/4.3.4 hwloc/1.6.1 lis/1.2.53
python/2.7.5 scons/1.0.1 starccm/9.4.11 (D)

---------------------------------------------------------
/opt/sw/lmod/lmod/modulefiles/Core
lmod/5.8.1 settarg/5.8.1

Caso não seja especificada a versão, como no “hdf5” acima, o lmod irá procurar pela versão default (marcada com um (D) ou a
maior instalada), que em geral é a mais atual do software instalado.

Para listar quais modulos estão carregados para o seu usuário basta digitar:

$ module list
Currently Loaded Modules:
1) gcc/4.9.1 2) hwloc/1.6.1 3) openmpi/1.8.4 4) szip/2.1 5)hdf5/1.8.14

Para remover um modulo carregado, digite:

$ module rm nome-do-modulo

ou

$ module unload nome-do-modulo

onde nome-do-modulo poderia ser “gcc” ou “gcc/4.9.1 “, por exemplo:

$ module rm gcc

caso tenha alguma dúvida com relação a sintaxe do comando module, você pode consultar a documentação aqui:
http://lmod.readthedocs.io/en/latest/ ou dentro do próprio cluster como abaixo pelo comando man, após carregar o modulo
modules:

$ man module

[Opicional]

Você também pode utilizar o Lmod para criar seus próprios módulos para softwares instalados na sua pasta HOME, por
exemplo. Para fazer isso basta seguir os passos abaixo:

Primeiro crie um diretório aonde ficaram salvos seus módulos (um módulo é um script escrito na linguagem tcl ou lua que
configura o ambiente atribuindo váriaveis do sistema que seram utilizadas pelo seu software durante a compilação e/ou
execução)

$ mkdir /home/USUARIO/privatemodules

Configure seu arquivo /home/USUARIO/.bashrc para carregar os seus módulos no momento do login

$ echo "source /etc/profile.d/modules.sh" >> ~/.bashrc

$ echo "module use /home/USUARIO/privatemodules" >> ~/.bashrc

Dentro da pasta privatemodules organize seus módulos como preferir, por exemplo, supondo que eu tenha instalado no meu
HOME o software chamado TESTCOMPILER no seguinte ramo de diretórios:
/home/USUARIO/softwares/TESTCOMPILER/1.2.3 onde 1.2.3 seria a versão do meu software. Assim eu poderia criar a
seguinte organização de módulos:

$ mkdir /home/USUARIO/privatemodules/TESTCOMPILER

e dentro dessa pasta criar meu script com o nome de “1.2.3”:

$ vim /home/USUARIO/privatemodules/TESTCOMPILER/1.2.3

Colocando, por exemplo o conteudo abaixo:

############################################################
#%Module1.0#################################################
proc ModulesHelp {} {
global name version prefix man_path
puts stderr "\t [module-info name] - put here some help message"
}

# for Tcl script use only

set name TESTCOMPILER
set version 1.2.3
set prefix /home/USUARIO/softwares/$name/$version

if {![ file exists $prefix ]} {

puts stderr "\t[module-info name] Load Error: $prefix does not exist"
break
exit 1
}
module−whatis "adds $name version $version"
prepend−path PATH $prefix/bin
############################################################
Dessa forma, quando eu logasse novamente no sistema (ou recarregasse meu bashrc, por exemplo, usando o comando: $
bash) ao utilizar o comando:

$ module avail

seria mostrado para mim meu novo modulo, como abaixo:

------------------------ /home/USUARIO/privatemodules ------------------------

TESTCOMPILER/1.2.3

e bastaria eu carrega-lo como os demais modulos do sistema:

$ module load TESTCOMPILER

Note que no meu script acima, eu setei a váriavel de ambiente PATH com o caminho “$prefix/bin” onde prefix é igual a:
“/home/USUARIO/softwares/TESTCOMPILER/1.2.3”, ou seja, estou acrescentando no meu PATH o caminho:
“/home/USUARIO/softwares/TESTCOMPILER/1.2.3/bin” o que significa que meus executáveis do programa TESTCOMPILER
devem estar nessa pasta para que eu consiga acessa-los de qualquer lugar do cluster.

Submetendo jobs no cluster

Após carregar os módulos apropriados, você está pronto para começar a trabalhar, você poderá utilizar algum editor de texto
de sua preferência para isso, no cluster há vários (emacs, vim, vi, nano, etc). Após alterar seu código, e compila-lo você poderá
submete-lo a um nó, para isso é utilizado o PBSpro. Qualquer dúvida com relação a sintaxe pode ser sanada com os manuais
que estão disponíveis aqui: ftp://mflab.mecanica.ufu.br/suporte/manuais/

Para submeter um job ao cluster, deve-se usar o comando qsub, como no exemplo abaixo:

1) qsub -q serial -l select=1:mem=2gb SCRIPT_DE_SUBMISSAO

2) Ou então deixando todos os parâmetros definidos no próprio script (SCRIPT_DE_SUBIMISSAO), como nos scripts de
exemplo de submissão que estão em anexo, mas posso lhe ajudar pessoalmente se tiver dificuldades para submeter seus jobs.

O walltime deve ser especificado no script de submissão do job, caso não seja, o seu job rodará por apenas 168 hrs, uma
semana.

Caso queira que seu job rode por mais de uma semana, você precisa especificar o walltime, pode faze-lo assim:

#PBS -l walltime=HH:MM:SS

substituindo HH:MM:SS pela quantidade de horas, minutos e segundos que deseja que seu job rode.

Configuração da filas:

nome da fila / default walltime / qtdade de nós / qtdade de cores(sem HyperThread habilitado) / Prioridade urgent / -- / 17 (todos
os nós) / 680 / 160* debug / 01:00:00 / 1 / 40 / 155 parallel_8 / 168:00:00 / 17 / 680 / 100 parallel_16 / 168:00:00 / 17 / 680 / 100
parallel_32 / 168:00:00 / 17 / 680 / 100 parallel_64 / 168:00:00 / 17 / 680 / 100 parallel_128 / 168:00:00 / 17 / 680 / 100
parallel_256 / 168:00:00 / 17 / 680 / 100 parallel_512 / 168:00:00 / 17 / 680 / 100

Para ter permissão para submeter jobs para a fila “urgent” é necessário enviar um email para johnatas@nibblelab.com (ou
mflab@nibblelab.com) com cópia para o prof. Aristeu ou prof. João Marcelo, justificando o porque da necessidade.

OBS.:

Quanto maior o valor da prioridade maior é a prioridade da fila.

Quanto menor o walltime(especificado pelo usuário com o parâmetro:

#PBS -l walltime=hh:mm:ss) maior é a prioridade. Caso não seja

Depois de especificado o walltime, o job terá o walltime da fila na qual foi escalonado (que é 168 hrs por padrão) , tendo
portanto a mesma prioridade de qualquer outro e podendo ficar muito tempo na fila.
 Na maioria das filas não existe limite para o walltime, você pode especificar o tempo que quiser, porem, quanto maior o
walltime, menos prioridade seu job terá, e consequentemente, poderá ficar mais tempo na fila ou até suspenso. Para
verificar o limite do walltime, quando existente, você pode utilizar o comando: $ qstat -q
Quanto menos recursos o job exigir, maior será a sua prioridade

Caso nenhuma fila seja especificada o PBS irá escolher uma que se aproxime das especificações feitas pelo usuário no script
de submissão do job.

Visualizando las

Para visualizarem as filas, podem usar o comando qstat com os parâmetros -q ou -Q. Por exemplo:

$ qstat -q

ou

$ qstat -Q

Submetendo jobs
Se você pretende usar OpenMP em conjunto com MPI, vai precisa especificar quantas threads quer, por exemplo:

#PBS -l select=4:ncpus=16:mpiprocs=1:mem=10gb:ompthreads=2

Este comando irá requisitar por: 4 nós, com 16 cores em cada, 10gb por nó, e 2 threads por core

Você pode ler mais a respeito na página 129, no capítulo “4.5 Hybrid MPI-OpenMP Jobs” do manual do usuário do PBSpro
(disponível aqui: ftp://mflab.mecanica.ufu.br/suporte/manuais/PBSPro-12.0/PBSProUserGuide12.pdf)

Após submeter o job, para verificar o status do seua job, basta rodar o comando:

$ qstat

O comando qstat possui vários argumentos utéis, e a descrição de todos eles e como usar, podem ser facilmente lidas
digitando:

$man qstat

Caso queira matar um job que tenha submetido, pode digitar:

$qdel ID_DO_JOB

A ID_DO_JOB é mostrada no momento da submissão e também listada pelo comando qstat, no exemplo abaixo submeto um
job serial cujo ID foi 458, depois visualizo o status dele como R(rodando) e mato o job com o comando qdel, passando o ID do
job, por ultimo vejo se ele sumiu realmente da lista de jobs:

$ qsub -q serial -l select=1,mem=2gb teste.pbs

458.cluster2.local
$ qstat
Job id Name User Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
359.cluster2 slug_flow2 mmvillar 693:46:5 R
serial
400.cluster2 SensDx3 mrpivello 313:21:5 R
serial
401.cluster2 A2dt1e-5 mrpivello 310:56:3 R
serial
403.cluster2 canalL3 mmvillar 308:29:2 R
serial
456.cluster2 slug_flow3 mmvillar 23:55:17 R
serial
 458.cluster2 testeserial rsaramago 00:03:05 R serial
$ qdel 458
$ qstat
Job id Name User Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
359.cluster2 slug_flow2 mmvillar 693:47:3 R
serial
400.cluster2 SensDx3 mrpivello 313:23:2 R
serial
401.cluster2 A2dt1e-5 mrpivello 310:58:0 R
serial
403.cluster2 canalL3 mmvillar 308:30:5 R
serial
456.cluster2 slug_flow3 mmvillar 23:56:02 R serial

Voce pode monitorar o status dos nós, e se estes estão vazios, pelos comandos abaixo:

Listar todos os nós e a quantidade de recurso sendo usada:

# pbsnodes -a

Para acompanharem o status dos jobs, recomendo os seguintes comandos:

$ qstat [ID_JOB]
$ tracejob ID_JOB

Fila de speedup
A fila speedup e urgent precisam de permissão para executar, pois elas possuem maior prioridade que as demais e podem
preemptar(remover) jobs com menores prioridades. Além disso o placement padrão da fila speedup é place=scatter:excl, ou
seja, caso não informado o place no script de submissão, o default já é deixar o nó exclusivo.

Ela possui maior prioridade que as demais filas, significa que no calculo das prioridades dos jobs (em fila - Q ou executando -
R), considerando walltime, número de processos e demais recursos, o valor de prioridade da fila speedup “converge” mais
rápido que o das demais filas, logo um job aguardando na fila speedup pode não entrar na hora que é submetido se o cluster
tiver muito cheio, mas com o tempo ele entrará mais rápido que outros jobs, além do mais, como o escalonador de jobs
recalcula a prioridade de todos os jobs rodando e na fila a certo intervalo de tempo, caso o o job que está na fila atinja um valor
de prioridade maior um outro em execução, o escalonador tira o job que ta rodando e coloca o da fila speedup/urgent.

A fila de speedup tem os seguintes limites:

resources_max.walltime = 168:00:00 resources_min.nodect = 1 resources_default.mem = 512mb resources_default.place =

scatter:excl resources_default.walltime = 01:00:00

Caso queira que seu job rode na fila speedup com um placement diferente de scatter:excl, ou seja, não se importa do seu job
dividir processamento com outros jobs, você deve alterar o placement do job. Para isso, dentre os possíveis parâmetros que
podem ser visto aqui na página 44 na tabela 3-1 do manual(ftp://mflab.mecanica.ufu.br/suporte/manuais/PBSPro-
12.0/PBSProUserGuide12.pdf), os principais são:

free - Coloca seu job em qq nó onde há recurso disponível pack - Agrupa todos os processos em um mesmo nó, caso tenha
selecionado mais de um nó (select maior que 1) scatter - Cada nó especificado no select vai para um nó diferente, não
agrupando os processos em um único nó mesmo que caibam excl - Apenas o seu job executa no nó escolhido

Há outros parâmetros que você pode conferir no manual e eles podem ser agrupados usando o “:” como separador, por
exemplo: #PBS -l place=scatter:excl.

O default das outras filas é o place=free

Pinagem de cores reais

No cluster Navier o hyperthread está habilitado, o que faz com que cada nó tenha 40 cores de processamento. Isso porque
cada nó, de um total de 17 atualmente, possuí dois processadores cada um com 10 cores reais cada (20 cores reais no total
em cada nó), como o hyperthread está habilitado, o nó paassa a ter 40 cores, 20 reais e 20 virtuais.

Caso queira apenas utilizar os cores reais, deve-se “pinar” o seu processo no determinado core. Para isso, recomendo que,
caso utilize o openmpi use o comando cpu-set e caso utilize o compilador da intel, use o comando dplace (que é uma
ferramenta da SGI), este ultimo funciona apenas para o mpi da intel.
 Para utilizar o cpu-set com o openmpi você pode seguir o exemplo abaixo, em que são pinados 4 cores reais, os cores: 0,1,2 e
3

mpirun --cpu-set 0-3 --map-by core --bind-to core -n $CORES $PBS_O_WORKDIR/mpiteste > $PBS_O_WORKDIR/out

Caso queira usar o dplace com o mpi da intel, a sintaxe é a seguinte:

mpirun dplace -c 0-3 -n $CORES $PBS_O_WORKDIR/mpiteste > $PBS_O_WORKDIR/out

Para visualizar o mapa dos IDs dos cores em cada nó, você pode executar o comando: “numactl -H” no nó desejado.

Ele mostrará algo como abaixo em que, para o caso do Navier, como cada nó tem 2 processadores com 20 cores cada, os 10
primeiros cores de cada processador(socket) são os cores reais, logo os cores reais do nó r1i0n0 são 0 à 9 e 10 à 19

USUARIO@navier:~/st_navier> ssh r1i0n0 numactl -H

available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 20 21 22 23 24 25 26 27 28 29
node 0 size: 65506 MB
node 0 free: 1118 MB
node 1 cpus: 10 11 12 13 14 15 16 17 18 19 30 31 32 33 34 35 36 37 38 39
node 1 size: 65536 MB
node 1 free: 354 MB
node distances:
node 0 1
0: 10 21
1: 21 10

Assim, tanto no cpu-set como no dplace, para reservar todos os 20 cores reais o comando é passado por intervalo: --cpu-set 0-
19 ou dplace -c 0-19.

Caso queira dois cores específicos, basta separa-los por vírgula, por exemplo: --cpu-set 0,2,4,12,13,15

Mais informações podem ser obtidas aqui: cpu-set: https://www.open-mpi.org/doc/v2.0/man1/mpirun.1.php dplace:

http://www.ibiblio.org/gferg/ldp/man/man1/dplace.1.html

© Gitea Versão: e9b984e Página: 58ms Template: 1ms  português do Brasil JavaScript licenses API Site Go1.11.1