MCSTU

Com relação ao item 5.13, entendo que deveria sempre ser possível estruturar o código de maneira que múltiplos formatos de entrada e saída fossem possíveis, mediante injeção de dependências. A questão passaria a ser se NetCDF deveria ser o default e o único obrigatório de ser suportado pela implementação.

Bom. Essa é uma discussão que precisamos ter também com os meteorologistas. O Padrão da OMM é grib. Mas não prevê novas variáveis que tem sido incorporadas nos modelos. Coisas do clima espacial, química, windfarms, biologia, aerossóis, etc não estão previstas. Vejo 3 possibilidades:
1) Usar o default com netCDF e usar um software conversor posteriormente;
2) Usar o default com Grib2 e forçar variáveis fora do padrão OMM dentro;
3) Deixar que a interface de entrada e saída seja programável para qualquer formato (deve ter um custo adicional)
Mas, antes de tudo, uma boa conversar com os meteorologistas e pessoal operacional ajuda.

Luiz Flávio,

Ok com relação aos teus comentários.

Acredito que os itens 4.23, 5.11 e 5.13 possam ser abertos à discussão.

O item 5.11 já levanta uma discussão relacionado ao tópico Refatoração. Eu entendo a necessidade, e concordo com que está alí. Mas é algo bem difícil de se fazer na prática, principalmente quando pensamos na maioria das pessoas que deverão trabalhar no código. Muitos não irão fazer isso, pois estarão focados em uma parte pequena do código e muitas vezes não estarão preocupados necessariamente com isso.
Eu vejo o código do MCSTU dividido em partes bem distintas, separadas em níveis partindo de algo mais abstrato e chegando na ponta onde o usuário (pode ser aluno ou pesquisador) faria sua inclusão de melhoria ou algum metodo novo. Nesta última camada não consigo enchegar muito a refatoração, até porque as vezes o que se quer é ver se a metorologia funciona. Já nas camadas mais abaixo sim, alí a coisa tem que estar bem codificada dentro dos padrões e, no caso de código externo, ser refatorado se for necessário.

Tadeu,

Acredito que o código deveria comportar múltiplos formatos de entrada, visto que os dados utilizados nos modelos, em geral, são provenientes de diferentes fontes. Por outro lado, a saída acredito que seria melhor em um único formato. No geral é sempre mais fácil ler do que escrever nesses formatos.

Luiz Flávo, no caso do grib tem esse inconveniente das tabelas mesmo, no entanto, cada centro possui a sua, caso contrário usa o padrão WMO. O ECMWF, por exemplo, tem várias tabelas e não estão necessariamente em conformidade com a WMO. No caso do CPTEC há uma tabela específica, mas não sei quando foi criada e se há algum tipo de manuntenção. Eu ainda penso fortemente nessa questão de compressão do GRIB como sendo uma vantagem.

João.

Vc tem razão. A refatoração é algo bem difícil de se fazer. Por isso não é feita! Entretanto os softwares de sucesso só o são porque tem um padrão seguido a risca. Como disse, quando trabalhei com a MECB I, os protocolos só andavam se estivessem dentro do padrão. Por isso o satélite que era para durar dois anos em 1991 funciona até hoje. Permite trabalhar com clareza e segurança no código.

Para mim está claro que precisaremos de mão de obra. Qualificada, bem paga e dedicada. Para isso espera-se que o MCSTU seja um programa de governo. Isso vai trazer recursos, bolsas e gente.

Outra coisa importante: ao usar ferramentas adequadas boa parte da refatoração fica automática. Ajuda e acelera o processo. Precisamos treinar a equipe em usá-las. O Eclipe Photran por exemplo refatora muita coisa. E também podemos por gente para pegar um editor e colocar as refatoração nele.

Não acredito que evoluiremos se o código não seguir essa regra restritiva, mas necessária. Estou só argumentando e espero contra argumentos, ideias e considerações. Posso estar enganado em alguns pontos e trocar informações ajuda bastante.

Pessoal.

Ontem na palestra da NVIDIA (assisti depois), quando perguntado sobre fatoração - item 5.11 de nosso padrão, o Dr. Kumar disse que alteraram o mínimo possível porque os pesquisadores querem ver o mesmo código (ou algo do tipo). Esse é um fato verdadeiro que precisamos nos atentar. Quando eu alterei o ETA em 1999/2000 e apresentei para a Chou a reação foi essa mesmo. O código não era mais o mesmo e perderam-se as referências da pesquisadora internamente. Com a otimização o código passou de 2h40 para 0h20 a rodada, mas acabou sendo abandonado em pesquisa (ficou em operação). Não sei muito como lidar com isso e precisamos colocar isso em pauta. Será que encontramos uma maneira de conciliar as duas coisas?

Com relação à questão "refatoração X ossificação" do código, eu entendo que a resposta está no versionamento de componentes, não no sentido do git, mas no sentido de que a definição de boas interfaces permite-nos substituir componentes por outros segundo algum critério de interesse: no exemplo citado do ETA, uma boa interface permitiria que os componentes original e otimizado pudessem coexistir em diferentes implantações do sistema. O problema (muito comum) é quando as interfaces são alteradas pela refatoração. Dada a experiência do grupo no desenvolvimento desse tipo de sistema, acredito que um esforço prévio de definição de interfaces pode ajudar a reduzir a complexidade do problema.

