Documento com Perguntas e Respostas (PER)

RFI 02/2022

Esse documento contém as perguntas recebidas pelo comitê de compras do novo sistema de supercomputação do INPE e as respostas a cada pergunta. Os autores não são mencionados.

Para efeito de configuração, será permitido que o sistema seja configurado com nós híbridos?

Sim. Os sistemas ofertados podem ser configurados com nós híbridos. Por exemplo: CPU+GPU, CPU+FPGA, CPU+GPU+Vetorial, etc. Os sistemas devem ser acessados como um único sistema e atender aos requisitos mínimos dessa RFI.
O que é considerado "janela temporal de 2 horas" para a rodada dos modelos?

A janela temporal máxima de duas horas é o tempo máximo que a máquina pode gastar para processar simultâneamente as 20 instâncias de MOD1 e as 4 instâncias de MOD2. Ou seja, todos os wall times devem terminar antes do prazo de 2h. Abaixo vemos um diagrama exemplo on ti é o tempo inicial de submissão dos jobs e tf=ti+2h.

O Modelo BRAMS está apresentando problemas para acessar alguns arquivos de configuração apontados por links simbólicos. Como devo proceder?

Muitos sistemas não permitem que links simbólicos (criados pelo comando ln) sejam usados para acessar arquivos. Substitua os links simbólicos por links diretos com o caminho completo do arquivo.
No documento 'ComoRodarBenchmarkMOD1-BRAMS.html' não aparecem os links para os arquivos necessários em "Baixando os dados". Pode verificar?

O documento com as correções foi publicado na página.
Pede-se que sejam executadas 20 instâncias do modelo BRAMS 6.0 e 4 instâncias do modelo MPAS nas configurações definidas no documento. É possível se rodar 1 instância de cada modelo e fazer uma extrapolação para o número final de instâncias?

Sim. O fabricante ou fornecedor pode rodar apenas uma instância do modelo e inferir as arquiteturas, número de nós computacionais e demais necessidades baseadas na extrapolação para N instâncias. Contudo há que se garantir que ao rodar as N instâncias não aconteçam gargalos de rede ou I/O que possam prejudicar ou comprometer a janela de simulação (2 horas). Numa eventual e futura concorrência a empresa vencedora do certame deverá mostrar todas as instâncias sendo executadas no sistema.
Essa RFI garante que o INPE realize a compra do sistema conforme a especificação do fabricante ou o INPE pode mudar os requisitos?

O INPE não garante que a concorrência será igual ou totalmente baseada nessa RFI, nos mesmos requisitos, moldes e características solicitadas. O INPE se reserva ao direito de alterar as especificações dos sistemas, benchmarks ou do número de instâncias dos modelos dependendo das respostas a essa consulta e de diversos fatores de interese da instituição.
É possivel fazer testes com processadores ARM e apresentar a solução baseada nesses processadores?

Sim. O fabricante ou fornecedor pode usar qualquer processador que julgar necessário desde que atenda aos requisitos da consulta pública. Também é falcultado ao fabricante ou fornecedor usar qualquer arquitetura computacional de seu interesse para o atendimento da solução.
Na seção referente ao Benchmark item B) MOD2: Modelo MPAS esta escrito como previsão de 10 (dez) dias. Porem no arquivo disponível no site https://rfi_sc.inpe.br/ComoRodarBenchmarkMOD2-MPAS.html) esta escrito ADVANCEDcomo previsão de 5 (cinco) dias. Qual o valor de previsão devemos seguir?

O número de dias correto é 5 (cinco) e o termos será corrigido no documento citado.
Gostariamos de solicitar o suporte dos senhores em uma questão em relação a rodada do BRAMS: O output da rodada apresenta os arquivos solicitados no RAMSIM, e ele lista quatro arquivos com um caminho direto do BeeGFS [/mnt/beegfs/luiz.rodrigues]. Os arquivos sao:
```
BRAMS-8km-IAU1-IBC.bin
rad_param.data
infMapAOT.vfm
jules.in
```
Poderiam nos fornecer esses arquivos por favor?

