sbatch - Online na nuvem

PROGRAMA:

NOME

sbatch - Envie um script de lote para Slurm.

SINOPSE

lote [opções] escrita [args...]

DESCRIÇÃO

sbatch envia um script de lote para Slurm. O script de lote pode ser fornecido para sbatch por meio de um
nome do arquivo na linha de comando, ou se nenhum nome de arquivo for especificado, sbatch irá ler em um
script da entrada padrão. O script em lote pode conter opções precedidas de "#SBATCH"
antes de qualquer comando executável no script.

sbatch sai imediatamente após o script ser transferido com sucesso para o Slurm
controlador e atribuído um ID de trabalho Slurm. O script em lote não é necessariamente concedido
recursos imediatamente, ele pode ficar na fila de trabalhos pendentes por algum tempo antes de seu
os recursos necessários tornam-se disponíveis.

Por padrão, tanto a saída padrão quanto o erro padrão são direcionados para um arquivo com o nome
"slurm-% j.out", onde "% j" é substituído pelo número de alocação do trabalho. O arquivo irá
ser gerado no primeiro nó da alocação de trabalho. Além do próprio script em lote,
Slurm não move os arquivos do usuário.

Quando a alocação de trabalho é finalmente concedida para o script em lote, Slurm executa uma única cópia
do script em lote no primeiro nó no conjunto de nós alocados.

O seguinte documento descreve a influência de várias opções na alocação de
cpus para trabalhos e tarefas.
http://slurm.schedmd.com/cpu_management.html

OPÇÕES

-a, --variedade=<índices>
Envie uma matriz de trabalho, vários trabalhos a serem executados com parâmetros idênticos. o
índices especificação identifica quais valores de índice de array devem ser usados. Múltiplo
os valores podem ser especificados usando uma lista separada por vírgulas e / ou um intervalo de valores com
um separador "-". Por exemplo, "--array = 0-15" ou "--array = 0,6,16-32". Um passo
a função também pode ser especificada com um sufixo contendo dois pontos e um número. Para
exemplo, "--array = 0-15: 4" é equivalente a "--array = 0,4,8,12". Um número máximo de
a execução simultânea de tarefas da matriz de trabalho pode ser especificada usando um "%"
separador. Por exemplo, "--array = 0-15% 4" limitará o número de simultaneamente
executando tarefas a partir desta matriz de trabalho para 4. O valor de índice mínimo é 0. o máximo
o valor é um a menos que o parâmetro de configuração MaxArraySize.

-A, --conta=<conta>
Cobrar recursos usados ​​por este trabalho para a conta especificada. o conta é um
string arbitrária. O nome da conta pode ser alterado após o envio do trabalho usando o
controlar comando.

--acctg-freq
Defina a contabilidade do trabalho e os intervalos de amostragem do perfil. Isso pode ser usado para
substituir o JobAcctGatherFrequency parâmetro no arquivo de configuração de Slurm,
slurm.conf. O formato suportado é o seguinte:

--acctg-freq ==
onde = especifica o intervalo de amostragem da tarefa para
o plugin jobacct_gather ou um intervalo de amostragem para um tipo de perfil
pelo plugin acct_gather_profile. Vários, separados por vírgulas
= intervalos podem ser especificados. Tipos de dados suportados
são como segue:

tarefa =
onde é o intervalo de amostragem da tarefa em segundos para
os plug-ins jobacct_gather e para o perfil de tarefa pelo
plugin acct_gather_profile. NOTA: Esta frequência é usada para
monitorar o uso de memória. Se os limites de memória forem impostos, o mais alto
frequência que um usuário pode solicitar é o que está configurado no
arquivo slurm.conf. Eles também não podem desligá-lo (= 0).

energia =
onde é o intervalo de amostragem em segundos para energia
criação de perfil usando o plugin acct_gather_energy

rede =
onde é o intervalo de amostragem em segundos para
Perfil do infiniband usando o plugin acct_gather_infiniband.

sistema de arquivos =
onde é o intervalo de amostragem em segundos para
perfil do sistema de arquivos usando o plugin acct_gather_filesystem.

O valor padrão para o intervalo de amostragem da tarefa é 30 segundos.
O valor padrão para todos os outros intervalos é 0. Um intervalo de 0 desativa a amostragem
do tipo especificado. Se o intervalo de amostragem da tarefa for 0, informações contábeis
é coletado apenas no término do trabalho (reduzindo a interferência do Slurm no trabalho).
Valores menores (diferentes de zero) têm um impacto maior sobre o desempenho do trabalho, mas um valor
de 30 segundos provavelmente não será perceptível para aplicativos com menos de
10,000 tarefas.

-B --extra-node-info=<soquetes[:núcleos[:tópicos]]>
Solicite uma alocação específica de recursos com detalhes quanto ao número e tipo
de recursos computacionais dentro de um cluster: número de sockets (ou físico
processadores) por nó, núcleos por soquete e threads por núcleo. A quantidade total de
os recursos solicitados são o produto de todos os termos. Cada valor especificado
é considerado um mínimo. Um asterisco (*) pode ser usado como um marcador indicando
que todos os recursos disponíveis desse tipo devem ser utilizados. Tal como acontece com os nós, o
níveis individuais também podem ser especificados em opções separadas, se desejado:
--soquetes-por-nó=<soquetes>
--núcleos por soquete=<núcleos>
--threads por núcleo=<tópicos>
Se SelectType for configurado para selecionar / cons_res, ele deve ter um parâmetro de
CR_Core, CR_Core_Memory, CR_Socket ou CR_Socket_Memory para que esta opção seja
honrado. Esta opção não é suportada em sistemas BlueGene (select / plugin bluegene
está configurado). Se não for especificado, o scontrol show job exibirá
'ReqS: C: T = *: *: *'.

--bb=<especulação>
Especificação do buffer de burst. A forma da especificação depende do sistema.

--começar=<tempo>
Envie o script em lote para o controlador Slurm imediatamente, como normal, mas diga
o controlador para adiar a alocação do trabalho até a hora especificada.

O tempo pode ser da forma HH: MM: SS para executar um trabalho em uma hora específica do dia (segundos
são opcionais). (Se essa hora já tiver passado, o dia seguinte será assumido.) Você pode
também especificar meia-noite, meio-dia, Outro (3h) ou teatime (4h) e você pode ter um
hora do dia sufixada com AM or PM para correr de manhã ou à noite. Vocês
também pode dizer em que dia o trabalho será executado, especificando uma data do formulário MMDDAA
or MM / DD / AA AAAA-MM-DD. Combine data e hora usando o seguinte formato
AAAA-MM-DD [THH: MM [: SS]]. Você também pode dar tempos como agora + contar unidades de tempo, Onde
as unidades de tempo podem ser segundo (Padrão) minutos, horas, diasou semanas e você pode
diga a Slurm para executar o trabalho hoje com a palavra-chave hoje e para executar o trabalho amanhã
com a palavra-chave amanhã. O valor pode ser alterado após o envio do trabalho usando o
controlar comando. Por exemplo:
--begin = 16: 00
--begin = agora + 1 hora
--begin = now + 60 (segundos por padrão)
--begin=2010-01-20T12:34:00

Notas sobre especificações de data / hora:
- Embora o campo 'segundos' da especificação de tempo HH: MM: SS seja permitido por
o código, observe que o tempo de votação do agendador Slurm não é preciso o suficiente para
garantir o envio do trabalho no exato segundo. O trabalho será elegível para
iniciar na próxima votação após o tempo especificado. O intervalo exato da sondagem
depende do agendador Slurm (por exemplo, 60 segundos com o sched / embutido padrão).
- Se nenhuma hora (HH: MM: SS) for especificada, o padrão é (00:00:00).
- Se uma data for especificada sem um ano (por exemplo, MM / DD), o ano atual é
assumido, a menos que a combinação de MM / DD e HH: MM: SS já tenha passado para isso
ano, caso em que o próximo ano é usado.

- checkpoint=<tempo>
Especifica o intervalo entre a criação de pontos de verificação da etapa do trabalho. Por padrão,
a etapa do trabalho não terá pontos de verificação criados. Os formatos de hora aceitáveis ​​incluem
"minutos", "minutos: segundos", "horas: minutos: segundos", "dias-horas",
"dias-horas: minutos" e "dias-horas: minutos: segundos".

--ponto de verificação-dir=<anuário>
Especifica o diretório no qual o trabalho ou ponto de verificação da etapa do trabalho deve ser
escrito (usado apenas pelos plug-ins checkpoint / blcrm e checkpoint / xlch). o
o valor padrão é o diretório de trabalho atual. Os arquivos de ponto de verificação serão do
Formato " .ckpt "para empregos e" . .ckpt "para as etapas do trabalho.

--Comente=<corda>
Um comentário arbitrário colocado entre aspas duplas, se usar espaços ou algum objeto especial
caracteres.

-C, --limitação=<Lista>
Os nós podem ter características atribuído a eles pelo administrador Slurm. Os usuários podem
especifique qual destes características são exigidos por seu trabalho usando a restrição
opção. Apenas nós com recursos que correspondam às restrições de trabalho serão usados ​​para
satisfazer o pedido. Múltiplas restrições podem ser especificadas com AND, OR, combinando
OU, contagens de recursos, etc. As opções de restrição suportadas incluem:

Individual Nome
Apenas nós que possuem o recurso especificado serão usados. Por exemplo,
--constraint = "intel"

Node Contar
Uma solicitação pode especificar o número de nós necessários com algum recurso por
anexando um asterisco e contar após o nome do recurso. Por exemplo
"--nodes = 16 --constraint = gráficos * 4 ... " indica que o trabalho requer 16
nós e que pelo menos quatro desses nós devem ter o recurso
"gráficos."

E Se apenas nós com todos os recursos especificados forem usados. O e comercial é
usado para um operador AND. Por exemplo, --constraint = "intel & gpu"

