orte-submit - Online na nuvem

PROGRAMA:

NOME

orte-submit, ompi-submit - Execute trabalhos seriais e paralelos no Open MPI usando um DVM.

Nota: ompi-submeter e orte-submeter são sinônimos um do outro. Usando qualquer um dos nomes
irá produzir o mesmo comportamento.

SINOPSE

Modelo de Dados Múltiplos de Processo Único (SPMD):

ompi-submeter [opções] [ ]

Modelo de Dados Múltiplos com Instrução Múltipla (MIMD):

ompi-submeter [global_options]
[local_options1] [ ]:
[local_options2] [ ]:
...:
[local_optionsN] [ ]

Observe que em ambos os modelos, invocando ompi-submeter por meio de um nome de caminho absoluto é equivalente a
especificando o --prefixo opção com um valor equivalente ao diretório onde ompi-
enviar reside, menos seu último subdiretório. Por exemplo:

% / usr / local / bin / ompi-submit ...

é equivalente a

% ompi-submit --prefixo / usr / local

QUICK RESUMO

Use of orte-submeter exige que Você primeiro começo da Distribuído Virtual Máquina (DVM)
utilização orte-dvm.

Se você está simplesmente procurando como executar um aplicativo MPI, provavelmente deseja usar um
linha de comando da seguinte forma:

% ompi-submit [-np X] [--hostfile ]

Isso irá executar X cópias de em seu ambiente de tempo de execução atual (se estiver executando sob
um gerenciador de recursos compatível, Open MPI's ompi-submeter geralmente usará automaticamente o
gerenciador de recursos correspondente inicializador do processo, em oposição a, por exemplo, rsh or ssh,
que requerem o uso de um hostfile, ou terão como padrão a execução de todas as cópias do X no
localhost), agendamento (por padrão) em rodízio por slot de CPU. Veja o resto de
esta página para mais detalhes.

Observe que ompi-submit vincula processos automaticamente a partir do início da v1.8
Series. Dois padrões de ligação são usados ​​na ausência de quaisquer diretivas adicionais:

Vincular para testemunho: quando o número de processos é <= 2

Vincular para soquete: quando o número de processos é> 2

Se o seu aplicativo usa threads, então você provavelmente quer ter certeza de que não está
vinculado a todos (especificando --bind-to none), ou vinculado a vários núcleos usando um
nível de ligação apropriado ou número específico de elementos de processamento por aplicativo
processo.

OPÇÕES

ompi-submeter irá enviar o nome do diretório onde foi chamado no nó local para
cada um dos nós remotos e tente mudar para esse diretório. Veja o "Atual
Na seção Diretório de Trabalho "abaixo para obter mais detalhes.

O executável do programa. Este é identificado como o primeiro argumento não reconhecido
para ompi-submit.

Passe esses argumentos de tempo de execução para cada novo processo. Estes devem ser sempre os
últimos argumentos para ompi-submeter. Se um arquivo de contexto de aplicativo for usado, será
ignorado.

-h, --Socorro
Mostra a ajuda para este comando

-q, --quieto
Suprima mensagens informativas de orte-submit durante a execução do aplicativo.

-v, --verbose
Seja prolixo

-V, --versão
Imprimir o número da versão. Se nenhum outro argumento for fornecido, isso também causará
orte-submit para sair.

Use uma das seguintes opções para especificar em quais hosts (nós) do DVM executar.
Especificar hosts fora do DVM resultará em erro.

-H, -hospedeiro, --hospedeiro
Lista de hosts nos quais invocar processos.

-hostfile, --hostfile
Forneça um hostfile para usar.

-máquinafile, --machinefile
Sinônimo de -hostfile.

As opções a seguir especificam o número de processos a serem iniciados. Observe que nenhum dos
opções implicam em uma política de ligação específica - por exemplo, solicitar N processos para cada soquete
não significa que os processos serão vinculados ao soquete.