Esses arquivos fazem parte do RAMSIN_ADVANCED. Editem esse arquivo com o editor de sua preferência e, em primeiro lugar, procedam com a substituição das seguintes linhas:
```
   MAPAOTFILE = '/mnt/beegfs/luiz.rodrigues/bin/tables/rad_carma/infMapAOT.vfm',
   JULESIN = '/mnt/beegfs/luiz.rodrigues/bin/jules.in',
```
por
```
   MAPAOTFILE = './tables/rad_carma/infMapAOT.vfm',
   JULESIN = './jules.in',
```
, também substituam a linha
```
   FILENAMEIAU = '/mnt/beegfs/luiz.rodrigues/bin/dataout/IAU_tendencies/BRAMS-8km-IAU1-IBC.bin',  ! prefix of the file to store the IAU's tendencies'
```
por
```
   FILENAMEIAU = '',  ! prefix of the file to store the IAU's tendencies'
```
e façam ainda a substituição da linha
```
RADDATFN  = '/mnt/beegfs/luiz.rodrigues/bin/tables/rad_carma/rad_param.data',
```
por
```
RADDATFN  = './tables/rad_carma/rad_param.data',
```
por fim baixem o arquivo jules.in (clique no link) e descompactem no diretório onde se efetuará a execução do modelo. Este arquivo compactado contém o Jules.in.
solicito um arquivo para os benchmarks do INPE, poderiam enviar o arquivo stream_list.atmosphere.diagnostics ?

No documento Como rodar o MOD2, logo abaixo do parágrafo "Obtenção do benchmark", pede-se que executem os seguintes comandos:
```
wget https://www2.mmm.ucar.edu/projects/mpas/benchmark/v6.x/MPAS-A_benchmark_10km_L56.tar.gz
tar -zxvf MPAS-A_benchmark_10km_L56.tar.gz
cd MPAS-A_benchmark_10km_L56
ls -A1
```
O arquivo baixado pelo comando wget e posteriormente descompactado contém o arquivo stream_list.atmosphere.diagnostics solicitado e vários outros necessários para a execução do benchmark.
Os parâmetros disponíveis no arquivo stream_list.atmosphere.diagnostics podem ser alterados para fins de otimização? Sim, mas não podem comprometer o funcionamento do código ou os resultados. As escolhas das parametrizações físicas não podem ser alteradas.
O INPE sugere parâmetros específicos em substituição aos parâmetros disponíveis no arquivo stream_list.atmosphere.diagnostics? Não. O INPE deixa a cargo das concorrentes alterações para melhorias de performance. Mas não permite que se altere a física do modelo.
Poderiam fornecer um detalhamento adicional sobre como alterar o input para testes com um numero diferente de 8 compute nodes?

Acredita-se que a pergunta se refere ao BRAMS. Não ha necessidade de alteração do input para alterações do número de nós computacionais. Atente-se apenas ao detalhe que, devido a implementação MPI, número excessivo de nós computacionais podem apresentar problemas que serão reportados nas saídas de log e out do modelo.
É possível se compartilhar os seguintes logs de referência: jules.log, brams.log e 20216051500_ini.out?

Os arquivos com extensão "log" e "out" são saídas dos modelos. Servem para verificar o funcionamento correto do mesmo. Não serão fornecidos pelo INPE
O output file gera muitos arquivos .ctl e .gra, qual dos arquivos deve ser utilizado para validação? É possível compartilhar o grads scripts?

Todas as saídas "gra" e "ctl" são de interesse. Contém as saídas meteorológicas do modelo. O Arquivo ctl é um descritor do arquivo binário (.gra). Todas as saídas serão usadas para comparação de resultados. Essa comparação será realizada como objeto da concorrência. Não da RFI. A confecção de um script em grads para comparação ou o uso de outra ferramenta com o mesmo intuito, nessa fase do processo, é responsabilidade do fabricante/fornecedor. Atente o fabricante/fornecedor que as otimizações não podem comprometer os resultados.
Durante os testes notamos o aparecimento de inúmeros avisos no log: “cfl_max_sum has exceeded 90% of the max. allowed value!” Gostaríamos de confirmação se os logs gerados no Instituto confirmam os mesmos avisos? É possível compartilhar os logs?