OR Se apenas nós com pelo menos um dos recursos especificados forem usados. o
a barra vertical é usada para um operador OR. Por exemplo,
--constraint = "intel | amd"

Correspondente OR
Se apenas um de um conjunto de opções possíveis deve ser usado para todos os alocados
nós, então use o operador OR e coloque as opções dentro de um quadrado
colchetes. Por exemplo: "--constraint = [rack1 | rack2 | rack3 | rack4] " pode ser
usado para especificar que todos os nós devem ser alocados em um único rack do
cluster, mas qualquer um desses quatro racks pode ser usado.

Múltiplo Contagens
Contagens específicas de vários recursos podem ser especificadas usando o E
operador e colocando as opções entre colchetes. Por exemplo:
"--constraint = [rack1 * 2 & rack2 * 4] " pode ser usado para especificar que dois nós
deve ser alocado a partir de nós com o recurso de "rack1" e quatro nós devem
ser alocado a partir de nós com o recurso "rack2".

--contíguo
Se definido, os nós alocados devem formar um conjunto contíguo. Não honrado com o
topologia / árvore or topologia / 3d_torus plug-ins, os quais podem modificar o nó
encomenda.

--núcleos por soquete=<núcleos>
Restrinja a seleção de nós para nós com pelo menos o número especificado de núcleos por
socket. Veja informações adicionais em -B opção acima quando plugin de tarefa / afinidade
está ativado.

--cpu-freq =<p1[-p2[:p3]]>

Solicite que as etapas do trabalho iniciadas por comandos srun dentro deste script sbatch sejam executadas
em alguma frequência solicitada, se possível, nas CPUs selecionadas para a etapa do
nó (s) de computação.

