Corrigir data no arquivo ctl

[cfbastarz]

Os arquivos binários escritos pelo SCANTEC, são acompanhados de um arquivo descritor (.ctl) para que possam ser abertos pelo GrADS. O @Garcia-INPE identificou que todos os arquivos .ctl contém a mesma data na diretiva tdef. Esta data está hardwired na rotina scan_bstatistic.f90 (linhas 628, 656 e 683).

Além disso, a variável Analysis Time Step é utilizada nessa rotina para o cálculo do tdef (número de tempos de previsão) e, se a avaliação for feita dia a dia, essa variável - se não ajustada de forma correta, pode resultar em valores erradas de tdef.

Exemplo do problema:

Considerando os seguintes parâmetros no arquivo scantec.conf:

Starting Time: 2016071500
Ending Time:   2016071500
Analisys Time Step:  12
Forecast Time Step:  24
Forecast Total Time: 72
Time Step Type: backward
History Time:   48

Fará com que o SCANTEC escreva arquivos .ctl com o seguinte conteúdo:

tdef   7 linear 00Z05AUG2014 12HR

Quando o correto deveria ser:

tdef   4 linear 00Z15JUL2016 24HR

O problema ocorre porque a data 00Z05AUG2014 está hardwired na rotina scan_bstatistic.f90 e porque a conta realizada para calcular o tdef (scantec%forecast_time/scantec%atime_step)+1) utiliza o valor de Analisys Time Step: 12. Nesse caso, bastaria instruir para o usuário que substitua o valor de Analisys Time Step por 24, mas é necessário investigar uma forma de se evitar isso.

[cfbastarz]

No push b22c2a2d44841e3824b43e0f8acdec5bd901b847, foram inseridas as seguintes modificações na rotina scan_bstatistic.f90:

https://github.com/GAM-DIMNT-CPTEC/SCANTEC/blob/b22c2a2d44841e3824b43e0f8acdec5bd901b847/core/scan_bstatistic.f90#L614-L655

Essa modificação converte os valores das variáveis scantec%atime ou scantec%ftime (valores inteiros referentes às datas de análise ou previsão) para strings, as quais são utilizadas para gerar uma nova string utilizada como data de referência dentro do arquivo CTL do GrADS. Nessa mesma rotina, a nova data formata é utilizada na escrita da diretiva tdef dos arquivos CTL escritos. Exemplo:

https://github.com/GAM-DIMNT-CPTEC/SCANTEC/blob/b22c2a2d44841e3824b43e0f8acdec5bd901b847/core/scan_bstatistic.f90#L671-L672

Dessa forma, os arquivos CTL apresentam a data de referência correta, de acordo com os valores das variáveis scantec%atime ou scantec%ftime (atribuídas através das variáveis Starting Time ou Ending Time do namelist do SCANTEC). Apesar disso surge um problema prático quanto ao uso da opção Time Step Type (backward ou forward): quando Time Step Type: forward, pela lógica, a data de referência é a data da análise (atime) e os arquivos de previsão utilizados na avaliação, partem dessa data de referência. Por exemplo:

!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!
!                          Running scantec                            !
!     Please wait while the system is performing the statistics       !
!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!
Analisys   Forecast        fct
2020061000 2020061000        00h
2020061000 2020061100        24h
2020061000 2020061200        48h
2020061100 2020061100        00h
2020061100 2020061200        24h
2020061100 2020061300        48h

Por outro lado, quando a opção Time Step Type: backward (situação próxima à operacional, quando os modelos são avaliados "para trás"), pela lógica, a data de referência é a data de previsão (ftime) e os arquivos de previsão utilizados na avaliação, são a referência. Por exemplo:

!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!
!                          Running scantec                            !
!     Please wait while the system is performing the statistics       !
!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~!
Analisys   Forecast        fct
2020061000 2020061000        00h
2020060900 2020061000        24h
2020060800 2020061000        48h
2020061100 2020061100        00h
2020061000 2020061100        24h
2020060900 2020061100        48h

Independente do ajuste da opção Time Step Type, a diretiva tdef do GrADS apenas incrementa das datas para frente, ou seja, as datas são sempre somadas e nunca subtraídas. Com isso, surge a dificuldade de se representar a data no arquivo CTL do GrADS quando o SCANTEC é realizado com a opção Time Step Type: backward, pois a data de referência é a data de previsão (e as datas de análise são anteriores à essa data de referência, para as previsões de 24, 48, 72 horas etc) e, no arquivo CTL, a data inserida no arquivo CTL é a data de referência com incrementos somados (datas futuras) e não subtraídos (datas passadas). Então, considerando o exemplo de realização do SCANTEC com a opção Time Step Type: backward, os arquivos CTLs criados possuirão a diretiva tdef da seguinte forma:

tdef    3 linear 00Z10JUN2020  24HR

Com isso, no GrADS, t=1 será 00Z10JUN2020, t=2 será 00Z11JUN2020 e t=3 será 00Z12JUN2020 e estas datas não fazem referência aos arquivos utilizados na avaliação. Como resolver esse problema (@joaogerd e @Garcia-INPE)? O mínimo é esclarecer esse detalhe na documentação do SCANTEC.

[cfbastarz]

Conversando com o @joaogerd, podemos adotar a solução proposta para inserir a data correta no arquivo CTL, mas uma solução mais adequada (e.g., ao invés de se escrever arquivos binários, escrever arquivos no formato GRIB) deverá ser proposta para uma revisão maior do código. Dessa forma, a modificação proposta, deverá ser lançada na versão 2.1.0 do SCANTEC (https://github.com/GAM-DIMNT-CPTEC/SCANTEC/milestone/7).

[cfbastarz]

Realizando testes a partir da consolidação das modificações deste branch, foram identificados dois problemas:

1. O nome do mês 8 está abreviado como AGO, quando deveria ser AUG; isso faz com que o arquivo CTL não seja aberto. Os nomes dos outros meses também devem ser revisados;
2. Quando o testcase do modelo BAM é realizado, o arquivo CTL possui mais tempos de previsão do que a respectiva tabela, o que faz com que mais records sejam lidos pelo GrADS.

Esta issue será reaberta para que esses problemas possam ser corrigidos.

[cfbastarz]

O PR 3c36acc9e83200d79e79384928aeffeb6269176c corrige o nome da data do mês 8 na rotina scan_bstatistic.f90. Sobre a discrepância entre o número de linhas da tabela e o número de tempos no arquivos CTL, como já fora discutido, isso se deve à escolha do número de time steps da análise, que no caso do testcase do modelo BAM, está como 12 ao invés de 24. Isso já havia sido discutido no escopo desta issue, mas faltou alterar o script run_scantes.sh com esse valor.