Esses avisos de excesso no CFL podem acontecer. Indicam que existe certa instabilidade numérica em algum(uns) ponto(s) causada por diversos fatores. Esses fatores são originários de diversas fontes, desde topografias com grandes "degraus" de altura, excesso de ventos nas bordas do modelo, variações específicas nos dados de entrada e algumas características da arquitetura do computador e de excesso de otimização na compilação. Em geral o modelo tenta tratar os erros e continua sem problema. Só deve ser motivo de preocupação se o modelo instabilizar e causar algum erro catastrófico (fatal error). Nesse caso sugerimos que se edite o RAMSIN_BASIC e altere o valor da variável DTLONG para um valor menor e múltiplo de 3600 seg (20, 30, 45).

Nota: Quanto menor o valor de DTLONG mais lenta será a execução.
Rodando o BRAMS com os arquivos fornecidos sem nenhuma mudança obtivemos o resultado para 9 dias e não 8 dias conforme especificado na RFI.

De 15/05/2022 à 23/05/2022

Start at 2022 may 15 - 0000h: brams-ams8km-A-2022-05-15-000000-g1.gra

Ends at 2022 may 24 - 0000h: brams-ams8km-A-2022-05-24-000000-g1.gra

Poderiam confirmar se isso esta correto ou devemos baixar um dia de previsão ? Onde e como devemos mudar para ter apenas 8 dias de previsão ?

*Por favor, alterem no RAMSIN_BASIC o campo TIMMAX para 192 (esse tempo é ajustado horas segundo apontado em TIMEUNIT). Com isso o modelo irá terminar no tempo adequado.
A versão 6.0 do BRAMS, obtida no github, quando rodada, gera no final de seus logs a indicação de uma versão diferente, a "5.4". Podemos considerar isso como normal?

Sim. O print está desatualizado.
Os arquivos CTL para validação dos resultados, fornecidos no benchmark, tem diferentes valores para xdef e ydef. Nós devemos modificar esses valores como os fornecidos nos arquivos de benchmark ou vocês podem sugerir alguma modificação no namelist?

Os valores apresentados são ligeiramente diferentes e não comprometem a apresentação dos resultados gráficos no grads. Mantenha-os como produzidos.
Ao checar a variabilidade dos resultados de 8 dias de simulação do BRAMS, observamos que as últimas 5 horas de simulação são sempre diferentes. O mesmo acontece em rodadas de 8 ou 9 dias. Essa diferença nas últimas 5 horas de simulação são esperadas pelo código do BRAMS?

Variabilidades são esperadas dependendo de diversos fatores, entre eles o do grau de otimização, vetorização ou paralelismo aplicado. As diferenças serão avaliadas quando da apresentação dos resultados. Caso seja de interesse, a empresa poderá mandar as figuras com as diferenças para averiguação prévia e parecer sobre os resultados.
Segundo a RFI observa-se que: 3) O SC deve conter uma camada de discos rápidos com sistemas paralelos, que permitam a execução dos benchmarks propostos na janela máxima especificada no ítem (1). 3.1) O volume líquido desses discos rápidos deve ser de, no mínimo, 2,5 PB. Nesses ítens não está claro o que é considerado "discos rápidos", se é do tipo HDDs ou SSDs, ou se refere a interface SAS ou SATA, ou se são discos NVMe.

Conforme especificado na própria sentença do item (3), trata-se da solução completa de discos com suas interfaces, hardwares e acessórios, que permitam a produção de resultados e a entrada de dados para os dois benchmarks (MOD1 e MOD2), nas 20 instâncias do BRAMS e 4 instâncias do MPAS , todas rodando simultâneamente, sem gargalos de I/O, sem intertravamento, dentro da janela especificada de 2 horas. O tipo do disco, sua velocidade, suas interfaces e toda a solução ficam a cargo da proponente cuja proposta deve atender a esses requisitos.