p1 pode ser [#### | baixo | médio | alto | highm1] que irá definir a frequência
scaling_speed para o valor correspondente, e defina a frequência scaling_governor para
Espaço do usuário. Veja abaixo a definição dos valores.

p1 pode ser [Conservador | OnDemand | Desempenho | PowerSave] que irá definir o
scaling_governor para o valor correspondente. O governador tem que estar no conjunto de listas
pela opção slurm.conf CpuFreqGovernors.

Quando p2 estiver presente, p1 será a frequência de escala mínima e p2 será o
frequência máxima de escalonamento.

p2 pode ser [#### | médio | alto | highm1] p2 deve ser maior que p1.

p3 pode ser [Conservador | OnDemand | Desempenho | PowerSave | UserSpace] que
irá definir o governador para o valor correspondente.

If p3 for UserSpace, a frequência scaling_speed será definida por uma potência ou energia
estratégia de agendamento ciente para um valor entre p1 e p2 que permite que o trabalho seja executado dentro
a meta de energia do site. O trabalho pode ser atrasado se p1 for maior do que uma frequência que
permite que o trabalho seja executado dentro do objetivo.

Se a frequência atual for <min, será definida como min. Da mesma forma, se o atual
a frequência é> máx., será definida como máx.

Os valores aceitáveis ​​no momento incluem:

#### frequência em quilohertz

Baixo a menor frequência disponível

Alta a maior frequência disponível

AltoM1 (alto menos um) selecionará a próxima frequência mais alta disponível

Médio tenta definir uma frequência no meio do intervalo disponível

Conservador tenta usar o governador Conservative CPU

Sob demanda tenta usar o governador de CPU OnDemand (o valor padrão)

Desempenho tenta usar o governador Performance CPU

Economia de energia tenta usar o governador de CPU PowerSave

Espaço do usuário tentativas de usar o regulador de CPU do UserSpace

A seguinte variável de ambiente informativa é definida no trabalho
passo quando --cpu-freq opção é solicitada.
SLURM_CPU_FREQ_REQ

Esta variável de ambiente também pode ser usada para fornecer o valor para a CPU
pedido de frequência se for definido quando o comando 'srun' é emitido. o --cpu-freq
na linha de comando substituirá o valor da variável de ambiente. O formulário no
a variável de ambiente é igual à linha de comando. Veja o MEIO AMBIENTE
VARIÁVEIS seção para uma descrição da variável SLURM_CPU_FREQ_REQ.

NOTA: Este parâmetro é tratado como uma solicitação, não um requisito. Se a etapa do trabalho for
o nó não suporta a configuração da frequência da CPU ou o valor solicitado está fora
os limites das frequências legais, um erro é registrado, mas a etapa do trabalho é
permissão para continuar.

NOTA: Definir a frequência apenas para as CPUs da etapa do trabalho implica que o
as tarefas são confinadas a essas CPUs. Se o confinamento da tarefa (ou seja,
TaskPlugin = task / affinity ou TaskPlugin = task / cgroup com o "ConstrainCores"
opção) não está configurada, este parâmetro é ignorado.

NOTA: Quando a etapa for concluída, a frequência e governador de cada CPU selecionada é
redefinir para o configurado CPUFreqDef valor com um valor padrão da CPU OnDemand
governador.

NOTA: Ao enviar trabalhos com o --cpu-freq opção com linuxproc como o
ProctrackType pode fazer com que os trabalhos sejam executados muito rapidamente antes que a contabilidade possa pesquisar
para obter informações sobre o trabalho. Como resultado, nem todas as informações contábeis estarão presentes.

-c, --cpus-por-tarefa=<ncpus>
Avise o controlador Slurm que as etapas de trabalho subsequentes exigirão ncpus número de
processadores por tarefa. Sem esta opção, o controlador apenas tentará alocar
um processador por tarefa.

Por exemplo, considere um aplicativo que tem 4 tarefas, cada uma exigindo 3
processadores. Se nosso cluster é composto de nós de quatro processadores e simplesmente pedimos
para 12 processadores, o controlador pode nos dar apenas 3 nós. No entanto, usando
as opções --cpus-per-task = 3, o controlador sabe que cada tarefa requer 3
processadores no mesmo nó, e o controlador concederá uma alocação de 4
nós, um para cada uma das 4 tarefas.

-d, --dependência=<lista_dependência>
Adie o início deste trabalho até que as dependências especificadas sejam satisfeitas
concluído.lista_dependência> é da forma
<tipo: job_id [: job_id] [, tipo: job_id [: job_id]]> ou
<type: job_id [: job_id] [? type: job_id [: job_id]]>. Todas as dependências devem ser satisfeitas
se o separador "," for usado. Qualquer dependência pode ser satisfeita se o "?" separador
é usado. Muitos trabalhos podem compartilhar a mesma dependência e esses trabalhos podem até pertencer a
usuários diferentes. O valor pode ser alterado após o envio do trabalho usando o scontrol
comando. Uma vez que uma dependência de trabalho falha devido ao estado de término de um anterior
trabalho, o trabalho dependente nunca será executado, mesmo se o trabalho anterior for recolocado na fila e
tem um estado de terminação diferente em uma execução subsequente.

depois: job_id [: jobid ...]
Este trabalho pode começar a ser executado depois que os trabalhos especificados iniciarem a execução.

afterany: job_id [: jobid ...]
Este trabalho pode começar a ser executado após o término dos trabalhos especificados.

afternotok: job_id [: jobid ...]
Este trabalho pode começar a ser executado após o término dos trabalhos especificados em
algum estado de falha (código de saída diferente de zero, falha de nó, tempo limite esgotado, etc).

afterok: job_id [: jobid ...]
Este trabalho pode começar a ser executado após os trabalhos especificados terem sido bem-sucedidos
executado (executado até a conclusão com um código de saída zero).

expandir: job_id
Os recursos alocados para este trabalho devem ser usados ​​para expandir o trabalho especificado.
O trabalho de expansão deve compartilhar o mesmo QOS (Quality of Service) e
partição. O agendamento de grupos de recursos na partição também não é
suportado.

coisa única
Este trabalho pode começar a ser executado após qualquer trabalho lançado anteriormente, compartilhando o
mesmo nome de trabalho e usuário foram encerrados.

-D, --workdir=<anuário>
Defina o diretório de trabalho do script em lote para anuário antes de ser executado.
O caminho pode ser especificado como caminho completo ou caminho relativo para o diretório onde o
comando é executado.

-e, --erro=<nome do arquivo de cinto de segurança>
Instrua Slurm a conectar o erro padrão do script em lote diretamente ao arquivo
nome especificado no "nome do arquivo de cinto de segurança". Por padrão, a saída padrão e
o erro padrão é direcionado para o mesmo arquivo. Para matrizes de trabalho, o arquivo padrão
o nome é "slurm-% A_% a.out", "% A" é substituído pelo ID do trabalho e "% a" pelo array
índice. Para outros trabalhos, o nome do arquivo padrão é "slurm-% j.out", onde o "% j" é
substituído pelo ID do trabalho. Veja o --entrada opção para opções de especificação de nome de arquivo.

--exclusive [= usuário]
A alocação de trabalho não pode compartilhar nós com outros trabalhos em execução (ou apenas outros usuários
com a opção "= usuário"). O comportamento padrão compartilhado / exclusivo depende do sistema
configuração e a partição Partilhado opção tem precedência sobre o trabalho
opção.

--exportar=<meio Ambiente variáveis | TODAS | NENHUM>
Identifique quais variáveis ​​de ambiente são propagadas para a tarefa em lote. Múltiplo
os nomes das variáveis ​​de ambiente devem ser separados por vírgulas. Nomes de variáveis ​​de ambiente
pode ser especificado para propagar o valor atual dessas variáveis ​​(por exemplo
"--export = EDITOR") ou valores específicos para as variáveis ​​podem ser exportados (por exemplo,
"--export = EDITOR = / bin / vi") além das variáveis ​​de ambiente que
caso contrário, ser definido. Esta opção é particularmente importante para trabalhos que são enviados
em um cluster e execute em um cluster diferente (por exemplo, com caminhos diferentes). Por
padrão, todas as variáveis ​​de ambiente são propagadas. Se o argumento for NENHUM or
nomes de variáveis ​​de ambiente específicos, então o --get-user-env opção implicitamente
ser definido para carregar outras variáveis ​​de ambiente com base na configuração do usuário em
o cluster que executa o trabalho.

--exportar arquivo=<nome do arquivo | fd>
Se um número entre 3 e OPEN_MAX for especificado como o argumento para esta opção, um
descritor de arquivo legível será assumido (STDIN e STDOUT não são suportados como
argumentos válidos). Caso contrário, um nome de arquivo é assumido. Exportar variáveis ​​de ambiente
definido emnome do arquivo> ou ler defd> para o ambiente de execução do trabalho. o
o conteúdo é uma ou mais definições de variáveis ​​de ambiente no formato NOME = valor,
cada um separado por um caractere nulo. Isso permite o uso de caracteres especiais em
definições de ambiente.

-F, --nodefile=<nó lima>
Muito parecido com --nodelist, mas a lista está contida em um arquivo de nome nó lima. O
os nomes dos nós da lista também podem ocupar várias linhas no arquivo. Nó duplicado
nomes no arquivo serão ignorados. A ordem dos nomes dos nós na lista não é
importante; os nomes dos nós serão classificados por Slurm.

--get-user-env[=tempo limite][modo]
Esta opção dirá ao sbatch para recuperar as variáveis ​​de ambiente de login para o
usuário especificado no --uid opção. As variáveis ​​de ambiente são recuperadas por
executando algo desse tipo "su - -c / usr / bin / env"e analisando o
saída. Esteja ciente de que quaisquer variáveis ​​de ambiente já definidas no sbatch's
ambiente terá precedência sobre quaisquer variáveis ​​de ambiente no login do usuário
ambiente. Limpe quaisquer variáveis ​​de ambiente antes de chamar sbatch que você não
deseja propagado para o programa gerado. O opcional tempo limite o valor está em segundos.
O valor padrão é 8 segundos. O opcional modo valor controla as opções "su".
Com uma conta na modo valor de "S", "su" é executado sem a opção "-". Com um modo
valor de "L", "su" é executado com a opção "-", replicando o login
ambiente. Se modo não especificado, o modo estabelecido no momento da construção de Slurm é
usado. Exemplos de uso incluem "--get-user-env", "--get-user-env = 10"
"--get-user-env = 10L" e "--get-user-env = S". Esta opção foi originalmente criada
para uso por Moab.

--gid=<grupo>
If lote é executado como root, e o --gid opção for usada, envie o trabalho com grupo's
permissões de acesso do grupo. grupo pode ser o nome do grupo ou o ID numérico do grupo.

--gres=<Lista>
Especifica uma lista delimitada por vírgulas de recursos consumíveis genéricos. O formato de
cada entrada na lista é "nome [[: tipo]: contagem]". O nome é o do
recurso consumível. A contagem é o número desses recursos com um padrão
valor de 1. Os recursos especificados serão alocados para o trabalho em cada nó.
Os recursos consumíveis genéricos disponíveis são configuráveis ​​pelo sistema
administrador. Uma lista de recursos consumíveis genéricos disponíveis será impressa
e o comando será encerrado se o argumento da opção for "ajuda". Exemplos de uso
incluem "--gres = gpu: 2, mic = 1", "--gres = gpu: kepler: 2" e "--gres = help".

-H, --segurar
Especifique que o trabalho deve ser enviado em estado retido (prioridade zero). Um trabalho retido
agora pode ser liberado usando scontrol para redefinir sua prioridade (por exemplo, "controlar liberar
").

-h, --Socorro
Exibir informações de ajuda e sair.

--dica=<tipo>
Vincule as tarefas de acordo com as dicas do aplicativo.

limite_computador
Selecione as configurações para aplicativos de computação vinculada: use todos os núcleos em cada
socket, um thread por núcleo.

limite_de_memória
Selecione as configurações para aplicativos de memória: use apenas um núcleo em cada
socket, um thread por núcleo.

[não] multithread
[não] use threads extras com multi-threading in-core que pode se beneficiar
aplicações intensivas de comunicação. Compatível apenas com a tarefa / afinidade
plugin.

ajudar mostre esta mensagem de ajuda

-I, --imediato
O script em lote só será submetido ao controlador se os recursos
necessários para conceder sua alocação de trabalho estão imediatamente disponíveis. Se o trabalho
alocação terá que esperar em uma fila de trabalhos pendentes, o script de lote não
seja submetido. NOTA: Há suporte limitado para essa opção com trabalhos em lote.

--ignore-pbs
Ignore quaisquer opções "#PBS" especificadas no script de lote.

-i, --entrada=<nome do arquivo de cinto de segurança>
Instrua Slurm a conectar a entrada padrão do script em lote diretamente ao arquivo
nome especificado no "nome do arquivo de cinto de segurança".

Por padrão, "/ dev / null" é aberto na entrada padrão do script em lote e ambos
a saída padrão e o erro padrão são direcionados para um arquivo com o nome
"slurm-% j.out", onde o "% j" é substituído pelo número de alocação do trabalho, como
descrito abaixo.

O padrão de nome de arquivo pode conter um ou mais símbolos de substituição, que são um
sinal de porcentagem "%" seguido por uma letra (por exemplo,% j).

Os símbolos de substituição suportados são:

%A Número de alocação de trabalho mestre da matriz de trabalho.

%a Número de ID (índice) da matriz de trabalho.

%j Número de alocação do trabalho.

%N Nome do nó. Apenas um arquivo é criado, então% N será substituído pelo nome de
o primeiro nó da tarefa, que executa o script.

%u Nome do usuário.

-J, --nome do trabalho=<nome do trabalho>
Especifique um nome para a alocação de trabalho. O nome especificado aparecerá junto com
o número de identificação do trabalho ao consultar trabalhos em execução no sistema. O padrão é o nome
do script em lote, ou apenas "sbatch" se o script for lido no padrão de sbatch
entrada.

--ID de trabalho=<ID de trabalho>
Alocar recursos como o ID de trabalho especificado. NOTA: Válido apenas para o usuário root.

-k, --não mate
Não encerra automaticamente um trabalho se um dos nós foi alocado
falha. O usuário assumirá as responsabilidades de tolerância a falhas caso um nó
falhou. Quando há uma falha de nó, todas as etapas do trabalho ativo (geralmente trabalhos MPI) em
esse nó quase certamente sofrerá um erro fatal, mas com --no-kill, o trabalho
a alocação não será revogada para que o usuário possa iniciar novas etapas de trabalho no
nós restantes em sua alocação.

Por padrão, Slurm encerra toda a alocação de trabalho se qualquer nó falhar em seu
gama de nós alocados.

--kill-on-inválido-dep=<sim | não>
Se um trabalho tem uma dependência inválida e nunca pode ser executado, este parâmetro diz a Slurm
para encerrá-lo ou não. Um estado de trabalho encerrado será JOB_CANCELLED. Se este
a opção não for especificada, o comportamento de todo o sistema se aplica. Por padrão, o trabalho permanece
pendente com o motivo DependencyNeverSatisfied ou se o kill_invalid_depend for
especificado em slurm.conf, o trabalho é encerrado.

-L, --licenças=<licença>
Especificação de licenças (ou outros recursos disponíveis em todos os nós do
cluster) que deve ser alocado para este trabalho. Os nomes das licenças podem ser seguidos por um
dois pontos e contagem (a contagem padrão é um). Vários nomes de licença devem ser vírgulas
separados (por exemplo, "--licenses = foo: 4, bar"). Para enviar trabalhos usando licenças remotas,
aqueles servidos pelo slurmdbd, especifique o nome do servidor que fornece o
licenças. Por exemplo "--license = nastran @ slurmdb: 12".

-M, --grupos=<corda>
Clusters para os quais emitir comandos. Vários nomes de cluster podem ser separados por vírgulas. o
trabalho será submetido a um cluster fornecendo o trabalho esperado mais cedo
tempo de iniciação. O valor padrão é o cluster atual. Um valor de 'todos os' vai
consulta para executar em todos os clusters. Note o --exportar opção para controlar o ambiente
variáveis ​​exportadas entre clusters.

-m, --distribuição=
arbitrário|<quadra|cíclico|avião =[:quadra|cíclico|cíclico]>

Especifique métodos de distribuição alternativos para processos remotos. Em sbatch, este apenas
define variáveis ​​de ambiente que serão usadas por solicitações srun subsequentes. Esse
opção controla a atribuição de tarefas aos nós nos quais os recursos foram
alocados, e a distribuição desses recursos para tarefas de ligação (tarefa
afinidade). O primeiro método de distribuição (antes de ":") controla a distribuição
de recursos entre os nós. O segundo método de distribuição opcional (após ":")
controla a distribuição de recursos entre sockets dentro de um nó. Observe que
com select / cons_res, o número de cpus alocados em cada socket e nó pode ser
diferente. Referir-se http://slurm.schedmd.com/mc_support.html Para maiores informações
na alocação de recursos, atribuição de tarefas a nós e vinculação de tarefas a CPUs.

Primeiro método de distribuição:

quadra O método de distribuição em bloco distribuirá tarefas para um nó de forma que
tarefas consecutivas compartilham um nó. Por exemplo, considere uma alocação de três
nós, cada um com dois cpus. Um pedido de distribuição de bloco de quatro tarefas irá
distribuir essas tarefas para os nós com as tarefas um e dois no primeiro
nó, tarefa três no segundo nó e tarefa quatro no terceiro nó. Bloquear
distribuição é o comportamento padrão se o número de tarefas exceder o
número de nós alocados.

cíclico O método de distribuição cíclica distribuirá tarefas para um nó de forma que
tarefas consecutivas são distribuídas por nós consecutivos (em um round-robin
moda). Por exemplo, considere uma alocação de três nós, cada um com dois
cpus. Uma solicitação de distribuição cíclica de quatro tarefas distribuirá essas tarefas para
os nós com tarefas um e quatro no primeiro nó, tarefa dois no segundo
nó e tarefa três no terceiro nó. Observe que quando SelectType é
select / cons_res, o mesmo número de CPUs não pode ser alocado em cada nó.
A distribuição de tarefas será round-robin entre todos os nós com CPUs que ainda não
ser atribuído a tarefas. A distribuição cíclica é o comportamento padrão se o
o número de tarefas não é maior do que o número de nós alocados.

avião As tarefas são distribuídas em blocos de um tamanho especificado. As opções
inclua um número que representa o tamanho do bloco de tarefas. Isso é seguido
por uma especificação opcional do esquema de distribuição de tarefas dentro de um bloco
de tarefas e entre os blocos de tarefas. O número de tarefas distribuídas
para cada nó é o mesmo que para a distribuição cíclica, mas os taskids
atribuído a cada nó depende do tamanho do plano. Para mais detalhes (incluindo
exemplos e diagramas), consulte
http://slurm.schedmd.com/mc_support.html
e
http://slurm.schedmd.com/dist_plane.html

arbitrário
O método arbitrário de distribuição irá alocar processos em ordem como
listado no arquivo designado pela variável de ambiente SLURM_HOSTFILE. Se
esta variável é listada, substituirá qualquer outro método especificado. Se não
definir o método será o padrão para bloquear. Dentro do hostfile deve conter um
mínimo o número de hosts solicitados e ser um por linha ou vírgula
separados. Se especificar uma contagem de tarefas (-n, --ntasks=<número>), suas tarefas
será disposto nos nós na ordem do arquivo.
OBSERVAÇÃO: A opção de distribuição arbitrária em uma alocação de trabalho controla apenas
os nós a serem alocados para o trabalho e não a alocação de CPUs naqueles
nós. Esta opção destina-se principalmente a controlar o layout da tarefa de uma etapa do trabalho em
uma alocação de trabalho existente para o comando srun.

Segundo método de distribuição:

quadra O método de distribuição em bloco distribuirá tarefas para sockets de forma que
tarefas consecutivas compartilham um soquete.

cíclico O método de distribuição cíclica distribuirá tarefas para sockets de forma que
tarefas consecutivas são distribuídas em soquetes consecutivos (em um round-robin
moda). Tarefas que requerem mais de uma CPU terão todas essas CPUs
alocado em um único soquete, se possível.

cíclico
O método de distribuição fcyclic irá distribuir tarefas para sockets de forma que
tarefas consecutivas são distribuídas em soquetes consecutivos (em um round-robin
moda). Tarefas que requerem mais de uma CPU terão cada CPU alocada
de forma cíclica entre os soquetes.

--mail-type=<tipo>
Notifique o usuário por e-mail quando certos tipos de eventos ocorrerem. Válido tipo os valores são NENHUM,
BEGIN, END, FAIL, REQUEUE, ALL (equivalente a BEGIN, END, FAIL, REQUEUE e
STAGE_OUT), STAGE_OUT (saída de buffer de burst concluída), TIME_LIMIT, TIME_LIMIT_90
(atingiu 90 por cento do limite de tempo), TIME_LIMIT_80 (atingiu 80 por cento do tempo
limite) e TIME_LIMIT_50 (atingiu 50 por cento do limite de tempo). Múltiplo tipo valores
pode ser especificado em uma lista separada por vírgulas. O usuário a ser notificado é indicado
com --mail-usuário. Notificações por correio nas tarefas BEGIN, END e FAIL se aplicam a uma tarefa
array como um todo, em vez de gerar mensagens de e-mail individuais para cada tarefa em
a matriz de trabalho.

--mail-usuário=<usuário>
O usuário receberá notificação por e-mail de mudanças de estado, conforme definido por --mail-type. O
o valor padrão é o usuário que está enviando.

--mem=<MB>
Especifique a memória real necessária por nó em MegaBytes. O valor padrão é
DefMemPerNode e o valor máximo é MaxMemPerNode. Se configurado, ambos
parâmetros podem ser vistos usando o controlar mostrar configuração comando. Este parâmetro
geralmente seria usado se nós inteiros fossem alocados para trabalhos
(SelectType = select / linear). Veja também --mem-por-cpu. --mem e --mem-por-cpu e guarante que os mesmos estão
Mutualmente exclusivo. NOTA: Uma especificação de tamanho de memória é tratada como um caso especial
e concede ao trabalho acesso a toda a memória em cada nó. NOTA: Aplicação de
os limites de memória atualmente dependem do plugin task / cgroup ou habilitação de
contabilidade, que faz a amostragem do uso da memória periodicamente (os dados não precisam ser armazenados,
acabado de coletar). Em ambos os casos, o uso da memória é baseado no tamanho do conjunto residente do trabalho
(RSS). Uma tarefa pode exceder o limite de memória até a próxima contabilidade periódica
amostra.

--mem-por-cpu=<MB>
Memória mínima exigida por CPU alocada em MegaBytes. O valor padrão é
DefMemPerCPU e o valor máximo é MaxMemPerCPU (veja exceção abaixo). Se
configurados, ambos os parâmetros podem ser vistos usando o controlar mostrar configuração comando.
Observe que se o trabalho for --mem-por-cpu valor excede o configurado MaxMemPerCPU,
então, o limite do usuário será tratado como um limite de memória por tarefa; --mem-por-cpu
será reduzido a um valor não maior que MaxMemPerCPU; --cpus-por-tarefa será definido
e o valor de --cpus-por-tarefa multiplicado pelo novo --mem-por-cpu valor vai
igual ao original --mem-por-cpu valor especificado pelo usuário. Este parâmetro seria
geralmente é usado se processadores individuais são alocados para tarefas
(SelectType = select / cons_res) Se os recursos são alocados pelo núcleo, soquete ou
nós inteiros; o número de CPUs alocadas para um trabalho pode ser maior do que a tarefa
contagem e o valor de --mem-por-cpu deve ser ajustado em conformidade. Veja também
--mem. --mem e --mem-por-cpu são mutuamente exclusivos.

--mem_bind= [{quieto, prolixo},]tipo
Vincule tarefas à memória. Usado apenas quando o plugin de tarefa / afinidade está habilitado e o
Funções de memória NUMA estão disponíveis. Note que da resolução of CPU e memória
obrigatório pode diferir on alguns arquiteturas. Por exemplo, a ligação da CPU pode ser realizada
no nível dos núcleos dentro de um processador enquanto a ligação da memória será realizada
no nível de nós, onde a definição de "nós" pode diferir de sistema para
sistema. A usar of qualquer tipo de outros do que "Nenhum" or "local" is não recomendado. If
você deseja maior controle, tente executar um código de teste simples com as opções
"--mem_bind = verbose, none" para determinar a configuração específica.

NOTA: Para que o Slurm sempre informe sobre a ligação de memória selecionada para todos os comandos
executado em um shell, você pode ativar o modo verbose configurando o SLURM_MEM_BIND
valor da variável de ambiente para "verbose".

As seguintes variáveis ​​de ambiente informativas são definidas quando --mem_bind é em
usar:

SLURM_MEM_BIND_VERBOSE
SLURM_MEM_BIND_TYPE
SLURM_MEM_BIND_LIST

veja a MEIO AMBIENTE VARIÁVEIS seção para uma descrição mais detalhada do
variáveis ​​SLURM_MEM_BIND * individuais.

As opções com suporte incluem:

quieto]
ligar silenciosamente antes da execução da tarefa (padrão)

v [erbose]
relatar detalhadamente a ligação antes da execução da tarefa

Nenhum] não vincule tarefas à memória (padrão)

classificar vincular por classificação de tarefa (não recomendado)

local Use a memória local para o processador em uso

map_mem:
vincular mapeando a memória de um nó para tarefas conforme especificado onde é
, , ... . IDs de CPU são interpretados como valores decimais
a menos que sejam precedidos de '0x', caso em que interpretados como
valores hexadecimais (não recomendado)

mask_mem:
vincular definindo máscaras de memória em tarefas conforme especificado onde é
, , ... . máscaras de memória são sempre interpretado como
valores hexadecimais. Observe que as máscaras devem ser precedidas de um '0x' se elas
não comece com [0-9], então eles são vistos como valores numéricos por srun.

ajudar mostre esta mensagem de ajuda

--mincpus=<n>
Especifique um número mínimo de cpus / processadores lógicos por nó.

-N, --nós=<minnodes[-maxnodes]>
Solicite que um mínimo de minnodes nós sejam alocados para este trabalho. Um nó máximo
a contagem também pode ser especificada com maxnodes. Se apenas um número for especificado, este
é usado como contagem de nós mínimo e máximo. Os limites do nó da partição
substituem as do trabalho. Se os limites do nó de um trabalho estiverem fora do intervalo
permitido para sua partição associada, o trabalho será deixado em um estado PENDENTE.
Isso permite a execução possível em um momento posterior, quando o limite da partição é
mudado. Se um limite de nó de trabalho exceder o número de nós configurados no
partição, o trabalho será rejeitado. Observe que a variável de ambiente
SLURM_NNODES será definido para a contagem de nós realmente alocados para o trabalho. Ver
da MEIO AMBIENTE VARIÁVEIS seção para mais informações. Se -N não é especificado,
o comportamento padrão é alocar nós suficientes para satisfazer os requisitos do
-n e -c opções. O trabalho será alocado para tantos nós quanto possível dentro do
intervalo especificado e sem atrasar o início do trabalho. A contagem de nós
especificação pode incluir um valor numérico seguido por um sufixo de "k" (multiplica
valor numérico por 1,024) ou "m" (multiplica o valor numérico por 1,048,576).

-n, --ntasks=<número>
O sbatch não inicia tarefas, ele solicita uma alocação de recursos e envia um
script em lote. Esta opção informa ao controlador Slurm que as etapas do trabalho são executadas dentro
a alocação irá lançar no máximo número tarefas e para fornecer para
Recursos. O padrão é uma tarefa por nó, mas observe que o --cpus-por-tarefa
opção irá alterar este padrão.

--rede=<tipo>
Especifique as informações pertencentes ao switch ou rede. A interpretação de
tipo é dependente do sistema. Esta opção é suportada ao executar Slurm em um Cray
nativamente. Ele é usado para solicitar usando contadores de desempenho de rede. Apenas um valor
por pedido é válido. Todas as opções não diferenciam maiúsculas de minúsculas. Nesta configuração
os valores suportados incluem:

.
Use os contadores de desempenho da rede em todo o sistema. Somente nós solicitados irão
ser marcado em uso para a alocação de trabalho. Se o trabalho não preencher o
sistema inteiro, o resto dos nós não podem ser usados ​​por outros trabalhos
usando NPC, se ocioso, seu estado aparecerá como PerfCnts. Esses nós são
ainda disponível para outros trabalhos que não usam NPC.

lâmina Use os contadores de desempenho de rede blade. Somente nós solicitados serão
marcado em uso para a alocação de trabalho. Se o trabalho não preencher todo o
lâmina (s) alocada (s) para o trabalho, essa (s) lâmina (s) não podem ser usadas por outro
jobs usando NPC, se ociosos, seu estado aparecerá como PerfCnts. Esses nós são
ainda disponível para outros trabalhos que não usam NPC.

Em todos os casos, o pedido de alocação de trabalho devo especificamos da
--opção exclusiva. Caso contrário, o pedido será negado.

Além disso, com qualquer uma dessas opções, as etapas não têm permissão para compartilhar blades, portanto, os recursos
permaneceria ocioso dentro de uma alocação se a etapa em execução em uma lâmina não der certo
todos os nós da lâmina.

A rede opção também é suportada em sistemas com Ambiente Paralelo da IBM
(EDUCAÇAO FISICA). Consulte a documentação da palavra-chave do comando de trabalho LoadLeveler da IBM sobre a palavra-chave
"rede" para obter mais informações. Vários valores podem ser especificados em uma vírgula
lista separada. Todas as opções não diferenciam maiúsculas de minúsculas. Os valores suportados incluem:

BULK_XFER[=recursos>]
Habilite a transferência em massa de dados usando RDMA (Remote Direct-Memory Access).
O opcional recursos especificação é um valor numérico que pode ter
um sufixo de "k", "K", "m", "M", "g" ou "G" para kilobytes, megabytes ou
gigabytes. Note o recursos especificação não é suportada pelo
infraestrutura IBM subjacente a partir do Parallel Environment versão 2.2
e nenhum valor deve ser especificado neste momento.

CAU=<contar> Número de unidades de aceleração coletiva (CAU) necessárias. Aplica-se apenas
para processadores IBM Power7-IH. O valor padrão é zero. CAU independente
será alocado para cada interface de programação (MPI, LAPI, etc.)

DEVNAME=<nome>
Especifique o nome do dispositivo a ser usado para comunicações (por exemplo, "eth0" ou
"mlx4_0").

TIPO DEV.=<tipo>
Especifique o tipo de dispositivo a ser usado para comunicações. O apoiado
valores de tipo são: "IB" (InfiniBand), "HFI" (P7 Host Fabric
Interface), "IPONLY" (interfaces somente IP), "HPCE" (HPC Ethernet) e
"KMUX" (Emulação de kernel de HPCE). Os dispositivos alocados para um trabalho devem
todos sejam do mesmo tipo. O valor padrão depende de
qual hardware está disponível e em ordem de preferências é IPONLY (qual
não é considerado no modo Espaço do usuário), HFI, IB, HPCE e KMUX.

IMEDIATO =<contar>
Número de slots de envio imediato por janela necessária. Aplica-se apenas a
Processadores IBM Power7-IH. O valor padrão é zero.

INSTÂNCIAS =<contar>
Especifique o número de conexões de rede para cada tarefa em cada rede
conexão. A contagem de instâncias padrão é 1.

IPV4 Use as comunicações do protocolo da Internet (IP) versão 4 (padrão).

IPV6 Use as comunicações do protocolo da Internet (IP) versão 6.

LAPI Use a interface de programação LAPI.

MPI Use a interface de programação MPI. MPI é a interface padrão.

PAMI Use a interface de programação PAMI.

SHMEM Use a interface de programação OpenSHMEM.

SN_ALL Use todas as redes de switch disponíveis (padrão).

SN_SINGLE Use uma rede de switch disponível.

UPC Use a interface de programação UPC.

US Use as comunicações do espaço do usuário.

Alguns exemplos de especificações de rede:

Instâncias = 2, US, MPI, SN_ALL
Crie duas conexões de espaço do usuário para comunicações MPI em cada
mudar de rede para cada tarefa.

US, MPI, instâncias = 3, Devtype = IB
Crie três conexões de espaço de usuário para comunicações MPI em cada
Rede InfiniBand para cada tarefa.

IPV4, LAPI, SN_Single
Crie uma conexão IP versão 4 para comunicações LAPI em um switch
rede para cada tarefa.

Instâncias = 2, US, LAPI, MPI
Crie duas conexões de espaço de usuário cada para comunicações LAPI e MPI
em cada rede de switch para cada tarefa. Observe que SN_ALL é o padrão
opção para que cada rede de switch seja usada. Observe também que Instâncias = 2
especifica que duas conexões são estabelecidas para cada protocolo (LAPI
e MPI) e cada tarefa. Se houver duas redes e quatro tarefas no
o nó, então, um total de 32 conexões são estabelecidas (2 instâncias x
2 protocolos x 2 redes x 4 tarefas).

--legais[=ajustamento]
Execute o trabalho com uma prioridade de programação ajustada no Slurm. Sem ajuste
valor, a prioridade de programação é reduzida em 100. O intervalo de ajuste é de
-10000 (prioridade mais alta) a 10000 (prioridade mais baixa). Apenas usuários privilegiados podem
especificar um ajuste negativo. NOTA: Esta opção é atualmente ignorada se
SchedulerType = sched / wiki or SchedulerType = sched / wiki2.

--sem fila
Especifica que o trabalho em lote nunca deve ser enfileirado novamente.
Definir esta opção impedirá que os administradores do sistema sejam capazes de reiniciar
o trabalho (por exemplo, após um tempo de inatividade programado), recuperar de uma falha de nó ou
ser enfileirado novamente na preempção por um trabalho de prioridade mais alta. Quando um trabalho é colocado na fila novamente, o
o script em lote é iniciado desde o início. Veja também o --reenfileirar opção. O
JobRequeue O parâmetro de configuração controla o comportamento padrão no cluster.

--ntasks-por-núcleo=<tarefas>
Solicite o máximo tarefas ser chamado em cada núcleo. Destina-se a ser usado com o
--ntasks opção. Relacionado a --ntasks-por-nó exceto no nível central, em vez de
o nível do nó. NOTA: Esta opção não é compatível, a menos que
SelectTypeParameters = CR_Core or SelectTypeParameters = CR_Core_Memory está configurado.

--ntasks por soquete=<tarefas>
Solicite o máximo tarefas ser invocado em cada soquete. Destina-se a ser usado com o
--ntasks opção. Relacionado a --ntasks-por-nó exceto no nível do soquete ao invés
do nível do nó. NOTA: Esta opção não é compatível, a menos que
SelectTypeParameters = CR_Socket or SelectTypeParameters = CR_Socket_Memory is
configurado.

--ntasks-por-nó=<tarefas>
Solicite isso tarefas ser chamado em cada nó. Se usado com o --ntasks opção, o
--ntasks opção terá precedência e o --ntasks-por-nó será tratado como um
máximo contagem de tarefas por nó. Destina-se a ser usado com o --nós opção. Isto
está relacionado a --cpus-por-tarefa=ncpus, mas não requer conhecimento do real
número de cpus em cada nó. Em alguns casos, é mais conveniente ser capaz de
solicitar que não mais do que um número específico de tarefas seja chamado em cada nó.
Exemplos disso incluem o envio de um aplicativo MPI / OpenMP híbrido em que apenas um MPI
"tarefa / classificação" deve ser atribuída a cada nó, permitindo que a parte OpenMP para
utilizar todo o paralelismo presente no nó, ou enviar um único
configuração / limpeza / monitoramento de trabalho para cada nó de uma alocação pré-existente como uma etapa
em um script de trabalho maior.

-O, --overcommit
Supercomprimir recursos. Quando aplicado à alocação de trabalho, apenas uma CPU é alocada para
o trabalho por nó e opções usadas para especificar o número de tarefas por nó, soquete,
core, etc. são ignorados. Quando aplicado a alocações de etapas de trabalho (o correr comando
quando executado dentro de uma alocação de trabalho existente), esta opção pode ser usada para lançar
mais de uma tarefa por CPU. Normalmente, correr não alocará mais de um processo
por CPU. Especificando --overcommit você está permitindo explicitamente mais de um
processo por CPU. No entanto, não mais do que MAX_TASKS_PER_NODE tarefas são permitidas para
execute por nó. NOTA: MAX_TASKS_PER_NODE está definido no arquivo slurm.h e é
não é uma variável, é definida no momento da construção de Slurm.

-o, --resultado=<nome do arquivo de cinto de segurança>
Instrua Slurm a conectar a saída padrão do script em lote diretamente ao arquivo
nome especificado no "nome do arquivo de cinto de segurança". Por padrão, a saída padrão e
o erro padrão é direcionado para o mesmo arquivo. Para matrizes de trabalho, o arquivo padrão
o nome é "slurm-% A_% a.out", "% A" é substituído pelo ID do trabalho e "% a" pelo array
índice. Para outros trabalhos, o nome do arquivo padrão é "slurm-% j.out", onde o "% j" é
substituído pelo ID do trabalho. Veja o --entrada opção para opções de especificação de nome de arquivo.

- modo aberto= anexar | truncar
Abra os arquivos de saída e de erro usando o modo anexar ou truncar conforme especificado. o
o valor padrão é especificado pelo parâmetro de configuração do sistema JobFileAnexar.

--parsável
Exibe apenas o número de identificação do trabalho e o nome do cluster, se houver. Os valores são
separados por ponto e vírgula. Os erros ainda serão exibidos.

-p, --partição=<nome_da_partição>
Solicite uma partição específica para a alocação de recursos. Se não for especificado, o
o comportamento padrão é permitir que o controlador slurm selecione a partição padrão
conforme designado pelo administrador do sistema. Se o trabalho pode usar mais de um
partição, especifique seus nomes em uma lista separada por vírgulas e aquela que oferece
a primeira iniciação será usada sem levar em consideração o nome da partição
ordenação (embora partições de prioridade mais alta sejam consideradas primeiro). Quando o
o trabalho for iniciado, o nome da partição usada será colocado primeiro no trabalho
string de partição de registro.

--potência=<bandeiras>
Lista separada por vírgulas de opções de plug-ins de gerenciamento de energia. Bandeiras atualmente disponíveis
incluem: nível (todos os nós alocados para o trabalho devem ter limites de energia idênticos,
pode ser desabilitado pela opção de configuração Slurm PowerParameters = job_no_level).

--prioridade=
Solicite uma prioridade de trabalho específica. Pode estar sujeito a configurações específicas
restrições. Apenas operadores e administradores Slurm podem definir a prioridade de um
trabalho.

--perfil=
permite a coleta de dados detalhados pelo plug-in acct_gather_profile. Dados detalhados
normalmente são séries temporais que são armazenadas em um arquivo HDF5 para o trabalho.

Todos Todos os tipos de dados são coletados. (Não pode ser combinado com outros valores.)

nenhum Nenhum tipo de dados é coletado. Este é o padrão.
(Não pode ser combinado com outros valores.)

Energia Os dados de energia são coletados.

Tarefa Dados de tarefa (E / S, Memória, ...) são coletados.

Brilho Os dados do Lustre são coletados.

Network Os dados da rede (InfiniBand) são coletados.

--propagar[=rlimitfR]
Permite que os usuários especifiquem quais dos limites de recursos modificáveis ​​(soft) devem ser propagados
aos nós de computação e se aplicam a seus trabalhos. Se limites não é especificado, então
todos os limites de recursos serão propagados. Os seguintes nomes de rlimit são suportados
por Slurm (embora algumas opções possam não ser suportadas em alguns sistemas):

TODAS Todos os limites listados abaixo

AS O espaço de endereço máximo para um processo

NÚCLEO O tamanho máximo do arquivo principal

CPU A quantidade máxima de tempo de CPU

DADOS O tamanho máximo do segmento de dados de um processo

TAMANHO FS O tamanho máximo dos arquivos criados. Observe que se o usuário definir FSIZE como
menor que o tamanho atual do slurmd.log, a inicialização do job falhará com
um erro de 'Limite de tamanho de arquivo excedido'.

MEMLOCK O tamanho máximo que pode ser bloqueado na memória

NENHUM ARQUIVO O número máximo de arquivos abertos

NPROC O número máximo de processos disponíveis

RSS O tamanho máximo do conjunto residente

PILHA O tamanho máximo da pilha

-Q, --quieto
Suprime as mensagens informativas do sbatch. Os erros ainda serão exibidos.

--qos=<Qos>
Solicite um serviço de qualidade para o trabalho. Os valores de QOS podem ser definidos para cada
associação de usuário / cluster / conta no banco de dados Slurm. Os usuários serão limitados a
seu conjunto definido de associação de qos quando o parâmetro de configuração Slurm,
AccountingStorageEnforce, inclui "qos" em sua definição.

--reinício
Force os nós alocados a reinicializar antes de iniciar o trabalho. Este é apenas
compatível com algumas configurações do sistema e, caso contrário, será ignorado silenciosamente.

--reenfileirar
Especifica que a tarefa em lote deve ser elegível para recolocação na fila. O trabalho pode ser
recolocado na fila explicitamente por um administrador do sistema, após a falha do nó ou mediante
preempção por um trabalho de maior prioridade. Quando um trabalho é enfileirado novamente, o script em lote é
iniciado desde o seu início. Veja também o --sem fila opção. O JobRequeue
O parâmetro de configuração controla o comportamento padrão no cluster.

--reserva=<nome>
Aloque recursos para o trabalho da reserva nomeada.

-s, --compartilhado
A alocação de trabalho pode compartilhar recursos com outros trabalhos em execução. Os recursos para
podem ser compartilhados, nós, soquetes, núcleos ou hyperthreads, dependendo de
configuração. O comportamento padrão compartilhado depende da configuração do sistema e do
partição Partilhado a opção tem precedência sobre a opção do trabalho. Esta opção pode
resultar na atribuição sendo concedida mais cedo do que se a opção --share não fosse
definir e permitir maior utilização do sistema, mas o desempenho do aplicativo provavelmente
sofrer devido à competição por recursos. Veja também a opção --exclusive.

-S, --core-spec=<Números>
Contagem de núcleos especializados por nó reservado pelo trabalho para operações do sistema e
não usado pelo aplicativo. O aplicativo não usará esses núcleos, mas será
cobrados por sua alocação. O valor padrão depende do nó
valor CoreSpecCount configurado. Se um valor de zero for designado e o Slurm
opção de configuração AllowSpecResourcesUsage está habilitada, o trabalho terá permissão para
substituir CoreSpecCount e usar os recursos especializados nos nós que está alocado.
Esta opção não pode ser usada com o --especificação de thread opção.

--sicp Identifique uma tarefa como aquela da qual as tarefas enviadas a outros clusters podem ser dependentes.

--sinal= [B:]núm_sig> [@hora_sig_time>]
Quando um trabalho está dentro hora_sig_time segundos do tempo de término, envie-lhe o sinal núm_sig.
Devido à resolução de tratamento de eventos por Slurm, o sinal pode ser enviado em até 60
segundos antes do especificado. núm_sig pode ser um número de sinal ou nome
(por exemplo, "10" ou "USR1"). hora_sig_time deve ter um valor inteiro entre 0 e 65535.
Por padrão, nenhum sinal é enviado antes do horário de término do trabalho. Se um núm_sig é especificado
sem nenhum hora_sig_time, o tempo padrão será 60 segundos. Use a opção "B:" para
sinalize apenas o shell do lote, nenhum dos outros processos será sinalizado. Por
padrão, todas as etapas do trabalho serão sinalizadas, mas não o shell do lote em si.

--soquetes-por-nó=<soquetes>
Restrinja a seleção de nós para nós com pelo menos o número especificado de soquetes.
Veja informações adicionais em -B opção acima quando o plugin de tarefa / afinidade é
ativado.

--comuta=<contar> [@tempo máximo>]
Quando uma topologia de árvore é usada, isso define a contagem máxima de opções desejadas
para a alocação de trabalho e, opcionalmente, o tempo máximo de espera por esse número de
comuta. Se Slurm encontrar uma alocação contendo mais opções do que a contagem
especificado, o trabalho permanece pendente até encontrar uma alocação com o
mudar a contagem ou o limite de tempo expirar. Se não houver limite de contagem de interruptores,
não há demora em iniciar o trabalho. Os formatos de hora aceitáveis ​​incluem "minutos",
"minutos: segundos", "horas: minutos: segundos", "dias-horas", "dias-horas: minutos" e
"dias-horas: minutos: segundos". O atraso máximo do trabalho pode ser limitado pelo
administrador do sistema usando o Parâmetros do Agendador parâmetro de configuração com o
max_switch_wait opção de parâmetro. O tempo máximo padrão é max_switch_wait
Parâmetros do Agendador.

-t, --Tempo=<tempo>
Defina um limite para o tempo total de execução da alocação de trabalho. Se a hora solicitada
limite excede o limite de tempo da partição, o trabalho será deixado em um estado PENDENTE
(possivelmente indefinidamente). O limite de tempo padrão é o tempo padrão da partição
limite. Quando o limite de tempo é atingido, cada tarefa em cada etapa do trabalho é enviada SIGTERM
seguido por SIGKILL. O intervalo entre os sinais é especificado pelo Slurm
parâmetro de configuração KillWaitName. O Limite de tempo extra parâmetro de configuração pode
permitir que o trabalho seja executado por mais tempo do que o programado. A resolução de tempo é de um minuto e
os segundos valores são arredondados para o minuto seguinte.

Um limite de tempo de zero requer que nenhum limite de tempo seja imposto. Tempo aceitável
os formatos incluem "minutos", "minutos: segundos", "horas: minutos: segundos",
"dias-horas", "dias-horas: minutos" e "dias-horas: minutos: segundos".

--tarefas por nó=<n>
Especifique o número de tarefas a serem iniciadas por nó. Equivalente a
--ntasks-por-nó.

--somente teste
Valide o script em lote e retorne uma estimativa de quando um trabalho seria agendado
para executar dada a fila de trabalho atual e todos os outros argumentos que especificam o trabalho
requisitos. Nenhum trabalho é realmente enviado.

--especificação de thread=<Números>
Contagem de threads especializados por nó reservado pelo trabalho para operações do sistema e
não usado pelo aplicativo. O aplicativo não usará esses threads, mas
ser cobrados por sua alocação. Esta opção não pode ser usada com o --core-spec
opção.

--threads por núcleo=<tópicos>
Restringir a seleção de nós para nós com pelo menos o número especificado de threads por
essencial. NOTA: "Threads" refere-se ao número de unidades de processamento em cada núcleo, em vez
do que o número de tarefas do aplicativo a serem iniciadas por núcleo. Veja mais
informação sob -B opção acima quando o plugin de tarefa / afinidade está habilitado.

--tempo-min=<tempo>
Defina um limite de tempo mínimo para a alocação de trabalho. Se especificado, o trabalho pode ter
é --Tempo limite reduzido para um valor não inferior a --tempo-min se isso permitir
o trabalho para iniciar a execução mais cedo do que de outra forma possível. O limite de tempo do trabalho
não será alterado depois que os recursos forem alocados ao trabalho. Isso é realizado por um
algoritmo de programação de aterramento para alocar recursos de outra forma reservados para superiores
empregos prioritários. Os formatos de hora aceitáveis ​​incluem "minutos", "minutos: segundos",
"horas: minutos: segundos", "dias-horas", "dias-horas: minutos" e
"dias-horas: minutos: segundos".

--tmp=<MB>
Especifique uma quantidade mínima de espaço em disco temporário.

-u, --uso
Exibe uma breve mensagem de ajuda e sai.

--uid=<usuário>
Tentar enviar e / ou executar um trabalho como usuário em vez do ID do usuário de chamada. o
invocar as credenciais do usuário será usado para verificar as permissões de acesso para o alvo
partição. O usuário root pode usar esta opção para executar trabalhos como um usuário normal em um RootOnly
partição por exemplo. Se executado como root, lote irá deixar suas permissões para o uid
especificado após a alocação do nó ser bem-sucedida. usuário pode ser o nome do usuário ou
ID de usuário numérico.

-V, --versão
Exibir informações da versão e sair.

-v, --verbose
Aumente o detalhamento das mensagens informativas do sbatch. Múltiplo -v'lavagem
aumentar ainda mais a verbosidade do sbatch. Por padrão, apenas erros serão exibidos.

-w, --lista de nós=<nó nome Lista>
Solicite uma lista específica de hosts. O trabalho conterá todos os desses hospedeiros e
possivelmente hosts adicionais conforme necessário para satisfazer os requisitos de recursos. A lista pode
ser especificado como uma lista separada por vírgulas de hosts, um intervalo de hosts (host [1-5,7, ...]
por exemplo) ou um nome de arquivo. A lista de hosts será considerada um nome de arquivo se
contém um caractere "/". Se você especificar um nó mínimo ou contagem de processador maior
do que pode ser satisfeito pela lista de hosts fornecida, recursos adicionais serão
alocados em outros nós conforme necessário. Nomes de nós duplicados na lista serão
ignorado. A ordem dos nomes dos nós na lista não é importante; os nomes dos nós
será classificado por Slurm.

--wait-all-nós=<valor>
Controla quando a execução do comando começa. Por padrão, o trabalho começará
execução assim que a atribuição é feita.

0 Comece a execução assim que a alocação puder ser feita. Não espere por todos os nós
para estar pronto para uso (ou seja, inicializado).

1 Não comece a execução até que todos os nós estejam prontos para uso.

--wckey=<wckey>
Especifique wckey a ser usado com o trabalho. Se TrackWCKey = no (padrão) no slurm.conf
este valor é ignorado.

--enrolar=<comando corda>
Sbatch irá envolver a string de comando especificada em um script de shell "sh" simples e
envie esse script para o controlador slurm. Quando --wrap é usado, um nome de script e
os argumentos não podem ser especificados na linha de comando; em vez disso, o gerado por sbatch
o script wrapper é usado.

-x, --excluir=<nó nome Lista>
Exclua explicitamente certos nós dos recursos concedidos ao trabalho.

As seguintes opções suportam sistemas Blue Gene, mas podem ser aplicáveis ​​a outros sistemas como
bem.

--blrts-imagem=<caminho>
Caminho para o Supervisor de tempo de execução do Blue GeneL, ou blrts, imagem para o bloco bluegene. BGL
só. Padrão de blugene.conf se não for definido.

--cnload-imagem=<caminho>
Caminho para calcular a imagem do nó para o bloco bluegene. Apenas BGP. Padrão de
blugene.conf se não for definido.

--conn-type=<tipo>
Exigir que o tipo de conexão em bloco seja de um determinado tipo. No Blue Gene, o
aceitável de tipo são MESH, TORUS e NAV. Se NAV, ou se não for definido, então Slurm irá
tente ajustar o que o DefaultConnType está definido no bluegene.conf se não for
definir o padrão é TORUS. Normalmente, você não deve definir esta opção. Se correr em
um sistema BGP e querendo funcionar no modo HTC (apenas para 1 plano médio e inferior). Vocês
pode usar HTC_S para SMP, HTC_D para Dual, HTC_V para modo de nó virtual e HTC_L para
Modo Linux. Para sistemas que permitem um tipo de conexão diferente por dimensão, você
pode fornecer uma lista separada por vírgulas de tipos de conexão podem ser especificados, um para
cada dimensão (ou seja, M, T, T, T lhe dará uma conexão de toro é todas as dimensões
espere o primeiro).

-g, --geometria=<XxYxZ> |AxXxYxZ>
Especifique os requisitos de geometria para o trabalho. Nos sistemas BlueGene / L e BlueGene / P
existem três números que fornecem dimensões nas direções X, Y e Z, enquanto em
Nos sistemas BlueGene / Q, existem quatro números que fornecem as dimensões em A, X, Y e Z
direções e não pode ser usado para alocar sub-blocos. Por exemplo
"--geometria = 1x2x3x4", especifica um bloco de nós com 1 x 2 x 3 x 4 = 24 nós
(na verdade, midplanes no BlueGene).

--ioload-imagem=<caminho>
Caminho para a imagem io para o bloco bluegene. Apenas BGP. Padrão de blugene.conf se não
definido.

--linux-imagem=<caminho>
Caminho para a imagem do Linux para o bloco bluegene. BGL apenas. Padrão de blugene.conf if
não configurado.

--mloader-imagem=<caminho>
Caminho para a imagem do mloader para o bloco bluegene. Padrão de blugene.conf se não for definido.

-R, --não-girar
Desativa a rotação da geometria solicitada do trabalho, a fim de se ajustar a um apropriado
bloquear. Por padrão, a geometria especificada pode girar em três dimensões.

--ramdisk-imagem=<caminho>
Caminho para a imagem ramdisk do bloco bluegene. BGL apenas. Padrão de blugene.conf if
não configurado.

INPUT MEIO AMBIENTE VARIÁVEIS

Na inicialização, o sbatch irá ler e lidar com as opções definidas no ambiente a seguir
variáveis. Observe que as variáveis ​​de ambiente substituirão quaisquer opções definidas em um lote
script e opções de linha de comando substituirão quaisquer variáveis ​​de ambiente.

SBATCH_ACCOUNT Igual a -UMA, --conta

SBATCH_ACCTG_FREQ Igual a --acctg-freq

SBATCH_ARRAY_INX Igual a -uma, --variedade

SBATCH_BLRTS_IMAGE Igual a --blrts-imagem

SBATCH_BURST_BUFFER Igual a --bb

SBATCH_CHECKPOINT Igual a - checkpoint

SBATCH_CHECKPOINT_DIR Igual a --ponto de verificação-dir

SBATCH_CLUSTERS or SLURM_CLUSTERS
Igual a --grupos

SBATCH_CNLOAD_IMAGE Igual a --cnload-imagem

SBATCH_CONN_TYPE Igual a --conn-type

SBATCH_CORE_SPEC Igual a --core-spec

SBATCH_DEBUG Igual a -dentro, --verbose

SBATCH_DISTRIBUTION Igual a -m, --distribuição

SBATCH_EXCLUSIVE Igual a --exclusivo

SBATCH_EXPORT Igual a --exportar

SBATCH_GEOMETRIA Igual a -g, --geometria

SBATCH_GET_USER_ENV Igual a --get-user-env

SBATCH_HINT or SLURM_HINT
Igual a --dica

SBATCH_IGNORE_PBS Igual a --ignore-pbs

SBATCH_IMMEDIATE Igual a -EU, --imediato

SBATCH_IOLOAD_IMAGE Igual a --ioload-imagem

SBATCH_JOBID Igual a --ID de trabalho

SBATCH_JOB_NAME Igual a -J, --nome do trabalho

SBATCH_LINUX_IMAGE Igual a --linux-imagem

SBATCH_MEM_BIND Igual a --mem_bind

SBATCH_MLOADER_IMAGE Igual a --mloader-imagem

SBATCH_NETWORK Igual a --rede

SBATCH_NO_REQUEUE Igual a --sem fila

SBATCH_NO_ROTATE Igual a -R, --não-girar

SBATCH_OPEN_MODE Igual a - modo aberto

SBATCH_OVERCOMMIT Igual a -O, --overcommit

SBATCH_PARTITION Igual a -p, --partição

SBATCH_POWER Igual a --potência

SBATCH_PROFILE Igual a --perfil

SBATCH_QOS Igual a --qos

SBATCH_RAMDISK_IMAGE Igual a --ramdisk-imagem

SBATCH_RESERVATION Igual a --reserva

SBATCH_REQ_SWITCH Quando uma topologia de árvore é usada, isso define a contagem máxima de
opções desejadas para a alocação de trabalho e, opcionalmente, o máximo
tempo para esperar por esse número de interruptores. Ver --comuta

SBATCH_REQUEUE Igual a --reenfileirar

SBATCH_SICP Igual a --sicp

SBATCH_SIGNAL Igual a --sinal

SBATCH_THREAD_SPEC Igual a --especificação de thread

SBATCH_TIMELIMIT Igual a -t, --Tempo

SBATCH_WAIT_ALL_NODES Igual a --wait-all-nós

SBATCH_WAIT4SWITCH Tempo máximo de espera pelos interruptores solicitados. Ver --comuta

SBATCH_WCKEY Igual a --wckey

SLURM_CONF A localização do arquivo de configuração Slurm.

SLURM_EXIT_ERROR Especifica o código de saída gerado quando ocorre um erro Slurm (por exemplo
opções inválidas). Isso pode ser usado por um script para distinguir
códigos de saída do aplicativo de várias condições de erro Slurm.

SLURM_STEP_KILLED_MSG_NODE_ID= ID
Se definido, apenas o nó especificado irá registrar quando o trabalho ou etapa são
morto por um sinal.

SAÍDA MEIO AMBIENTE VARIÁVEIS

O controlador Slurm irá definir as seguintes variáveis ​​no ambiente do lote
script.

BASIL_RESERVATION_ID
O ID de reserva em sistemas Cray executando apenas ALPS / BASIL.

MPIRUN_NOALLOCATE
Não aloque um bloco apenas em sistemas Blue Gene L / P.

MPIRUN_NOFREE
Não libere um bloco apenas em sistemas Blue Gene L / P.

MPIRUN_PARTITION
O nome do bloco apenas em sistemas Blue Gene.

SBATCH_CPU_BIND
Defina o valor da opção --cpu_bind.

SBATCH_CPU_BIND_VERBOSE
Defina como "verbose" se a opção --cpu_bind incluir a opção verbose. Definido como
"quieto" caso contrário.

SBATCH_CPU_BIND_TYPE
Defina como o tipo de vinculação da CPU especificado com a opção --cpu_bind. Valores possíveis
duas strings possíveis separadas por vírgulas. A primeira string possível identifica o
entidade a ser vinculada a: "threads", "núcleos", "sockets", "ldoms" e "boards". o
a segunda string identifica a maneira pela qual as tarefas são vinculadas: "nenhum", "classificação",
"map_cpu", "mask_cpu", "rank_ldom", "map_ldom" ou "mask_ldom".

SBATCH_CPU_BIND_LIST
Definido como máscara de bits usada para vinculação de CPU.

SBATCH_MEM_BIND
Defina o valor da opção --mem_bind.

SBATCH_MEM_BIND_VERBOSE
Defina como "verbose" se a opção --mem_bind incluir a opção verbose. Definido como
"quieto" caso contrário.

SBATCH_MEM_BIND_TYPE
Defina para o tipo de ligação de memória especificado com a opção --mem_bind. Possível
os valores são "none", "rank", "map_map", "mask_mem" e "local".

SBATCH_MEM_BIND_LIST
Definido como máscara de bits usada para vinculação de memória.

SLURM_ARRAY_TASK_ID
Número de ID (índice) da matriz de trabalho.

SLURM_ARRAY_TASK_MAX
Número máximo de ID (índice) da matriz de trabalho.

SLURM_ARRAY_TASK_MIN
Número mínimo de ID (índice) da matriz de trabalho.

SLURM_ARRAY_TASK_STEP
Tamanho da etapa do índice da matriz de trabalho.

SLURM_ARRAY_JOB_ID
Número de identificação do trabalho mestre da matriz de trabalho.

SLURM_CHECKPOINT_IMAGE_DIR
Diretório no qual as imagens do ponto de verificação devem ser gravadas, se especificado no
executar linha.

SLURM_CLUSTER_NAME
Nome do cluster no qual o trabalho está sendo executado.

SLURM_CPUS_ON_NODE
Número de CPUS no nó alocado.

SLURM_CPUS_PER_TASK
Número de cpus solicitados por tarefa. Apenas definido se o --cpus-por-tarefa opção
Especificadas.

SLURM_DISTRIBUTION
Igual a -m, --distribuição

SLURM_GTIDS
IDs de tarefas globais em execução neste nó. Origem zero e separados por vírgula.

SLURM_JOB_ID (E SLURM_JOBID para compatibilidade com versões anteriores)
O ID da alocação de trabalho.

SLURM_JOB_CPUS_PER_NODE
Contagem de processadores disponíveis para o trabalho neste nó. Observe o select / linear
plugin aloca nós inteiros para trabalhos, então o valor indica a contagem total de
CPUs no nó. O plugin select / cons_res aloca processadores individuais para
trabalhos, então este número indica o número de processadores neste nó alocado para
o emprego.

SLURM_JOB_DEPENDENCY
Defina o valor da opção --dependency.

SLURM_JOB_NAME
Nome do trabalho.

SLURM_JOB_NODELIST (E SLURM_NODELIST para compatibilidade com versões anteriores)
Lista de nós alocados para o trabalho.

SLURM_JOB_NUM_NODES (E SLURM_NNODES para compatibilidade com versões anteriores)
Número total de nós na alocação de recursos do trabalho.

SLURM_JOB_PARTITION
Nome da partição na qual o trabalho está sendo executado.

SLURM_LOCALID
ID de tarefa local do nó para o processo em um trabalho.

SLURM_NODE_ALIASES
Conjuntos de nome de nó, endereço de comunicação e nome de host para nós alocados para o
trabalho da nuvem. Cada elemento no conjunto é separado por dois pontos e cada conjunto é
separados por vírgulas. Por exemplo: SLURM_NODE_ALIASES = ec0: 1.2.3.4: foo, ec1: 1.2.3.5: bar

SLURM_NODEID
ID dos nós alocados.

SLURMD_NODENAME
Nomes de todos os nós alocados.

SLURM_NTASKS (E SLURM_NPROCS para compatibilidade com versões anteriores)
Igual a -n, --ntasks

SLURM_NTASKS_PER_CORE
Número de tarefas solicitadas por núcleo. Apenas definido se o --ntasks-por-núcleo opção
Especificadas.

SLURM_NTASKS_PER_NODE
Número de tarefas solicitadas por nó. Apenas definido se o --ntasks-por-nó opção
Especificadas.

SLURM_NTASKS_PER_SOCKET
Número de tarefas solicitadas por socket. Apenas definido se o --ntasks por soquete opção
é especificado.

SLURM_PRIO_PROCESS
A prioridade de agendamento (valor legal) no momento do envio do trabalho. Este valor é
propagado para os processos gerados.

SLURM_PROCID
A classificação MPI (ou ID do processo relativo) do processo atual

SLURM_PROFILE
Igual a --perfil

SLURM_RESTART_COUNT
Se o trabalho foi reiniciado devido a uma falha do sistema ou foi explicitamente
enfileirado, isso será enviado para o número de vezes que o trabalho foi reiniciado.

SLURM_SUBMIT_DIR
O diretório do qual lote foi invocado.

SLURM_SUBMIT_HOST
O nome do host do computador a partir do qual lote foi invocado.

SLURM_TASKS_PER_NODE
Número de tarefas a serem iniciadas em cada nó. Os valores são separados por vírgulas e no
mesmo pedido que SLURM_NODELIST. Se dois ou mais nós consecutivos devem ter o
mesma contagem de tarefas, essa contagem é seguida por "(x #)", onde "#" é a repetição
contar. Por exemplo, "SLURM_TASKS_PER_NODE = 2 (x3), 1" indica que os três primeiros
cada um dos nós executará três tarefas e o quarto nó executará uma tarefa.

SLURM_TASK_PID
O ID do processo da tarefa que está sendo iniciada.

SLURM_TOPOLOGY_ADDR
Isso é definido apenas se o sistema tiver o plug-in de topologia / árvore configurado. o
valor será definido para os nomes de comutadores de rede que podem estar envolvidos no
comunicações de trabalho do interruptor de nível superior do sistema até o interruptor de folha
e terminando com o nome do nó. Um ponto é usado para separar cada componente de hardware
nome.

SLURM_TOPOLOGY_ADDR_PATTERN
Isso é definido apenas se o sistema tiver o plug-in de topologia / árvore configurado. o
valor será definido como tipos de componentes listados em SLURM_TOPOLOGY_ADDR. Cada
componente será identificado como "switch" ou "nó". Um ponto é usado para
separe cada tipo de componente de hardware.

EXEMPLOS

Especifique um script em lote por nome de arquivo na linha de comando. O script de lote especifica um 1
limite de tempo de minuto para o trabalho.

$ cat meuscript
#!/ Bin / sh
#SBATCH --time = 1
srun hostname | sort

$ sbatch -N4 meuscript
salloc: Alocação de trabalho concedida 65537

$ gato slurm-65537.out
host1
host2
host3
host4

Passe um script de lote para sbatch na entrada padrão:

$ sbatch -N4 <
> #!/ Bin / sh
> srun hostname | sort
> EOF
sbatch: Trabalho em lote enviado 65541

$ gato slurm-65541.out
host1
host2
host3
host4

COPIAR

Copyright (C) 2006-2007 The Regents of the University of California. Produzido em Lawrence
Laboratório Nacional de Livermore (cf, DISCLAIMER).
Copyright (C) 2008-2010 Lawrence Livermore Segurança Nacional.
Direitos autorais (C) 2010-2015 SchedMD LLC.

Este arquivo faz parte do Slurm, um programa de gerenciamento de recursos. Para detalhes, veja
<http://slurm.schedmd.com/>.

Slurm é um software livre; você pode redistribuí-lo e / ou modificá-lo nos termos do
GNU General Public License conforme publicada pela Free Software Foundation; qualquer uma das versões 2
da Licença ou (conforme sua opção) qualquer versão posterior.

Slurm é distribuído na esperança de que seja útil, mas SEM NENHUMA GARANTIA; sem
até mesmo a garantia implícita de COMERCIALIZAÇÃO ou ADEQUAÇÃO A UM DETERMINADO FIM. Veja o
GNU General Public License para mais detalhes.

Use sbatch online usando serviços onworks.net