.. _perguntas_frequentes: Perguntas Frequentes ==================== Esta Seção é voltada a responder a dúvidas frequentes dos usuários do GridUnesp. Em geral, são perguntas sobre acesso ao cluster, instalações de pacotes, processamento e acompanhamento dos jobs e falhas na execução das simulações. .. contents:: :depth: 3 Acesso ao GridUnesp ------------------- 1) Como obter ajuda para utilizar o GridUnesp? ++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Entre em contato com a equipe de especialistas do GridUnesp enviando mensagem para ``support.ncc@unesp.br``. Caso esteja com problemas em relação ao job (à simulação), envie na mensagem informações suficientes e adequadas para que a equipe de especialistas do GridUnesp consiga ter o melhor entendimento possível sobre a situação. Informe, por exemplo: * a localização do script de submissão e dos arquivos e pastas de input; * a localização dos arquivos de log (*slurm-jobID.out*); * o comando usado para submeter o job; * e, se possível, o(s) número(s) do(s) job(s) em questão. 2) Como faço login no GridUnesp? ++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Caso tenha um computador baseada em Unix (Linux, Mac), basta abrir um terminal e digitar .. code-block:: bash $ ssh username@access.grid.unesp.br em que **username** é o login de usuário que você escolheu no processo de cadastro. Caso seu computador tenha sistema operacional Windows, consulte a Seção :ref:`acessando_o_cluster`. .. warning:: Alguns usuários mais antigos talvez ainda tentem fazer login pelo servidor **access.grid.unesp.br**. Contudo, este servidor foi desligago permanentemente. Agora, o acesso ao cluster é através do servidor **access2.grid.unesp.br**. Para mais informações, consulte a Seção :ref:`acessando_o_cluster`. 3) Não lembro minha senha. Como faço para resetar? ++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Acesse a página https://ncc.unesp.br/password/ e informe o **username** ou e-mail cadastrado no GridUnesp. Um token para troca será enviado ao email cadastrado. É fundamental utilizar senhas consideradas fortes em que: * haja um mínimo de 8 caracteres; * não contenha uma simples palavra comum; * contenha letras minúsculas, maiúsculas, números e símbolos (!, $, %, @, #, ...). Importante lembrar que as senhas devem ser alteradas em intervalos regulares (e.g., a cada ano) e que as novas senhas não devem ser iguais ou simples derivações das senhas passadas. Também é possível utilizar geradores de senha aleatória: https://www.lastpass.com/features/password-generator 4) Ao tentar fazer login no GridUnesp, aparece "The authenticity of host 'access2.grid.unesp.br (200.145.46.48)' can't be established". O que isso significa? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Ao acessar o servidor **access2.grid.unesp.br** pela primeira vez, seu client de conexão segura irá perguntar se você a reconhece como uma máquina confiável. Você deve verificar se a chave é igual à exibida abaixo e confirmar, digitando **yes**: .. parsed-literal:: The authenticity of host 'access2.grid.unesp.br (200.145.46.48)' can't be established. RSA key fingerprint is SHA256:WVFokXOLnuH9+2e7xxRU2gp7XJqxwuE6H8bbUMqTCXo. Are you sure you want to continue connecting (yes/no)? 5) Ao tentar fazer login no GridUnesp, aparece "WARNING: POSSIBLE DNS SPOOFING DETECTED!"? O que isso significa? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle É possível que o usuário esteja há algum tempo sem fazer login no cluster do GridUnesp e, devido a mudanças na configuração do sistema como a modificação do servidor de acesso, poderá aparecer uma mensagem de erro com o seguinte conteúdo: .. parsed-literal:: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The ECDSA host key for access2.grid.unesp.br has changed, and the key for the corresponding IP address 200.145.46.48 is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:WVFokXOLnuH9+2e7xxRU2gp7XJqxwuE6H8bbUMqTCXo. Please contact your system administrator. Add correct host key in /home/username/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/username/.ssh/known_hosts:13 remove with: ssh-keygen -f "/home/username/.ssh/known_hosts" -R "access2.grid.unesp.br" ECDSA host key for access2.grid.unesp.br has changed and you have requested strict checking. Host key verification failed. Se o usuário está usando um computador Linux, bastar dar o seguinte comando: .. code-block:: bash $ ssh-keygen -f "/home/username/.ssh/known_hosts" -R "access2.grid.unesp.br" Estando o usuário utilizando um computador Mac, o comando é: .. code-block:: bash $ ssh-keygen -f "/Users/username/.ssh/known_hosts" -R "access2.grid.unesp.br" .. warning:: Note aque, aqui, **username** é o login do computador pessoal do usuário, e não o login de acesso ao GridUnesp. Finalmente, basta tentar acessar o cluster novamente, mas agora como o login do GridUnesp. Para mais informações, veja a Seção :ref:`confirmacao_de_seguranca`. 6) Por que não consigo fazer login? +++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Devido a alguma falha na internet, o usuário pode perder a conexão. Todavia, pode ocorrer do usuário estar errando a senha e, por isso, ter sido bloqueado pelo sistema **Fai2Ban**. Por questões de segurança, o sistema bloqueia o usuário (por 15 minutos) toda vez que: * erra a senha várias vezes; * usa o comando ``scp`` várias vezes em um curto espaço tempo; * ou faz login de vários terminais em um curto espaço de tempo. Para mais informações, veja a Seção :ref:`bloqueio_de_usuario`. 7) Estava conectado no GridUnesp e de repente o terminal travou. Por quê? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Devido a alguma falha na internet, o usuário pode perder a conexão. Todavia, pode ocorrer do usuário estar errando a senha e, por isso, ter sido bloqueado pelo sistema **Fai2Ban**. Por questões de segurança, o sistema bloqueia o usuário (por 15 minutos) toda vez que: * erra a senha várias vezes; * usa o comando ``scp`` várias vezes em um curto espaço tempo; * ou faz login de vários terminais em um curto espaço de tempo. Para mais informações, veja a Seção :ref:`bloqueio_de_usuario`. 8) Não sei o que fazer depois de acessar minha conta no GridUnesp. Pode me ajudar? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Em linhas gerais, a razão para um professor, pesquisador ou estudante ter acesso a uma infraestrutura de computação de alta performance (HPC) é poder aproveitar o poder computacional (grande capacidade de armazenamento e processamento de dados) e a comodidade de deixar um programa, software, aplicação executando por um longo período (dias talvez) sem ter que se preocupar com falta de energia, falha de internet, superaquecimento do computador ou memória limitada, por exemplo. O usuário iniciante pode começar procurando se informar sobre o uso do cluster através da documentação do GridUnesp https://ncc.unesp.br/gridunesp/docs/ Há vários exemplos de scripts de submssião de simulações e comandos a serem usados para monitorar o processamento, além de informações sobre o funcionamento do cluster e instruções necessárias para executar aplicações científicas na Seção :ref:`manual_do_usuario`. Necessitando de ajuda, o usuário sempre pode enviar mensagem para a lista de suporte (``support.ncc@unesp.br``). 9) É possível acessar o GridUnesp via browser? ++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Não. Apenas é possível acessar o GridUnesp via *SSH* pelo terminal. Transferência de arquivos ------------------------- 10) Como transfiro arquivos para minha conta do GridUnesp? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Supondo que um usuário queira transferir um arquivo chamado "test.data" para seu diretório ``/home/`` no GridUnesp. A partir do computador pessoal, caso utilize sistema Linux ou Mac, poderá dar o seguinte comando no terminal: .. code-block:: bash scp test.data username@access2.grid.unesp.br:/home/username/. em que *username* é o login do usuário escolhido durante do cadastro. Caso queira saber como fazer a transferência a partir de um computador pessoal com sistema operacional Windows, consulte a Seção :ref:`transferindo_arquivos`. 11) Como transfiro arquivos do GridUnesp para meu computador pessoal? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Supondo que um usuário queira transferir um arquivo chamado "test.data" da conta do GridUnesp (``/home/username/test.data``) para seu computador pessoal. A partir do computador pessoal, caso utilize sistema Linux ou Mac, poderá dar o seguinte comando no terminal: .. code-block:: bash scp username@access2.grid.unesp.br:/home/username/test.data . em que *username* é o login do usuário escolhido durante do cadastro. Observe o ponto (.) ao final do comando. Ele indica que o arquivo "test.data" deverá ser transferido para a pasta corrente no computador pessoal. Será solicitado informar a senha de acesso ao GridUnesp. Após digitar a senha e apertar o [Enter], o arquivo "test.data" será transferiado para o computador do usuário. Caso seja usuário de Windows, poderá usar um software como o `WinSCP `_ para fazer a transferência. Para mais informações, consulte a Seção :ref:`transferindo_arquivos`. Instalação de programas, softwares e bibliotecas ------------------------------------------------ 12) Estou tentando instalar um software, mas não tenho permissão de administrador. O que faço? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle O usuário do GriUnesp pode realizar instalação de aplicações científicas em seu próprio ``/home/``. Muitos dos programas e bibliotecas permitem que a instalação seja feita em diretórios/pastas diferentes daquelas normalmente usadas como ``/usr/``, ``/lib/``. No entanto, caso não faça as configurações necessárias, poderá obter mensagens de erro, como falta de permissão. Em todo caso, também é possível solicitar que a instalação seja feita pela equipe de suporte do GridUnesp. Para mais informações, consulte a Seção :ref:`instalando_aplicacoes`. 13) Como faço para instalar um software/aplicação/biblioteca no GridUnesp? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Muitas aplicações científicas, softwares e bibliotecas podem ser instaladas em locais diferentes, como no ``/home/`` do usuário. Basta fazer as devidas configurações durante a instalação. Algumas são facilmente instaladas usando o ambiente `Anaconda `_. Há casos em que a instalação é demasiada complexa, ou em que há o desejo de a aplicação/biblioteca ser disponibilizada para vários usuários. Neste caso, basta informar à equipe de especialistas do GridUnesp (``support.ncc@unesp.br``) a aplicação/biblioteca de interesse, bem como o link do site de referência contendo informações de como realizar a instalação. Para mais informações, consulte a Seção :ref:`instalando_aplicacoes`. Processamento de simulações --------------------------- 14) Posso processar simulações no meu /home do GridUnesp? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Depende. O servidor **access2.grid.unesp.br** não deve ser usado para executar simulações. Ele serve apenas como local de acesso à conta do usuário para preparar o ambiente e enviar as simulações para serem executadas nos *worker nodes* (nós de processamento). Todavia, pré e pós processamentos que demandem um curtíssimo tempo de execução e pouca memória podem ser executados no servidor **access2**. Ou seja, é uma EXCEÇÃO. Em todas as demais situações, os usuários devem preparar os scripts de submissão de jobs para que as simulações sejam executadas nos nós de processamento. Para mais informações, consulte a Seção :ref:`processando_simulacoes`. 15) Como executar simulações no GridUnesp? ++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle O usuário deve preparar o ambiente de trabalho com os arquivos de input necessários e construir um scripts de submissão de simulações (jobs) para processamento nos *worker nodes* (nós de processamento). Esse script (vamos chamar de "sumit_job.sh", por exemplo) é escrito em linguagem `Bash `_ e deve conter diretivas que podem ser lidos pelo escalonador de jobs (`Slurm `_). Para enviar um job para processamento, deve-se usar o comando .. code-block:: bash sbatch sumit_job.sh Para obter mais informações sobre como processar simulações no GridUnesp, consulte a Seção :ref:`processando_simulacoes`. Informações sobre construção de scripts e monitoramento de jobs estão na Seção :ref:`melhorando_o_script_de_submissao`. 16) Como eu crio um script de submissão de jobs? ++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Consulte as seções :ref:`processando_simulacoes` e :ref:`melhorando_o_script_de_submissao`. Nelas o usuários encontrará informações detalhadas e vários exemplos. Monitoramento dos Jobs ---------------------- 17) Por quanto tempo meu job pode ficar processando no GridUnesp? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle São de **30 dias** o tempo máximo de processamento de simulações. Para obter mais informações e saber como configurar o tempo máximo de processamento, consulte a seção :ref:`sistema_de_filas`. 18) Há quantas filas/particões no GridUnesp? ++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle O GridUnesp conta com 3 filas de jobs diferentes: * **short** (24 horas); * **medium** (7 dias); * **long** (30 dias). Uma vez atingido o limite de tempo solicitado para determinada simulação, caso o processamento ainda esteja em execução, o job será cancelado por **TIMEOUT**. Para obter mais informações e saber como configurar o tempo máximo de processamento, consulte a seção :ref:`sistema_de_filas`. 19) Como sei que meu job começou a processar? +++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Através do comando (em que *username* é o login do usuário) .. code-block:: bash squeue -u username é possível verificar se o job já está em processamento ou se ainda está pendente de recursos. Caso já esteja em execução, aparecerá **R** no *status*. Porém, caso a simulação ainda esteja esperando a liberação de recursos, aparecerá o *status* **PD**. À medida que os jobs já em execução forem finalizando, os recursos do cluster vão sendo liberados para aqueles em **PD**. Para obter mais informações, consulte a seção :ref:`monitorando_simulacoes`. 20) Por que meu job está demorando tanto para começar a processar? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Em geral, caso um job esteja demorando muito tempo para iniciar o processamento, é porque há outros jobs na fila que estão consumindo os recursos do cluster, não havendo ainda os recursos solicitados pela simulação do usuário. Para ver todos os jobs que estão em execução, o comando é .. code-block:: bash squeue -a Para saber o total de jobs na fila, o comando é .. code-block:: bash squeue -a | wc -l Para saber o total de jobs pendentes de recursos, o comando é .. code-block:: bash squeue -a | grep PD | wc -l Para saber a ordem de prioridade dos jobs pendentes de recursos, o comando é .. code-block:: bash squeue -o "%.18i %.9Q %.8j %.8u %.10V %.6D %R" --sort=-p,i --states=PD No entanto, pode ocorrer de haver alguma falha no script de submissão do job que acaba demandando por recursos impossíveis de ser atendidos pelo sistema. Assim, caso o usuário tenha solicitado 50000 CPUs, ou 60 dias de tempo máximo de processamento, por exemplo, o job ficará pendente indefinidamente. Para obter mais informações, consulte as seções :ref:`monitorando_simulacoes` e :ref:`politica_de_prioridade`. 21) Existe alguma previsão de quando meu job vai começar a processar? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Quando o usuário submete jobs para processamento, ele solicita um tempo máximo em que o job pode ficar processando. No entanto, o tempo exato de duração é um dado desconhecido pois depende de diversos fatores, como a latência na transferência e na leitura e na escrita de dados. Além disso, se, por qualquer razão que seja, um ou mais jobs venha(m) a falhar, os recursos em uso são imediatamente liberados para os jobs que se encontram pendentes na fila. Em suma, o tempo que um job irá esperar na fila para começar a processar depende de fatores não determinísticos. 22) Por que meus jobs não começaram a processar enquanto outros usuários tem tantos jobs em execução? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle O cluster do GridUnesp está configurado para não haver recursos *idle* (ociosos). Assim, em períodos em que os recursos do GridUnesp estão sendo bastante demandados, um job submetido que solicita 28 CPUs pode ter que ficar esperando por um tempo significativo na fila. Por outro lado, um job que seja submetido logo na sequência e que esteja solicitando apenas 2 CPUs acaba obtendo prioridade, conseguindo "passar na frente" daqueles que demandam mais recursos. O cálculo da prioridade de um job na fila leva em conta a política de `Fair Share `_, o que envolve fatores como: * tempo máximo de processamento, número de CPUs e número de nós demandados; * quantidade de membros no grupo do usuário; * quantidade total de recursos até então usados pelas simulações do usuário. Para obter mais informações, consulte as seções :ref:`politica_de_prioridade` e :ref:`otimizando_o_desempenho`. Falhas no processamentos ------------------------ 23) Meu job foi cancelado por TIMEOUT. O que isso significa? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Uma vez atingido o limite de tempo solicitado para determinada simulação, caso o processamento ainda esteja em execução, o job é cancelado por **TIMEOUT**. Para obter mais informações e saber como configurar o tempo máximo de processamento, consulte a seção :ref:`sistema_de_filas`. 24) Meu job foi cancelado por falta do INPUT. O que isso significa? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle O script ``job-nanny`` serve para evitar que as aplicações científicas façam leitura e escrita diretamente na partição ``/home/``, o que poderia levar a uma sobrecarga na rede devido à grande transferência de arquivos entre esta partição e os nós de processamento. Assim, o script ``job-nanny`` verifica obrigatoriamente parâmetros como **INPUT** e **OUTPUT**. Caso o usuário não especifique algum desses parâmetros no script de submissão, o job será cancelado. Para mais informações, consulte a seção :ref:`script_job_nanny`. 25) Meu job foi cancelado por falta do OUTPUT. O que isso significa? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle O script ``job-nanny`` serve para evitar que as aplicações científicas façam leitura e escrita diretamente na partição ``/home/``, o que poderia levar a uma sobrecarga na rede devido à grande transferência de arquivos entre esta partição e os nós de processamento. Assim, o script ``job-nanny`` verifica obrigatoriamente parâmetros como **INPUT** e **OUTPUT**. Caso o usuário não especifique algum desses parâmetros no script de submissão, o job será cancelado. Para mais informações, consulte a seção :ref:`script_job_nanny`. 26) Por que meu job falhou? +++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Muitas são as razões que podem levar uma simulação a falhar: * falta de arquivos de input; * falha no código do usuário; * falha no(s) arquivo(s) de input; * falha na declaração de variáveis de ambiente; * falha na compilação de executáveis e bibliotecas; * memória insuficiente para processamento da simulação; * atingimento do limite máximo de tempo de processamento solicitado etc. Em geral, a simples análise dos arquivos de log e/ou output ajudam a verificar a fonte do problema. O nome padrão dos arquivos de log no GridUnesp tem o formato **slurm-.out** em que **** é o número do job correspondente. Caso o usuário não consiga descobrir a origem do problema, pode enviar mensagem para a lista de suporte (``support.ncc@unesp.br``). Na mensagem devem constar informações suficientes e adequadas para que a equipe de especialistas do GridUnesp consiga ter o melhor entendimento possível sobre a situação. Informe, por exemplo,: * a localização do script de submissão e dos arquivos e/ou pastas de input; * a localização dos arquivos de log (*slurm-jobID.out*); * o comando usado para submeter o job; * e, se possível, o(s) número(s) do(s) job(s) em questão. Optimização das simulações -------------------------- 27) O que faço para o processamento do meu job ficar mais rápido? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle É possível aumentar a quantidade de memória utilizando os parâmetros * ``-c`` (CPUs por processo); * ``--mem`` (memória por nó, em MB); * ``--mem-per-cpu`` (memória por CPU, em MB). No entanto, dependendo do programa/aplicação, disponibilizar mais memória não necessariamente fará com que o processamento seja mais rápido. Deve-se analisar caso a caso. Ainda é possível dividir o processamento em várias tarefas (vários processos) utilizando o parâmetro ``-n``. Porém, isso só funciona se o programa/aplicação tiver sido desenvolvido para suportar a opção de :ref:`memoria_distribuida`. Para mais informações, consulte as seções :ref:`melhorando_o_script_de_submissao`, :ref:`memoria_compartilhada` e :ref:`memoria_distribuida`. 28) Quantas CPUs/threads posso solicitar para o meu job? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Cada um dos 56 nós de processamento conectados ao servidor **access2.grid.unesp.br** posssui 28 núcleos cada (com hyperthread ativado). Ou seja, são 56 CPUs por nó. Cada CPU tem 2 GB, totalizando 128 GB de memória RAM. Para mais informações, consulte a seção :ref:`cluster_do_gridunesp`. 29) Tem GPU no GridUnesp? +++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Não. A inclusão de GPU já consta nos planos do Núclo de Computação Científica da Unesp (NCC/Unesp) para as próximas aquisições de hardware, estando pendente de suporte financeiro/orçamentário. 30) Como faço para processar simulações com várias CPUs? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Basta informar (no script de submissão) a quantidade de CPUs desejada através do parâmetro ``-c``. Supondo que se deseja realizar o processamento de um job com 16 CPUs. Bata solicitar esses recursos no script de submissão: .. code-block:: bash #!/bin/bash #SBATCH -c 16 Para mais informações, consulte a seção :ref:`melhorando_o_script_de_submissao`. Talvez seja importante também consultar a seção :ref:`memoria_compartilhada`. 31) Como faço para processar jobs em paralelo? ++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle É possível usar o conceito de memória distribuída. Para isso, deve-se informar ao sistema (no script de submissão) a quantidade de processos através do parâmetro ``-n``, além de carregar o módulo da *Intel* .. code-block:: bash #!/bin/bash #SBATCH -n 4 module load intel/compilers/2017 module load intel/mpi/2017 ou carregar o módulo do *OpenMP* .. code-block:: bash #!/bin/bash #SBATCH -n 4 module load openmpi/4.0.1 Caso seja possível ao programa/aplicação correspondente, outra opção para processar jobs em paralelo seria utilizar o conceito de *job array*, o qual consiste em dividir o trabalho em vários trabalhos menores e executar várias simulações simultaneamente. Para mais informações, consulte as seções :ref:`melhorando_o_script_de_submissao`, :ref:`memoria_distribuida` e :ref:`job_array`. 32) Como faço para usar ferramentas MPI? ++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Deve-se informar ao sistema (no script de submissão) a quantidade de processos através do parâmetro ``-n``, além de carregar o módulo da *Intel*: .. code-block:: bash #!/bin/bash #SBATCH -n 4 module load intel/compilers/2017 module load intel/mpi/2017 Para mais informações, consulte a seção :ref:`memoria_distribuida`. 33) Como configurar determinada quantidade de nós de processamento? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Caso a simulação do usuário esteja preparadda para trabalhar com :ref:`memoria_distribuida`, é possível informar qual o número exato de nós de processamento (*worker nodes*) que deseja alocar. Isso é feito usando a opção ``-N`` do *SBATCH*. Veja a seção :ref:`melhorando_o_script_de_submissao`. Digamos que o usuário deseje espalhar 18 processos por 4 nós. Isso seria possível usando algo como: .. code-block:: bash #!/bin/bash #SBATCH -n 18 -N 4 module load intel/compilers/2017 module load intel/mpi/2017 Contudo, em algumas situações (como quando a fila de jobs está consideravelmente grande), pode ser mais interessante ao usuário não especificar uma quantidade exata de *worker nodes*, mas delimitar quantidades mínima e máxima, deixando a decisão para o escalonadador do sistema (`Slurm `_). Como exemplo, digamos que o usuário deseje espalhar 18 processos entre 2 e 4 nós. Isso poderia ser feito com o seguinte exemplo de script de submissão: .. code-block:: bash #!/bin/bash #SBATCH -n 18 -N 2-4 module load intel/compilers/2017 module load intel/mpi/2017 Quando apenas um único valor é especificado, o sistema identifica as quantidades mínima e máxima de nós como sendo as mesmas: ``-N 4``, por exemplo, é equivalente a ``-N 4-4``. 34) É possível enviar vários jobs de uma vez com um único comando sbatch? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Sim. Para isso, deve-se usar o conceito de *job array*, o qual consiste em dividir o trabalho em vários trabalhos menores e executar várias simulações simultaneamente. Ao informar uma sequência de valores ao parâmetro ``-array`` no script de submissão, o sistema identifica o job como sendo, na verdade, vários jobs distintos: .. code-block:: bash #!/bin/bash #SBATCH --array=1-7:2 Para mais informações, consulte a seção :ref:`job_array`. 35) Por que o processamento do meu job é mais rápido quando uso um único nó do que quando uso vários? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle De acordo com a maneira como o GridUnesp está configurado atualmente, algumas aplicações têm seu desempenho diminuído drasticamente caso utilize processos espalhados por vários nós. De acordo com o explicado na seção :ref:`informacao_sobre_o_storage`, ao solicitar vários worker nodes, o job utiliza a partição ``/store/``, a qual é um *file system* compartilhado entre os nós. Isso significa que poderá haver um problema de latência (demora na comunicação): os nós precisam realizar uma comunicação entre si, além do tempo de transferência de dados na rede e do tempo de leitura e escrita naquela partição. Por outro lado, utilzando processos que envolvam apenas 1 worker node, os dados são armazenados na partição ``/tmp/`` do nó, então a escrita e leitura é feita diretamente nesse disco, aumentando assim o desempenho do processamento. Contudo, cada caso é um caso, cada software é um software, e precisa testar para verificar em quais situações vale a pena concentrar o processamento em apenas um worker node ou não. Em alguns casos - principalmente em períodos em que o cluster está sendo bastante demandado e o tempo de espera para disponibilização de recursos é significativo - talvez valha a pena espalhar o processamento em vários nós, ainda que a aplicação tenha sua enficiência reduzida. Para mais informações, consulte a seção :ref:`otimizando_o_desempenho`. 36) O GridUnesp utiliza rede InfiniBand ou Ethernet? ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle O GridUnesp atualmente trabalha com rede *Ethernet*. Há alguns anos, o GridUnesp possuía uma rede *InfiniBand*, considerada bastante rápida e adequada a várias aplicações científicas. Esse equipamento, contudo, é muito caro, tornando inviável sua manutenção a longo prazo. Com o advento do upgrade do cluster em 2017/2018, a comunicação entre os nós de processamentos e com o storage passou a ser feita por uma rede *Ethernet* 40 GB/s. Boas práticas de uso -------------------- 37) Minha simulações têm arquivos muito grandes? Tem algum problema? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Para simulações que sejam processadas em apenas um *worker node* (nó de processamento), o sistema utiliza a partição ``/tmp/`` do próprio *woker node* para leitura e escrita de dados. Esse disco tem cerca de 120 GB, sendo utilizado por todas as simulações em processamento no nó. Assim, caso os arquivos/pastas de input e output do job somem apenas alguns gigabytes, não há problema algum para a normalidade operacional do sistema. Contudo, caso os inputs e outputs somem algumas dezenas de gigabytes, o usuário deve tomar o cuidado de "obrigar" o job a utilizar a partição ``/store/`` (em vez da ``/tmp/`` do nó). A partição ``/store/`` é um *file system* compartilhado entre os *worker nodes* e possui terabytes de espaço, sendo mais seguro em cenários cujos jobs demandem um espaço considerável de armazenamento. Para informar ao sistema que a simulação deve usar o ``/store/``, basta o usuário editar o script de submissão incluindo uma das linhas seguintes: .. code-block:: bash export LARGE_FILES="true" .. code-block:: bash export SHARED_FS="true" Caso o script de submissão demande expressamente mais de 1 nó (``-N 3``, por exemplo), a opção por usar a partição ``/store/`` é automática, não necessitando informar as linhas acima. Para mais informações sobre as partições, consulte as seções :ref:`informacao_sobre_o_storage` e :ref:`parametros_do_job_nanny`. 38) Como faço para usar o /store/ em vez do /tmp/? ++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Para informar ao sistema que a simulação deve usar o ``/store/``, basta o usuário editar o script de submissão incluindo uma das linhas seguintes: .. code-block:: bash export LARGE_FILES="true" .. code-block:: bash export SHARED_FS="true" Caso o script de submissão demande expressamente mais de 1 nó (``-N 3``, por exemplo), a opção por usar a partição ``/store/`` é automática, não necessitando informar as linhas acima. 39) Como faço para usar o /tmp/ em vez do /store/? ++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Para informar ao sistema que a simulação deve usar o ``/tmp/``, basta o usuário editar o script de submissão incluindo uma das linhas seguintes: .. code-block:: bash export LARGE_FILES="false" .. code-block:: bash export SHARED_FS="false" Caso o script de submissão demande expressamente mais de 1 nó (``-N 3``, por exemplo), a opção por usar a partição ``/store/`` é automática. Já quando o usuário demanda que a execução do job seja realizada utilizando vários processos através de memória distribuída (veja a seção :ref:`memoria_distribuida`), pode ocorrer do `Slurm `_ (o sistema escalonador de jobs) distribuir os processos em vários nós. Caso queira, o usuário pode forçar que o processamento seja feito em apenas 1 *worker node*. Para isso, basta usar ``-N 1``. 40) Posso deixar meus arquivos guardados no GridUnesp? ++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Em regra, não. Apenas arquivos e pastas necessários à realização de futuras simulações podem ser mantidas no cluster. Os recursos do GridUnesp são compartilhados por centenas de usuários e, dado que os recursos são finitos, deve-se evitar usar o espaço em disco como uma *cloud* pois, caso o armazenamento atinja 100% de uso, todo o sistema começa a falhar, afetando inclusive os jobs dos usuários. Além disso, em caso de falha irrecurperável, os dados podem ser perdidos. Para mais informações, consulte a seção :ref:`manutencao_dos_dados`. 41) Como faço para apagar arquivos da minha conta? ++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Utilize o comando ``rm``. Veja exemplos na seção :ref:`manutencao_dos_dados`. 42) Tem algo que eu possa fazer para contribuir para manter o GridUnesp em bom funcionamento? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Sim. *Compliance* é fundamental para a normalidade operacional de qualquer sistema e/ou instituição. E com o GridUnesp não é diferente. Os usuários cadastrados no GridUnesp devem seguir as normas da seção :ref:`boas_praticas` sobre as regras que envolvem compartilhamento, manutenção e processamento de dados, bem como devem sempre ser diligentes no cumprimento da Política de Uso do GridUnesp (veja a seção :ref:`politica_de_uso`). Outros tipos de dúvidas ----------------------- 43) O GridUnesp usa Ubuntu? +++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Não. O cluster utiliza distribuição *AlmaLinux* ( e não *Ubuntu*, como se poderia supor). Isso significa que, caso, em situações bastante excepcionais, seja necessário a equipe do GridUnesp fazer instalações na raiz do sistema, seria utilizado o comando ``yum install`` (em vez do ``apt-get install`` do *Ubuntu*). Anteriormente o cluster era baseado em Linux com distribuição *CentOS*. Felizmente a distribuição corrente (*AlmaLinux*) apresenta compatibilidade 1 para 1 com *CentOS*. Ou seja, todos os comandos que eram usados para *CentOS* funcionam igualmente para *AlmaLinux*. 44) Qual é o sistema operacional do GridUnesp? Linux ou Windows? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle O cluster está baseado em sistema operacional **Linux** com distribuição *AlmaLinux*. 45) É possível usar programs interativos no GridUnesp? ++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Sim. Digamos que um usuário chamado *Spock*, cujo login no GridUnesp seja **spock**, queira abrir o arquivo *submit_job.sh* com o editor *Nedit* a partir do ``/home/`` do servidor **acess2**. Esse programa permite opções interativas de edição. Primeiramente, teria que fazer login com a opção ``-X``: .. code-block:: bash ssh -X spock@access2.grid.unesp.br Depois, abriria o arquivo: .. code-block:: bash nedit submit_job.sh & .. attention:: Os jobs no GridUnesp são submetidos utilizando *batch mode* (script de submissão via linha de comando com ``sbatch``) em vez de ambientes gráficos. Além disso, não é recomendada a submissão de jobs em modo interativo. Todavia, é possível usar o comando ``salloc`` para jobs interativos em *batch mode*, desde que sejam usados apenas para teste de scripts de submissão e depuração de problemas nos programas ou aplicações científicas usados/as pelos usuários. Para entender como usar essa opção, o usuário pode consultar páginas como https://slurm.schedmd.com/salloc.html http://manpages.ubuntu.com/manpages/bionic/man1/salloc.1.html 46) Como abrir aplicações visuais no GridUnesp? +++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Digamos que um usuário chamado *Spock*, cujo login no GridUnesp seja **spock**, queira abrir o arquivo *submit_job.sh* com o editor *Nedit* a partir do ``/home/`` do servidor **acess2**. Esse programa permite opções interativas de edição. Primeiramente, teria que fazer login com a opção `-X``: .. code-block:: bash ssh -X spock@access2.grid.unesp.br Depois, abriria o arquivo: .. code-block:: bash nedit submit_job.sh & 47) Está difícil resolver o problema com minha simulação. Seria possível ter uma conversa por vídeo conferência? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. admonition:: Resposta :class: toggle Sim. Envie mensagem para a lista de suporte (``support.ncc@unesp.br``) explicando suncitamente o problema. Uma pessoa do time de especialistas do GridUnesp analisará o caso e, dependendo do cenário, ele irá retornar o contato propondo uma solução ou marcando uma conversa por vídeo conferência em dia e hora a serem combinados.