-c, -n, - n, -np <#>
Execute esse número de cópias do programa nos nós fornecidos. Esta opção indica que
o arquivo especificado é um programa executável e não um contexto de aplicativo. Se não
valor é fornecido para o número de cópias a executar (ou seja, nem o "-np" nem
seus sinônimos são fornecidos na linha de comando), Open MPI será executado automaticamente
uma cópia do programa em cada slot de processo (veja abaixo a descrição de um "processo
slot "). Este recurso, no entanto, só pode ser usado no modelo SPMD e retornará
um erro (sem iniciar a execução do aplicativo) caso contrário.

—Map-by ppr: N:
Inicie N vezes o número de objetos do tipo especificado em cada nó.

-npersocket, --npersocket <#persocket>
Em cada nó, inicie muitos processos vezes o número de soquetes de processador em
o nó. o -npersocket opção também ativa o -ligar ao soquete opção.
(obsoleto em favor de --map-by ppr: n: socket)

-npernode, --npernode <#pernode>
Em cada nó, inicie muitos processos. (descontinuado em favor de --map-by
ppr: n: nó)

-pernodo, --pernode
Em cada nó, inicie um processo - equivalente a -npernode 1. (obsoleto em
favor de --map-by ppr: 1: nó)

Para mapear processos:

--map-por
Mapeie para o objeto especificado, o padrão é soquete. As opções com suporte incluem slot,
hwthread, core, L1cache, L2cache, L3cache, soquete, numa, placa, nó, sequencial,
distância e ppr. Qualquer objeto pode incluir modificadores adicionando um: e qualquer
combinação de PE = n (liga n elementos de processamento a cada proc), SPAN (equilíbrio de carga
os processos na alocação), OVERSUBSCRIBE (permitir mais processos em um nó
do que elementos de processamento) e NOOVERSUBSCRIBE. Isso inclui PPR, onde o
padrão seria encerrado por outro dois-pontos para separá-lo dos modificadores.

-bycore, --bycore
Mapear processos por núcleo (preterido em favor de --map-by core)

-bysocket, --bysocket
Mapear processos por socket (obsoleto em favor de --map-by socket)

-nolocal, --nolocal
Não execute nenhuma cópia do aplicativo lançado no mesmo nó que orte-submit
está correndo. Esta opção substituirá a listagem do host local com --hospedeiro Ou qualquer
outro mecanismo de especificação de host.

-nooversubscribe, --nooversubscribe
Não sobrescreva nenhum nó; erro (sem iniciar nenhum processo) se o
o número solicitado de processos causaria excesso de inscrições. Esta opção implicitamente
define "max_slots" igual ao valor "slots" para cada nó.

-bynode, --bynode
O lançamento de processos um por nó, alternando por nó em rodízio. Esse
espalha processos uniformemente entre os nós e atribui classificações MPI_COMM_WORLD em uma rodada-
robin, "por nó".

Para ordenar as classificações dos processos em MPI_COMM_WORLD:

- classificado por
Classifique no modo round-robin de acordo com o objeto especificado, o padrão é ranhura.
As opções com suporte incluem slot, hwthread, core, L1cache, L2cache, L3cache, socket,
numa, placa e nó.

Para ligação de processo:

--ligar a
Vincular processos ao objeto especificado, o padrão é core. As opções suportadas incluem
slot, hwthread, core, l1cache, l2cache, l3cache, socket, numa, board e nenhum.

-cpus-por-proc, --cpus-por-proc <#perproc>
Vincule cada processo ao número especificado de cpus. (descontinuado em favor de --map-
por : PE = n)

-cpus-por-rank, --cpus-por-classificação <#perrank>
Alias ​​para -cpus-por-proc. (descontinuado em favor de --map-by : PE = n)

-ligar ao núcleo, --bind-to-core
Processos de vinculação a núcleos (preterido em favor de --bind-to core)

-ligar ao soquete, --bind-to-soquete
Vincular processos a soquetes de processador (obsoleto em favor de --bind-to soquete)

-ligar a nenhum, --bind-to-none
Não vincular processos (obsoleto em favor de --bind-to none)

-ligações de relatório, --report-bindings
Relate quaisquer ligações para processos iniciados.

-lista de slots, --lista de slots
Lista de IDs de processador a serem usados ​​para vincular processos MPI. As ligações especificadas
será aplicado a todos os processos MPI. Veja a explicação abaixo para sintaxe.

Para rankfiles:

-rf, --rankfile
Fornece um arquivo rankfile.

Para gerenciar I / O padrão:

-nome do arquivo de saída, --output-filename
Redirecione o stdout, stderr e stddiag de todos os processos para um processo exclusivo
versão do nome do arquivo especificado. Quaisquer diretórios no nome do arquivo irão
ser criado automaticamente. Cada arquivo de saída consistirá em filename.id, onde o
id será a classificação dos processos em MPI_COMM_WORLD, preenchido à esquerda com zeros para
ordenação correta nas listagens.

-stdin, --stdin
A classificação MPI_COMM_WORLD do processo que receberá o stdin. O padrão é
encaminhar stdin para MPI_COMM_WORLD classificação 0, mas esta opção pode ser usada para encaminhar
stdin para qualquer processo. Também é aceitável especificar Nenhum, indicando que não
os processos devem receber stdin.

-tag-saída, --tag-saída
Identifique cada linha de saída para stdout, stderr e stddiag com [ID de trabalho,
MCW_rank] indicando o ID do trabalho do processo e a classificação MPI_COMM_WORLD do
processo que gerou a saída e o canal que a gerou.

-saída de carimbo de data / hora, --timestamp-saída
Registre a data e hora de cada linha de saída em stdout, stderr e stddiag.

-xml, --xml
Fornece todas as saídas para stdout, stderr e stddiag em formato xml.

-xterm, --xterm
Exibir a saída dos processos identificados por suas classificações MPI_COMM_WORLD em
janelas xterm separadas. As classificações são especificadas como uma lista separada por vírgulas de
intervalos, com -1 indicando todos. Uma janela separada será criada para cada
processo especificado. Nota: O xterm normalmente encerrará a janela após o encerramento
do processo em execução nele. No entanto, adicionando um "!" para o final da lista
de classificações especificadas, as opções adequadas serão fornecidas para garantir que o xterm mantenha
a janela aberta depois de o processo termina, permitindo assim que você veja o processo '
saída. Cada janela do xterm posteriormente precisará ser fechada manualmente. Nota: In
alguns ambientes, o xterm pode exigir que o executável esteja no caminho do usuário, ou
ser especificado em termos absolutos ou relativos. Assim, pode ser necessário especificar um
executável local como "./foo" em vez de apenas "foo". Se o xterm falhar em encontrar o
executável, ompi-submit travará, mas ainda responderá corretamente a um ctrl-c. Se
isso acontece, por favor, verifique se o executável está sendo especificado corretamente e tente
novamente.

Para gerenciar arquivos e ambiente de execução:

-caminho, --caminho
que será usado ao tentar localizar os executáveis ​​solicitados. Esse
é usado antes de usar a configuração PATH local.

--prefixo
Diretório de prefixo que será usado para definir o PATH e LD_LIBRARY_PATH na
nó remoto antes de invocar Open MPI ou o processo de destino. Veja o "Remoto
Seção Execução ", abaixo.

--preload-binário
Copie o (s) executável (es) especificado (s) para máquinas remotas antes de iniciar remotamente
processos. Os executáveis ​​serão copiados para o diretório da sessão Open MPI e
será excluído após a conclusão do trabalho.

--preload-arquivos
Pré-carregue a lista de arquivos separados por vírgulas para o diretório de trabalho atual do
máquinas remotas onde os processos serão iniciados antes de iniciar esses processos.

--preload-files-dest-dir
O diretório de destino a ser usado para arquivos pré-carregados, se diferente do atual
diretório de trabalho. Por padrão, os caminhos absolutos e relativos fornecidos por
--preload-files são usados.

-wd
Sinônimo de -wdir.

-wdir
Mude para o diretório antes que o programa do usuário seja executado. Veja o "Atual
Seção Working Directory "para notas sobre caminhos relativos. Nota: Se o -wdir opção
aparece na linha de comando e em um contexto de aplicativo, o contexto irá
têm precedência sobre a linha de comando. Assim, se o caminho para o wdir desejado for
diferente nos nós de back-end, então deve ser especificado como um caminho absoluto que
está correto para o nó de backend.

-x
Exporte as variáveis ​​de ambiente especificadas para os nós remotos antes de executar o
programa. Apenas uma variável de ambiente pode ser especificada por -x opção. Existir
variáveis ​​de ambiente podem ser especificadas ou novos nomes de variáveis ​​especificados com
valores correspondentes. Por exemplo:
% ompi-submit -x DISPLAY -x OFILE = / tmp / out ...

O analisador para o -x opção não é muito sofisticada; nem mesmo entende
valores cotados. Os usuários são aconselhados a definir variáveis ​​no ambiente e, em seguida, usar
-x para exportá-los (não defini-los).

Configurando parâmetros MCA:

-gmca, --gmca
Passe parâmetros MCA globais que são aplicáveis ​​a todos os contextos. é o
nome do parâmetro; é o valor do parâmetro.

-mca, --mca
Envie argumentos para vários módulos MCA. Consulte a seção "MCA" abaixo.

Para depuração:

-depurar, --depurar
Chame o depurador de nível de usuário indicado pelo orte_base_user_debugger MCA
parâmetro.

-depurador, --depurador
Sequência de depuradores para procurar quando --depurar é usado (ou seja, um sinônimo para
orte_base_user_debugger Parâmetro MCA).

-televisão, --televisão
Inicie processos no depurador TotalView. Compatibilidade com versões anteriores obsoleta
bandeira. Sinônimo de --depurar.

Existem também outras opções:

--allow-executar como root
Permitir ompi-submeter para ser executado quando executado pelo usuário root (ompi-submeter o padrão é
abortando quando lançado como usuário root).

-abortado, --abortado <#>
Defina o número máximo de processos abortados a serem exibidos.

--aplicativo
Fornece um appfile, ignorando todas as outras opções de linha de comando.

-cf, --cartofile
Forneça um arquivo de cartografia.

--hetero
Indica que vários app_contexts estão sendo fornecidos e são uma mistura de 32/64 bits
binários.

-ompi-servidor, --ompi-servidor <uri or arquivo>
Especifique o URI do servidor Open MPI (ou o ompi-submit a ser usado como o
servidor), o nome do arquivo (especificado como arquivo: nome do arquivo) que contém aquele
info, ou o PID (especificado como pid: #) do ompi-submit a ser usado como
o servidor. O servidor Open MPI é usado para oferecer suporte a dados de vários aplicativos
troca via MPI-2 MPI_Publish_name e MPI_Lookup_name funções.

As opções a seguir são úteis para desenvolvedores; eles geralmente não são úteis para a maioria
Usuários ORTE e / ou MPI:

-d, --debug-devel
Habilite a depuração do OmpiRTE (a camada de tempo de execução no Open MPI). Isso não é
geralmente útil para a maioria dos usuários.

Pode haver outras opções listadas com ompi-submeter --Socorro.

Meio Ambiente Variáveis
MPIEXEC_TIMEOUT
O número máximo de segundos que ompi-submeter (MPIEXEC) correrá. Depois de tantos
segundos, ompi-submeter abortará o job lançado e sairá.

DESCRIÇÃO

Uma invocação de ompi-submeter inicia um aplicativo MPI em execução no Open MPI. Se o
o aplicativo é um único processo de dados múltiplos (SPMD), o aplicativo pode ser especificado em
da ompi-submeter linha de comando.

Se a aplicação for de instrução múltipla de dados múltiplos (MIMD), composta de múltiplas
programas, o conjunto de programas e argumentos podem ser especificados de duas maneiras: Estendido
Argumentos da linha de comando e contexto do aplicativo.

Um contexto de aplicativo descreve o conjunto de programas MIMD, incluindo todos os argumentos em um
arquivo separado. Este arquivo contém essencialmente vários ompi-submeter linhas de comando, menos
o próprio nome do comando. A capacidade de especificar opções diferentes para diferentes
instanciações de um programa é outro motivo para usar um contexto de aplicativo.

Os argumentos estendidos da linha de comando permitem a descrição do layout do aplicativo no
linha de comando usando dois pontos (:) para separar a especificação de programas e argumentos.
Algumas opções são definidas globalmente em todos os programas especificados (por exemplo, --hostfile), enquanto
outros são específicos para um único programa (por exemplo, -np).

Especificando Proprietário Nodes
Os nós de host podem ser identificados no ompi-submeter linha de comando com o -hospedeiro opção ou em um
arquivo de host.

Por exemplo, nos

ompi-submit -H aa, aa, bb ./a.out
inicia dois processos no nó aa e um no bb.

Ou considere o hostfile

% gato meuhostfile
slots aa = 2
bb slots = 2
slots cc = 2

Uma vez que o DVM foi iniciado com orte-dvm, orte-submeter irá ignorar quaisquer argumentos de slots em
o hostfile. Valores fornecidos via hostfile para orte-dvm controlará o comportamento.

ompi-submit -hostfile meuhostfile ./a.out
irá lançar dois processos em cada um dos três nós.

ompi-submit -hostfile meuhostfile -host aa ./a.out
irá lançar dois processos, ambos no nó aa.

ompi-submit -hostfile meuhostfile -host dd ./a.out
não encontrará nenhum host para executar e abortar com um erro. Ou seja, o host especificado dd
não está no hostfile especificado.

Especificando Sessão of Processos
Como acabamos de ver, o número de processos a serem executados pode ser definido usando o hostfile. De outros
mecanismos existem.

O número de processos lançados pode ser especificado como um múltiplo do número de nós ou
soquetes de processador disponíveis. Por exemplo,

ompi-submit -H aa, bb -npersocket 2 ./a.out
lança processos 0-3 no nó aa e processo 4-7 no nó bb, onde aa e bb são ambos
nós de soquete duplo. o -npersocket opção também ativa o -ligar ao soquete opção,
que é discutido em uma seção posterior.

ompi-submit -H aa, bb -npernode 2 ./a.out
inicia os processos 0-1 no nó aa e os processos 2-3 no nó bb.

ompi-submit -H aa, bb -npernode 1 ./a.out
inicia um processo por nó de host.

ompi-submit -H aa, bb -pernode ./a.out
é o mesmo que -npernode 1.

Outra alternativa é especificar o número de processos com o -np opção. Considerar
agora o hostfile

% gato meuhostfile
slots aa = 4
bb slots = 4
slots cc = 4

Agora,

ompi-submit -hostfile meuhostfile -np 6 ./a.out
iniciará os processos 0-3 no nó aa e os processos 4-5 no nó bb. O restante
slots no arquivo host não serão usados, uma vez que o -np opção indicou que apenas 6
processos devem ser iniciados.

Mapeamento Processos para Nodes: utilização Políticas internas
Os exemplos acima ilustram o mapeamento padrão de processos de processo para nós. Esse
o mapeamento também pode ser controlado com vários ompi-submeter opções que descrevem o mapeamento
e envios.

Considere o mesmo hostfile acima, novamente com -np 6:

nó aa nó bb nó cc

ompi-enviar 0 1 2 3 4 5

ompi-submit --map-by nó 0 3 1 4 2 5

ompi-enviar -nolocal 0 1 2 3 4 5

A --map-por nó opção irá balancear a carga dos processos entre os nós disponíveis,
numerar cada processo em rodízio.

A -nolocal opção impede que qualquer processo seja mapeado para o host local (neste
nó de caso aa). Enquanto ompi-submeter normalmente consome poucos recursos do sistema, -nolocal pode ser
útil para o lançamento de trabalhos muito grandes onde ompi-submeter pode realmente precisar usar
quantidades perceptíveis de memória e / ou tempo de processamento.

Assim como -np pode especificar menos processos do que slots, ele também pode sobrecarregar
os slots. Por exemplo, com o mesmo hostfile:

ompi-submit -hostfile meuhostfile -np 14 ./a.out
iniciará os processos 0-3 no nó aa, 4-7 no bb e 8-11 no cc. Em seguida, ele adicionará o
restantes dois processos para qualquer nó que ele escolher.

Também é possível especificar limites para o excesso de assinaturas. Por exemplo, com o mesmo hostfile:

ompi-submit -hostfile meuhostfile -np 14 -nooversubscribe ./a.out
irá produzir um erro, uma vez que -nooversubscribe evita o excesso de assinaturas.

Limites de superinscrição também podem ser especificados no próprio hostfile:
% gato meuhostfile
slots aa = 4 max_slots = 4
bb max_slots = 4
slots cc = 4

A max_slots campo especifica esse limite. Quando isso acontecer, o caça-níqueis valor padrão para o
limite. Agora:

ompi-submit -hostfile meuhostfile -np 14 ./a.out
faz com que os primeiros 12 processos sejam iniciados como antes, mas os dois restantes
os processos serão forçados para o nó cc. Os outros dois nós são protegidos pelo
hostfile contra excesso de inscrições por este trabalho.

Com o --nooversubscribe opção pode ser útil, já que o Open MPI atualmente não obtém
Valores "max_slots" do gerenciador de recursos.

Claro que, -np também pode ser usado com o -H or -hospedeiro opção. Por exemplo,

ompi-submit -H aa, bb -np 8 ./a.out
lança 8 processos. Uma vez que apenas dois hosts são especificados, após os dois primeiros
processos são mapeados, um para aa e um para bb, os processos restantes sobrescrevem
os hosts especificados.

E aqui está um exemplo de MIMD:

ompi-submit -H aa -np 1 hostname: -H bb, cc -np 2 uptime
irá lançar o processo 0 em execução hostname no nó aa e processos 1 e 2, cada um em execução
uptime nos nós bb e cc, respectivamente.

Mapeamento, Classificação, e Encadernação: Oh Minhas!
O Open MPI emprega um procedimento de três fases para atribuir locais e classificações de processos:

mapeamento Atribui um local padrão para cada processo

posição Atribui um valor de classificação MPI_COMM_WORLD a cada processo

obrigatório Limita a execução de cada processo em processadores específicos

A mapeamento etapa é usada para atribuir um local padrão para cada processo com base no mapeador
sendo empregado. O mapeamento por slot, nó e sequencialmente resulta na atribuição do
processos para o nível do nó. Em contraste, o mapeamento por objeto permite que o mapeador atribua
o processo para um objeto real em cada nó.

Nota: a localização atribuída ao processo é independente de onde será direcionado - o
atribuição é usada apenas como entrada para o algoritmo de ligação.

O mapeamento de processos de processo para nós pode ser definido não apenas com políticas gerais
mas também, se necessário, usando mapeamentos arbitrários que não podem ser descritos por um simples
política. Pode-se usar o "mapeador sequencial", que lê o arquivo host linha por linha,
atribuição de processos a nós em qualquer ordem que o hostfile especificar. Use o -mca mapas
seq opção. Por exemplo, usando o mesmo hostfile de antes:

ompi-submit -hostfile meuhostfile -mca rmaps seq ./a.out

irá lançar três processos, um em cada um dos nós aa, bb e cc, respectivamente. O slot
contagens não importam; um processo é lançado por linha em qualquer nó listado no
linha.

Outra maneira de especificar mapeamentos arbitrários é com um arquivo de classificação, que fornece detalhes
controle sobre a ligação do processo também. Rankfiles são discutidos abaixo.

A segunda fase concentra-se no posição do processo no MPI_COMM_WORLD do trabalho.
Open MPI separa isso do procedimento de mapeamento para permitir mais flexibilidade no
colocação relativa de processos MPI. Isso é melhor ilustrado considerando o seguinte
dois casos em que usamos a opção —map-by ppr: 2: socket:

nó aa nó bb

rank-by core 0 1! 2 3 4 5! 6 7

rank-by socket 0 2! 1 3 4 6! 5 7

socket rank-by: span 0 4! 1 5 2 6! 3 7

A classificação por núcleo e por slot fornece o resultado idêntico - uma simples progressão de
MPI_COMM_WORLD classifica em cada nó. A classificação por soquete faz uma classificação round-robin dentro
cada nó até que todos os processos tenham sido atribuídos a uma classificação MCW, e então avança para o
próximo nó. Adicionando o palmo modificador para a diretiva de classificação faz com que o algoritmo de classificação
para tratar toda a alocação como uma única entidade - assim, as classificações MCW são atribuídas
em todos os encaixes antes de voltar ao início.

A obrigatório fase, na verdade, liga cada processo a um determinado conjunto de processadores. Isso pode
melhorar o desempenho se o sistema operacional estiver posicionando os processos de maneira não otimizada. Para
por exemplo, ele pode sobrecarregar alguns soquetes de processador multi-core, deixando outros soquetes
ocioso; isso pode levar os processos a disputar desnecessariamente por recursos comuns. Ou então
pode espalhar os processos muito amplamente; isso pode ser abaixo do ideal se o desempenho do aplicativo
é sensível aos custos de comunicação entre processos. A vinculação também pode manter o funcionamento
sistema de processos de migração excessivamente, independentemente de quão otimamente esses processos
foram colocados para começar.

Os processadores a serem usados ​​para ligação podem ser identificados em termos de agrupamentos topológicos
- por exemplo, a ligação a um l3cache ligará cada processo a todos os processadores dentro do escopo de
um único cache L3 em seu local atribuído. Assim, se um processo é atribuído pelo
mapeador para um determinado soquete, em seguida, um -ligar a l3cache diretiva fará com que o processo seja
vinculado aos processadores que compartilham um único cache L3 dentro desse soquete.

Para ajudar a equilibrar as cargas, a diretiva de ligação usa um método round-robin ao vincular a
níveis inferiores aos usados ​​no mapeador. Por exemplo, considere o caso em que um trabalho é mapeado
ao nível do soquete e, em seguida, vinculado ao núcleo. Cada soquete terá vários núcleos, portanto, se
vários processos são mapeados para um determinado soquete, o algoritmo de ligação atribuirá cada
processo localizado em um soquete para um núcleo exclusivo em uma maneira round-robin.

Alternativamente, os processos mapeados por l2cache e, em seguida, vinculados ao soquete serão simplesmente vinculados
a todos os processadores no soquete onde estão localizados. Desta forma, os usuários podem
exercer controle detalhado sobre a localização e ligação de classificação MCW relativa.

Finalmente, --report-bindings pode ser usado para relatar ligações.

Como exemplo, considere um nó com dois soquetes de processador, cada um compreendendo quatro núcleos. Nós
corrida ompi-submeter com -np 4 --report-bindings e as seguintes opções adicionais:

% ompi-submit ... --map-by core --bind-to core
[...] ... ligando filho [..., 0] a cpus 0001
[...] ... ligando filho [..., 1] a cpus 0002
[...] ... ligando filho [..., 2] a cpus 0004
[...] ... ligando filho [..., 3] a cpus 0008

% ompi-submit ... --mapear por soquete --bind-para soquete
[...] ... ligando filho [..., 0] ao soquete 0 cpus 000f
[...] ... ligando filho [..., 1] ao soquete 1 cpus 00f0
[...] ... ligando filho [..., 2] ao soquete 0 cpus 000f
[...] ... ligando filho [..., 3] ao soquete 1 cpus 00f0

% ompi-submit ... --map-by core: PE = 2 --bind-to core
[...] ... ligando filho [..., 0] a cpus 0003
[...] ... ligando filho [..., 1] a cpus 000c
[...] ... ligando filho [..., 2] a cpus 0030
[...] ... ligando filho [..., 3] a cpus 00c0

% ompi-submit ... --bind-to nenhum

Aqui, --report-bindings mostra a vinculação de cada processo como uma máscara. No primeiro caso,
os processos se ligam a núcleos sucessivos, conforme indicado pelas máscaras 0001, 0002, 0004 e
0008. No segundo caso, os processos se ligam a todos os núcleos em soquetes sucessivos, conforme indicado
pelas máscaras 000f e 00f0. Os processos circulam pelos soquetes do processador em uma rodada
forma robin quantas vezes forem necessárias. No terceiro caso, as máscaras nos mostram que 2
núcleos foram vinculados por processo. No quarto caso, a ligação está desligada e não
ligações são relatadas.

O suporte do Open MPI para vinculação de processos depende do sistema operacional subjacente.
Portanto, certas opções de vinculação de processo podem não estar disponíveis em todos os sistemas.

A vinculação do processo também pode ser definida com parâmetros MCA. Seu uso é menos conveniente do que
que de ompi-submeter opções. Por outro lado, os parâmetros MCA podem ser definidos não apenas no
ompi-submeter linha de comando, mas alternativamente em um arquivo de sistema ou usuário mca-params.conf ou como
variáveis ​​de ambiente, conforme descrito na seção MCA abaixo. Alguns exemplos incluem:

Valor da chave do parâmetro MCA da opção ompi-submit

--map-by núcleo rmaps_base_mapping_policy núcleo
--map-by soquete rmaps_base_mapping_policy soquete
--rank-by núcleo rmaps_base_ranking_policy núcleo
--bind-to core hwloc_base_binding_policy core
- vincular ao soquete hwloc_base_binding_policy soquete
--bind-to none hwloc_base_binding_policy nenhum

Arquivos de classificação
Rankfiles são arquivos de texto que especificam informações detalhadas sobre como processos individuais
devem ser mapeados para nós e para quais processadores eles devem ser associados. Cada linha de um
rankfile especifica a localização de um processo (para trabalhos MPI, o "rank" do processo se refere
para sua classificação em MPI_COMM_WORLD). A forma geral de cada linha no arquivo de classificação é:

classificação = slot =

Por exemplo:

$ cat meurankfile
classificação 0 = aa slot = 1: 0-2
classificação 1 = bb slot = 0: 0,1
classificação 2 = cc slot = 1-2
$ ompi-submit -H aa, bb, cc, dd -rf myrankfile ./a.out

Significa que

O Rank 0 é executado no nó aa, vinculado ao soquete lógico 1, núcleos 0-2.
O Rank 1 é executado no nó bb, vinculado ao soquete lógico 0, núcleos 0 e 1.
O Rank 2 é executado no nó cc, vinculado aos núcleos lógicos 1 e 2.

Os arquivos de classificação podem ser usados ​​alternativamente para especificar físico localizações do processador. Nesse caso,
a sintaxe é um pouco diferente. Os soquetes não são mais reconhecidos, e o número do slot
dado deve ser o número do PU físico, já que a maioria dos sistemas operacionais não atribuem um único físico
identificador para cada núcleo no nó. Assim, um arquivo de classificação físico adequado se parece com algo como
o seguinte:

$ cat meufisicorankfile
classificação 0 = aa slot = 1
classificação 1 = bb slot = 8
classificação 2 = cc slot = 6

Isto significa que

A classificação 0 será executada no nó aa, ligado ao núcleo que contém a PU 1 física
O Rank 1 será executado no nó bb, vinculado ao núcleo que contém o PU 8 físico
O Rank 2 será executado no nó cc, vinculado ao núcleo que contém o PU 6 físico

Rankfiles são tratados como lógico por padrão, e o parâmetro MCA
rmaps_rank_file_physical deve ser definido como 1 para indicar que o rankfile deve ser
considerado como físico.

Os nomes de host listados acima são "absolutos", o que significa que os nomes de host resolvíveis são
Especificadas. No entanto, os nomes de host também podem ser especificados como "relativos", o que significa que eles são
especificado em relação a uma lista especificada externamente de nomes de host (por exemplo, por ompi-submit's
--host argumento, um hostfile ou um agendador de trabalho).

A especificação "relativa" tem a forma "+ n ", onde X é um número inteiro especificando o
Xº nome de host no conjunto de todos os nomes de host disponíveis, indexados a partir de 0. Por exemplo:

$ cat meurankfile
rank 0=+n0 slot=1:0-2
classificação 1 = + n1 slot = 0: 0,1
classificação 2 = + n2 slot = 1-2
$ ompi-submit -H aa, bb, cc, dd -rf myrankfile ./a.out

A partir do Open MPI v1.7, todos os locais de slot de soquete / núcleo são especificados como lógico
índices (a série Open MPI v1.6 usada físico índices). Você pode usar ferramentas como
"Lstopo" do HWLOC para encontrar os índices lógicos de soquete e núcleos.

Aplicação Contexto or Executável Programa?
Para distinguir as duas formas diferentes, ompi-submeter procura na linha de comando por --aplicativo
opção. Se for especificado, o arquivo nomeado na linha de comando será considerado um
contexto da aplicação. Se não for especificado, o arquivo será considerado um executável
.

Localizando Arquivos
Se nenhum caminho relativo ou absoluto for especificado para um arquivo, o Open MPI procurará primeiro
arquivos pesquisando os diretórios especificados pelo --caminho opção. Se não há --caminho
conjunto de opções ou se o arquivo não for encontrado no --caminho local, então o Open MPI irá pesquisar
a variável de ambiente PATH do usuário conforme definido no (s) nó (s) de origem.

Se um diretório relativo for especificado, ele deve ser relativo ao diretório de trabalho inicial
determinado pelo starter específico usado. Por exemplo, ao usar os iniciadores rsh ou ssh,
o diretório inicial é $ HOME por padrão. Outros iniciantes podem definir o diretório inicial para
o diretório de trabalho atual a partir da invocação de ompi-submeter.

Atual Trabalho Diretório
A -wdir opção ompi-submit (e seu sinônimo, -wd) permite que o usuário mude para um
diretório arbitrário antes de o programa ser invocado. Também pode ser usado no aplicativo
arquivos de contexto para especificar diretórios de trabalho em nós específicos e / ou para
aplicações.

Se o -wdir opção aparece em um arquivo de contexto e na linha de comando, o contexto
o diretório de arquivos substituirá o valor da linha de comando.

Se o -wdir opção for especificada, Open MPI tentará mudar para o especificado
diretório em todos os nós remotos. Se isso falhar, ompi-submeter vai abortar.

Se o -wdir opção não especificado, Open MPI enviará o nome do diretório para onde ompi-
enviar foi chamado para cada um dos nós remotos. Os nós remotos tentarão mudar para
esse diretório. Se eles não puderem (por exemplo, se o diretório não existir nesse nó),
então o Open MPI usará o diretório padrão determinado pelo iniciador.

Todas as mudanças de diretório ocorrem antes que o programa do usuário seja invocado; não espera até
MPI_INIT é chamado.

Standard I / O
Open MPI direciona a entrada padrão do UNIX para / dev / null em todos os processos, exceto o
Processo de classificação 0 MPI_COMM_WORLD. O processo de classificação 0 MPI_COMM_WORLD herda a entrada padrão
da ompi-submeter. Nota: O nó que invocou ompi-submeter não precisa ser o mesmo que o
nó onde reside o processo de classificação 0 MPI_COMM_WORLD. Open MPI lida com o redirecionamento de
ompi-submeterentrada padrão do para o processo de classificação 0.

Open MPI direciona a saída padrão UNIX e erro de nós remotos para o nó que invocou
ompi-submeter e imprime na saída / erro padrão de ompi-submeter. Processos locais
herdar a saída / erro padrão de ompi-submeter e transferir diretamente para ele.

Assim, é possível redirecionar I / O padrão para aplicativos Open MPI usando o
procedimento típico de redirecionamento de shell em ompi-submeter.

% ompi-submit -np 2 my_app <my_input> my_output

Observe que neste exemplo só o processo de classificação 0 MPI_COMM_WORLD receberá o fluxo
da minha_entrada em stdin. O stdin em todos os outros nós será vinculado a / dev / null.
No entanto, o stdout de todos os nós será coletado no minha_saída arquivo.

Signal Propagação
Quando o orte-submit recebe um SIGTERM e SIGINT, ele tentará eliminar todo o trabalho por
enviando todos os processos da tarefa um SIGTERM, aguardando alguns segundos, então
enviando todos os processos da tarefa para um SIGKILL.

Os sinais SIGUSR1 e SIGUSR2 recebidos por orte-submit são propagados para todos os processos no
trabalho.

Pode-se ativar o encaminhamento de SIGSTOP e SIGCONT para o programa executado por ompi-submit
definindo o parâmetro MCA orte_forward_job_control para 1. Um sinal SIGTSTOP para ompi-
enviar fará com que um sinal SIGSTOP seja enviado a todos os programas iniciados por ompi-
enviar e da mesma forma um sinal SIGCONT para ompi-submit fará com que um SIGCONT seja enviado.

Outros sinais não são propagados atualmente por orte-submit.

Extração Terminação / Signal Manipulação
Durante a execução de um aplicativo MPI, se algum processo for interrompido de forma anormal (ou saindo
antes de invocar MPI_FINALIZEou morrendo como resultado de um sinal), ompi-submeter irá imprimir
enviar uma mensagem de erro e eliminar o restante do aplicativo MPI.

Os manipuladores de sinais do usuário provavelmente devem evitar tentar limpar o estado MPI (Open MPI é
atualmente não é seguro para sinais assíncronos; Vejo MPI_Init_thread(3) para detalhes sobre
MPI_THREAD_MULTIPLE e segurança de rosca). Por exemplo, se ocorrer uma falha de segmentação em
MPI_SEND (talvez porque um buffer inválido foi passado) e um manipulador de sinais do usuário é
invocado, se este manipulador de usuário tentar invocar MPI_FINALIZE, Coisas ruins podem acontecer
visto que Open MPI já estava "em" MPI quando o erro ocorreu. Desde a ompi-submeter precisarão
note que o processo morreu devido a um sinal, provavelmente não é necessário (e mais seguro)
para que o usuário limpe apenas o estado não MPI.

Extração Meio Ambiente
Os processos no aplicativo MPI herdam seu ambiente do daemon Open RTE após
o nó em que estão sendo executados. O ambiente é normalmente herdado do
shell do usuário. Em nós remotos, o ambiente exato é determinado pelo módulo MCA de inicialização
usado. o rsh módulo de lançamento, por exemplo, usa qualquer rsh/ssh para lançar o Open RTE
daemon em nós remotos, e normalmente executa um ou mais dos arquivos de configuração de shell do usuário
antes de lançar o daemon Open RTE. Ao executar aplicativos dinamicamente vinculados que
requer o LD_LIBRARY_PATH variável de ambiente a ser definida, deve-se tomar cuidado para garantir
se ele está configurado corretamente ao inicializar o Open MPI.

Consulte a seção "Execução remota" para obter mais detalhes.

Remote Execução
Open MPI requer que o PATH variável de ambiente deve ser definida para encontrar executáveis ​​remotos
nós (isso normalmente só é necessário em rsh- ou sshambientes baseados em -
ambientes em lote / agendados normalmente copiam o ambiente atual para a execução de
trabalhos remotos, portanto, se o ambiente atual tiver PATH e / ou LD_LIBRARY_PATH definido corretamente,
os nós remotos também o terão configurado corretamente). Se Open MPI foi compilado com compartilhado
suporte de biblioteca, também pode ser necessário ter o LD_LIBRARY_PATH variável de ambiente
definido em nós remotos também (especialmente para encontrar as bibliotecas compartilhadas necessárias para executar o usuário
Aplicativos MPI).

No entanto, nem sempre é desejável ou possível editar arquivos de inicialização do shell para definir PATH
e / ou LD_LIBRARY_PATH. O --prefixo opção é fornecida para algumas configurações simples
onde isso não é possível.

A --prefixo opção leva um único argumento: o diretório base no nó remoto onde
Open MPI está instalado. Open MPI usará este diretório para definir o controle remoto PATH e
LD_LIBRARY_PATH antes de executar qualquer Open MPI ou aplicativo de usuário. Isso permite correr
Abra trabalhos MPI sem ter pré-configurado o PATH e LD_LIBRARY_PATH no remoto
nós.

Open MPI adiciona o nome de base do "bindir" do nó atual (o diretório onde Open MPI's
executáveis ​​são instalados) para o prefixo e usa isso para definir o PATH no nó remoto.
Da mesma forma, Open MPI adiciona o nome de base do nó atual "libdir" (o diretório onde
Bibliotecas Open MPI são instaladas) para o prefixo e usa isso para definir o LD_LIBRARY_PATH
no nó remoto. Por exemplo:

Bindir local: / local / node / directory / bin

Libdir local: / local / node / diretório / lib64

Se a seguinte linha de comando for usada:

% ompi-submit --prefix / remote / node / directory

Open MPI irá adicionar "/ remote / node / directory / bin" ao PATH e
"/ remote / node / directory / lib64" para D_LIBRARY_PATH no nó remoto antes de tentar
para executar qualquer coisa.

A --prefixo opção não é suficiente se os caminhos de instalação no nó remoto são
diferente do nó local (por exemplo, se "/ lib"é usado no nó local, mas"/ lib64"é
usado no nó remoto), ou se os caminhos de instalação forem diferentes de um
subdiretório sob um prefixo comum.

Observe que executar ompi-submeter por meio de um nome de caminho absoluto é equivalente a especificar
--prefixo sem o último subdiretório no caminho absoluto para ompi-submeter. Para
exemplo:

% / usr / local / bin / ompi-submit ...

é equivalente a

% ompi-submit --prefixo / usr / local

Exportado Meio Ambiente Variáveis
Todas as variáveis ​​de ambiente nomeadas no formato OMPI_ * serão exportadas automaticamente
para novos processos nos nós locais e remotos. Os parâmetros ambientais também podem ser
definir / encaminhar para os novos processos usando o parâmetro MCA mca_base_env_list. O -x
opção para ompi-submeter foi descontinuado, mas a sintaxe do parâmetro MCA segue que
exemplo anterior. Embora a sintaxe do -x opção e parâmetro MCA permite a definição de
novas variáveis, observe que o analisador para essas opções não é muito sofisticado
- ele nem mesmo entende os valores citados. Os usuários são aconselhados a definir variáveis ​​no
ambiente e usar a opção de exportá-los; não para defini-los.

Configuração MCA parâmetros
A -mca switch permite a passagem de parâmetros para vários MCA (componente modular
Módulos de arquitetura). Os módulos MCA têm impacto direto nos programas MPI porque permitem
parâmetros ajustáveis ​​a serem definidos em tempo de execução (como qual driver de dispositivo de comunicação BTL para
usar, quais parâmetros passar para esse BTL, etc.).

A -mca switch leva dois argumentos: e . O argumento geral
especifica qual módulo MCA receberá o valor. Por exemplo, o "btl" é usado
para selecionar qual BTL será usado para transportar mensagens MPI. o argumento é o
valor que é passado. Por exemplo:

ompi-submit -mca btl tcp, self -np 1 foo
Diz ao Open MPI para usar os BTLs "tcp" e "self" e para executar uma única cópia de "foo" e
nó alocado.

ompi-submit -mca btl self -np 1 foo
Diz ao Open MPI para usar o "self" BTL e para executar uma única cópia de "foo" e alocado
nó.

A -mca switch pode ser usado várias vezes para especificar diferentes e / ou
argumentos. Se o mesmo é especificado mais de uma vez, o s são concatenados
com uma vírgula (",") separando-os.

Observe que o -mca switch é simplesmente um atalho para definir variáveis ​​de ambiente. o
o mesmo efeito pode ser obtido definindo as variáveis ​​de ambiente correspondentes antes
que ocorre ompi-submeter. A forma das variáveis ​​de ambiente que o Open MPI define é:

OMPI_MCA_ =

Assim, o -mca switch substitui quaisquer variáveis ​​de ambiente definidas anteriormente. o -mca
as configurações substituem de forma semelhante os parâmetros MCA definidos em $ OPAL_PREFIX / etc / openmpi-mca-
params.conf ou arquivo $ HOME / .openmpi / mca-params.conf.

Desconhecido argumentos ainda são definidos como variáveis ​​de ambiente - eles não são verificados (por
ompi-submeter) para correção. Ilegal ou incorreto argumentos podem ou não ser
relatado - depende do módulo MCA específico.

Para encontrar os tipos de componentes disponíveis na arquitetura MCA, ou para encontrar os disponíveis
parâmetros para um componente específico, use o ompi_info comando. Veja o ompi_info(1) homem
página para obter informações detalhadas sobre o comando.

Corrida as raiz
A equipe Open MPI desaconselha fortemente a execução ompi-submeter como o usuário root. MPI
os aplicativos devem ser executados como usuários regulares (não root).

Refletindo esse conselho, ompi-submit se recusará a executar como root por padrão. Para substituir
este padrão, você pode adicionar o --allow-executar como root opção para ompi-submeter linha de comando.

saída estado
Não existe uma definição padrão para o que ompi-submeter deve retornar como um status de saída.
Após uma discussão considerável, definimos o seguinte método para atribuir o ompi-
enviar status de saída (observação: na descrição a seguir, o trabalho "principal" é o inicial
aplicativo iniciado por ompi-submit - todos os trabalhos gerados por esse trabalho são designados
empregos "secundários"):

· Se todos os processos no trabalho principal normalmente terminam com o status de saída 0, retornamos 0

· Se um ou mais processos no trabalho principal normalmente terminam com saída diferente de zero
status, retornamos o status de saída do processo com a classificação MPI_COMM_WORLD mais baixa para
tem um status diferente de zero

· Se todos os processos no trabalho principal normalmente terminam com status de saída 0, e um ou
mais processos em um trabalho secundário normalmente terminam com status de saída diferente de zero, nós (a)
retorna o status de saída do processo com a classificação MPI_COMM_WORLD mais baixa na mais baixa
jobid para ter um status diferente de zero, e (b) emitir uma mensagem resumindo o status de saída de
os empregos primários e todos os secundários.

· Se a opção da linha cmd --report-child-jobs -efinida separadamente, retornaremos -apenas- o
status de saída do trabalho principal. Qualquer status de saída diferente de zero em empregos secundários será
relatado apenas em uma declaração impressa resumida.

Por padrão, o OMPI registra e observa que os processos MPI foram encerrados com finalização diferente de zero
status. Isso geralmente não é considerado uma "rescisão anormal" - ou seja, OMPI não
abortar um trabalho MPI se um ou mais processos retornarem um status diferente de zero. Em vez disso, o padrão
comportamento simplesmente relata o número de processos que terminam com status diferente de zero após
conclusão do trabalho.

No entanto, em alguns casos, pode ser desejável interromper o trabalho quando qualquer processo
termina com status diferente de zero. Por exemplo, um trabalho não MPI pode detectar um resultado ruim de
um cálculo e deseja abortar, mas não deseja gerar um arquivo principal. Ou um trabalho MPI
pode continuar após uma chamada para MPI_Finalize, mas indica que todos os processos devem abortar
devido a algum resultado pós-MPI.

Não é esperado que esta situação ocorra com freqüência. No entanto, no interesse
de servir a uma comunidade mais ampla, OMPI agora tem um meio para permitir que os usuários direcionem esse
os trabalhos serão abortados quando qualquer processo sair com status diferente de zero. Configurando o parâmetro MCA
"orte_abort_on_non_zero_status" para 1 fará com que OMPI aborte todos os processos uma vez que qualquer
processo
sai com status diferente de zero.

Encerramentos causados ​​desta maneira serão relatados no console como um "anormal
rescisão ", com o primeiro processo a sair identificado juntamente com seu status de saída.

EXEMPLOS

Certifique-se também de ver os exemplos nas seções acima.

ompi-submit -np 4 -mca btl ib, tcp, self prog1
Execute 4 cópias de prog1 usando o "ib", "tcp" e "self" BTL para o transporte de MPI
mensagens.

ompi-submit -np 4 -mca btl tcp, sm, self
--mca btl_tcp_if_include eth0 prog1
Execute 4 cópias de prog1 usando os BTLs "tcp", "sm" e "self" para o transporte de MPI
mensagens, com o TCP usando apenas a interface eth0 para se comunicar. Observe que outros BTLs
têm parâmetros MCA if_include semelhantes.

RETORNO VALOR

ompi-submeter retorna 0 se todos os processos iniciados por ompi-submeter saia depois de ligar
MPI_FINALIZE. Um valor diferente de zero é retornado se um erro interno ocorreu no ompi-submit,
ou um ou mais processos saíram antes de chamar MPI_FINALIZE. Se um erro interno
ocorreu no ompi-submit, o código de erro correspondente é retornado. No caso de aquele
ou mais processos saem antes de chamar MPI_FINALIZE, o valor de retorno de MPI_COMM_WORLD
classificação do processo que ompi-submeter primeiros avisos morreram antes de chamar MPI_FINALIZE
Ser devolvido. Observe que, em geral, este será o primeiro processo que morreu, mas não é
garantido que será assim.

Use orte-submit online usando os serviços onworks.net