MCSTU

Para efeito de tratar separadamente a unidade do sistema como um todo (modelo), seria adequado termos versionamento separados para os grandes módulos do modelo (radiação, advecção, turbulência, microfísica, dinâmica) e de um integrador dos módulos? Qual o impacto que teríamos nessa abordagem? Algum comentário ou ideia?

Olá Luiz Flávio,

Acredito que os outros colegas já deram algumas respostas por email, mas acho importante tentar fazer alguns cometários, mesmo não sendo do meu domínio. O que estamos mais acostumados a fazer, é lidar com o versionamento dos modelos como um todo, ou seja, eg., BAM V1.1.3. Nesse caso, as principais componentes do modelo (pré-processamento, modelo e pós-processamento) possuem todos as mesmas versões. Mas esta é uma visão muito simplificada da organização e versionamento do projeto. Ainda sim, é melhor do que nada. Por outro lado, quanto tem-se o versionamento "atomizado", pensando nas versões de cada componente, é mais fácil identificar, eg., o que cada componente contém. No caso do modelo global, sabemos que processos adicionais são adicionados à medida em que o modelo evolui. Isso nos força a mapear o que é adicionado e descontinuado apenas olhando para a versão de distribuição do modelo, o que não é bom. Denis, Eduardo e Bárbara estabeleceram uma versão para o pré-processamento (com testes funcionais) a qual sabemos integrar versões específicas do modelo. Isso é o que faz mais sentido e está de acordo com o que você está propondo. Mas, ainda sim, a depender da quantidade de bibliotecas e módulos a serem utilizados no projeto do MCSTU, pode ser realmente trabalhoso mapear todas as versões. Nesse momento é possível fazer uma estimativa de quantas componentes (incluindo modódulos e bibliotecas) serão consideradas em uma versão inicial do MCSTU?

Como sugestão, eu acho interessante fazer o planejamento das versões do MCSTU, com um roadmap. Nesse sentido, devemos discutir o que cada versão maior deve ter. Por exemplo:

• MCSTU 0.0.0: versão determinística da componente atmosférica com núcleo dinâmico escolhido e pacote de parametrizações físicas básico para simulações e testes iniciais em resolução espacial mais grosseira;
• MCSTU 0.0.Z: correções de bugs da versões 0.0.0;
• MCSTU 0.Y.0: primeira revisão intermediária do MCSTU, com uma nova característica ou funcionalidade, por exemplo, o mesmo que a versão 0.0.0, mas com o acoplamento de com alguma outra componente do sistema terrestre, ou com assimilação de dados variacional;
• MCSTU X.0.0: primeira grande revisão do MCSTU, com as componentes consolidadas e uma release inicial pública.

Se um planejamento por versões for feito, acredito que ficará mais fácil enxergarmos como os testes deverão ser e como poderemos fazê-los. Em síntese, podemos pensar nestes testes à medida em que as novas características e funcionalidades do modelo estiverem planejadas em aptas para serem aplicadas. Faz sentido?

Abs.

Carlos

Oi Carlos.

Sim. Concordo com você. Podemos fazer esse controle prévio do que esperamos em cada "release" do modelo. Quanto a essas unidades não seria algo tão "atômico" assim. Penso em grandes grupos de rotinas (encapsuladas sob um pacote, diretório ou coisa do tipo), módulos inteiros, etc. Vou citar aqui alguns exemplos tirados do BRAMS (podia ser de qualquer modelo):

1. Radiação RRTMG
2. Microfísica de Greg-Thompson
3. Turbulência MY
4. Convecção Grell-Freitas
5. Advecção Monotônica de Walcek
6. Advecção de Runge-Kupta
7. Química e transporte CCATT
8. Superfície JUles
9. utilities ***
etc

Cada um teria uma versão que ia evoluindo e seria passível de um teste unitário (stand-alone). O modelo costuraria as diversas unidades versionadas e essa combinação gera uma versão do modelo. Isso facilita o trabalho dos grupos que cuidariam de cada unidade. Eles podem se concentrar na sua unidade e testá-la. Também uma refatoração seria mais simples pois as unidades são menores.

**Uma coisa importante sobre a atomização da *utilities. As partes (procedures) que podem ser testadas em separado também podem ser atomizadas e prontas para reutilização. Por exemplo: imagine uma função que faça a solução de uma matriz esparsa. Esta pode ser acrescentada a uma unidade especial (utilities) que contém essas funções genéricas. As funções e subrotinas genéricas de uso comum são distribuídas em um módulo utilities cujas partes podem ser testadas em separado.

Com tudo isso não perdemos a "mão" do desenvolvimento e deixamos mais simples para muita gente interagir.