Flávio, Luiz escreveu:

Pessoal.

Ontem na palestra da NVIDIA (assisti depois), quando perguntado sobre fatoração - item 5.11 de nosso padrão, o Dr. Kumar disse que alteraram o mínimo possível porque os pesquisadores querem ver o mesmo código (ou algo do tipo). Esse é um fato verdadeiro que precisamos nos atentar. Quando eu alterei o ETA em 1999/2000 e apresentei para a Chou a reação foi essa mesmo. O código não era mais o mesmo e perderam-se as referências da pesquisadora internamente. Com a otimização o código passou de 2h40 para 0h20 a rodada, mas acabou sendo abandonado em pesquisa (ficou em operação). Não sei muito como lidar com isso e precisamos colocar isso em pauta. Será que encontramos uma maneira de conciliar as duas coisas?

Oi, Luiz Flávio.

Importante esta questão que abordas aqui. Não deve ser simples encontrar uma solução que concilie refatoração para melhoria do código e do seu desempenho, mantendo-o compreensível para quem o desenvolveu originalmente, caso muitas mudanças tenham que ser implementadas.

Gomes, Antonio Tadeu escreveu:

Com relação à questão "refatoração X ossificação" do código, eu entendo que a resposta está no versionamento de componentes, não no sentido do git, mas no sentido de que a definição de boas interfaces permite-nos substituir componentes por outros segundo algum critério de interesse: no exemplo citado do ETA, uma boa interface permitiria que os componentes original e otimizado pudessem coexistir em diferentes implantações do sistema. O problema (muito comum) é quando as interfaces são alteradas pela refatoração. Dada a experiência do grupo no desenvolvimento desse tipo de sistema, acredito que um esforço prévio de definição de interfaces pode ajudar a reduzir a complexidade do problema.

Muito bom, Tadeu.
Acho que você abordou a questão de maneira que ajuda a ter uma ideia de como podemos lidar com este ponto quando tivermos que realizar a refatoração do código.

Luiz Flávio,

tu tocou no ponto fundamental para o desenvolvimento do MCSTU. Como fazer um código eficiente, confiável e ainda "legível" por todos? O exemplo do Eta é bastante ilustrativo do que iremos enfrentar e nos mostra que é um ponto que devemos discutir bastante antes de dar os primeiros passos.

Acredito que essa dúvida não é somente nossa, mas de todos os que trabalham com o meio acadêmico e operacional juntos. Precisamos ao mesmo tempo ter um código eficiente, pois temos "clientes" que esperam um produto dentro do tempo, um código confiável, pois o produto deve possuir o melhor resultado possível (e sem falhas). Por outro lado, há a necessidade de constante desenvolvimento, aprimorar metodologias, sempre buscar melhorias nos resultados, aqui é onde entra a pesquisa e o com certeza o calcanhar de aquiles do MCSTU. Se o código não for legível o suficiente, com o tempo não será mais adotado, assim como foi no caso do Eta. Nesse caso específico do Eta, claramente tinha-se um código eficiente (certamente confiável), mas não era mais "legível". O que mostra um "desbalanceamento" entre esses três pontos. Devemos encontrar um meio termo, o que não é uma tarefa fácil.

Seria interessante olhar o que é feito no JEDI (aqui tem um overview da metodologia). A idéia é separar o código por tópicos e lidar separadamente com cada um deles utilizando conceitos modernos de desenvolvimento de software (tal como orientação à objeto).

Outro software que foi pelo mesmo caminho é o Land Information System (LIS), mas isso lá em 2004. Aqui seguiram também a idéia de orientação à objeto, o código foi separado em camadas. Criaram uma infraestutura que lida, por exemplo, com o paralelismo de tal forma que seja transparente ao usuário (no nosso caso o pesquisador). No LIS o usuário fica somente preocupado em "plugar" o código do modelo de interesse dele (seguindo um template) de tal forma que o modelo de superfície plugado (sem alteração prévia) usa toda a infraestutura do framework do LIS (paralelismo, IO e etc), e o pesquisador não precisa ter conhecimento sobre HPC, por exemplo, para ter o modelo dele dentro da estrutura. Assim ele (o pesquisador) foca somente no problema que ele entende e necessita resolver, usando o código que conhece, mas tira vantagem da infraestrutura que foi desenvovida para o LIS. Na época (2004) a orientação à objeto em fortran ainda não estava consolidada, então algumas coisas foram escritas em C (naquele caso lembro que usavam, por exemplo, algo como generic type bound function emulada em C).

Penso que deveríamos discutir algo no mesmo sentido do JEDI e LIS, em que se separa o problema em partes, com uma infraestrutura que controla o sistema e o usuário não precisa se preocupar como aquilo alí funciona para poder colocar seu código no sistema.