Esta página discute as propostas de futuro para o ambiente TerraME. Ela foi dividida nos diversos temas abordados:

Novas versões do TerraME

Conceitos gerais sobre o TerraME

Novas funções em TerraME

Agentes em TerraME

Interface TerraView - TerraME

Gerencia do TerraME

1. A função CellularSpace:load poderia ter como parâmetros o tempo dos atributos, para carregar automaticamente os atributos dinâmicos em cada passo temporal do modelo.

2. A função CellularSpace:save poderia salvar os dados numa tabela temporal, para facilitar o controle de visualização. Isto seria acoplado com melhorias no TerraView para visualizar seqüências temporais.

   Comentários Tiago: 

1.1 Idealizei a função “load()” e “save()” para que carregassem e gravassem dados de acordo com o relógio de simulação, desta maneira o parâmetro “tempo” poderia ser dispensado. Entretano, uma versão onde o tempo é passado como parâmetro é desejável. Especialmente quando se deseja carregar ou gravar espaços celulares de instantes passados ou futuros. Veja o próximo comentário para entender porque isso ainda não foi feito.

1.2 No momento da implementação do primeiro driver para acesso a bancos TerraLib, as fucionalidades de manupulação de tabelas dinâmicas ainda se encontravam num estágio pré-amadurecimento, e vinham sofrendo constantes alterações em suas interfaces (em especial os serviços da família STO). Esse fato, tornava o desenvolvimento de TerraME improdutivo. Desta forma, optei por implementar o armazenamento e recuperação de dados sobre tabelas estáticas, que naquele momento eram mais estáveis. Desta maneira, é exigido que o programador crie “temas” específicos para cada data e carregue em separado. Atualmente, a função “save()” cria um novo “tema” na vista “result” a cada vez que é chamada, isto só acontece devido uso das tabelas estáticas.

1.3 Fica aqui uma pergunta: em que estágio de amadurecimento se encontra a API para manipulação de tabelas dinâmicas em TerraLib?

1. Permitir a visualização de uma tabela temporal com um barra de tempo para permitir animação (automática e manual).

   Comentários Tiago: 

1.1 Um cuidado especial deve ser tomando para a implementação desta funcionalidade: as legendas! Os limites máximos e mínimos de um determinado atributo da tabela dinâmica são diferentes para diferentes instantes do tempo. Portanto, da maneira que o TerraView calcula as legendas, estas teriam limites diferentes para cada instante de tempo, cores diferentes seriam associados a um mesmo valor, ou a mesma cor seria associada a valores distintos. Tal fato dificultaria sobremaneira a comparação visual de mapas de diferentes instantes de tempo.

1.2 Por exemplo, no modelo hidrologico de “Cabeça de Boi”, no primeiro instante a célula que acumulou a maior quantidade de água, possui o valor “2” em seu atributo “qteAgua”. A cor “azul escuro” é associada ao valor “2”. Entretanto, no instante “36” o maior acúmulo de água supera algumas dezenas, então a cor “azul escuro” é associado ao valor máximo do atributo “qtdeAgua” e ao valor “2” é associado a cor “azul claro” (clarissimo). Assim, como poderiamos comparar estes dois mapas visualmente?

1.3 Sugestão: O modelador tem codições de após análise do comportamento do modelo e da análise de sensibiliade do modelo a seus parâmetros, diagnosticar seu ponto de equilibrio, e determinar quais são os valores ideiais para os limites inferior e superior da legenda. Portanto, a interface TerraView deveria permitir que o seu usuário definisse estes valores, e os mesmos deveriam ser utilizados para todos os tempos.

   Comentários Miguel: 

1.1 - A estratégia até o momento pensada para as questões relativas a “preenchimento de BD Celular” é a constução de um Plug-in TerraView. Este trabalho foi iniciado , existe código pronto e precisa ser retomado e finalizado, o que deve acontecer este semestre. E está na agenda da reunião planejamento de TLib, dia 2 de março.

1.2 - Questões relativas a apresentação de dados temporais em TView precuisam ser vistas com mais cuidado. Nao existe somente o dado celular em TLib e para o TView. Assim uma solução que envolva o “query” e a apresentação de dados espaço-temporais armazanados em um banco TLib através do seu visualizador TView precisa observar mais requisitos que apenas aqueles que as “saidas”do TerraME necessitam. Ou seja, é bom pensar mais um pouco antes de sair oferecendo soluções em TView que acabam atendendo bem um “tipo” de dado geográfico,mas complica para o universo de usos de um software como TView. Estamos estudando isso, e o importante agora é determinar os requisitos de apresentação e visualização para os “Mundos Celulares” que devem entrar , com os outros requisitos derivados de dados de outra natureza, mas com dinâmicas representadas ( tempo) no projeto da apresentação em TView.

1. Precisamos de um período de experimentação interna (INPE, UFOP) para amadurecer bem os conceitos do TerraME, e acomodar eventuais mudanças. também será preciso gerar uma documentação com muitos exemplos.

2. Poderíamos pensar que uma versão protótipo do TerraME poderia ser lançada no final de Agosto. Para isto, precisaremos de dois eventos internos: (a) um seminário de apresentação dos diferentes projetos internos que usariam o TerraME (em Março) e (b) Um seminário de avaliação de seu uso (em Junho). Julho e Agosto seriam dedicados a escrever a documentação.

  Comentários do Tiago:

3. É urgente a experimentação da condição “situada” dos autômatos de TerraME. Alguns já notaram seu pontencial e até publicaram um artigo sobre “agentes situados & GIS” em uma conferência em Portugal. Porém, interpretaram de forma errada a teoria e o artigo assim com a conferência são fracos. Mas corremos o risco de nadar, nadar e morrer na praia por falta de experimentação e publicação.

   Comentários do Miguel:

1.1 - As ações gerenciais de TerraME t6em natureezas distintas e devem operar em paralelo. Há em curso um recurso e uma programação, com base em contrato na PUC-Tegraf e a ser executado pelo Lab na UFOP conosco para resolver questões básicas:

     I - Organização do código em sistema de controle de versão (CVS) na estrutura de TLib, com acesso durante este período restrito aos times do INPE e da UFOP. Responsáveis locais. INPE: Laércio, UFOP: Tiago.
    II - Acomodar a versão TerraME para estar em sincronismo com TLib. TLib tem versão 3.2 programada, antes da versã0 4.0, e TerraME deve seguir este versionamento. Precisamos ter um TerraME "estável" e um "desenvolvimento". Agora mesmo deveríamos ter o TerraMe estável que acompanha a versao 3.1.4 da TLib e com versao Linux e Windows.
   III - Consolidar o Lab da UFOP. Com os equipamentos e um documento, creio que um termo de compromisso, que o INPE pode fazer ( e tenho um modelo) que possa ser assinado pelo Diretor , aqui, e o Reitor, na UFOP.( Tiago verificar isso) 
   IV - Documentação BÁSICA de código (kernel) e exemplos. melhoria do materuial, dos bancos de exemplos, etc,e tc.
   V - Definicao do LIcenciamento de TerraME e de sua forma de distribuição.

1.2 - Há uma série de atividades no contrato que devem ser feitase que contempalam boa parte desta “estruturação”do TerraME como um projeto de sofwtare de ciclo aberto, precisamos construir isso ao longo deste ANO!

 Comentários do Miguel

1. Acho que TerraME é uma plataforma importante para tratar problemas cada vez mais complexos. Torná-la simples e de uso comum é um obejtivo, mas em paralelo, não devemos deixar de avançar. Além do ambiente de Agentes há uma linha que acredito de enorme potencial e pretendo trabalhar nela, que aliás envolve “agentes” também. Mas em um primeiro momento é como incorporar as informações de “Redes”, os fluxos, com as informações dos “Lugares”, os fixos, uma preocupação antiga nossa e já explorada, mas agora, conm chances reais de avançar.

2. O trabalho para observar é o EPISimS ( originado no Los Alamos Labs, e agora no http://ndssl.vbi.vt.edu/projects.html). Mas a idéia aqui é Simulação em Larga Escala integrando Redes Sociais (agentes) e Técnicas (infra-estrutura de trasportes, comunicação) operando no suporte “celular”( espaço) para compreender e simular eventos como uma Epidemia e sua difusão, considerando a “cidade” real e múltiplas escalas. O mesmo suporte e conceitos, nos permitiria explorar mobilidade em outros problemas.

3. Preocupações do Tiago , como a possibilidade do TerraME “escalar” para ambientes de computação de alto-desempenho JÁ são importantes, mesmo que ainda não tenhamos consolidado a fase 1. Se queremos modelos interessantes e simuladores eficientes vamos precisar de “power”. Para Los Alamos foi possível fazer o modelo para Portland e um modelo para Hong Kong.

4. Então TerraME é um grande ambiente para experimentar com novoas formas de representação e simulação integrada para os efeitos dos “fixos”e dos “fluxos”.

5. Há um espaço de cooperação grande com os grupos do PROCC-FIOCRUZ ( experiência em Modelagem e ambientes computacionais para tratar com “redes” - em Python EPIGRASS - Epidemiological Geo-Referenced Analysis and Simulation System. 2005.COELHO, F. C. ; CODEÇO, C. T. http://epigrass.sourceforge.net/ ) e com os grupos envolvidos nas questões de modelos climáticos em escala regional.

VER ARTIGOS:

SIAM News, Volume 37, Number 4, May 2004 The Mathematics of Networks Understanding Large-Scale Social and Infrastructure Networks: A Simulation-Based Approach Christopher L. Barrett, Stephen Eubank, V.S. Anil Kumar, and Madhav V. Marathe http://ndssl.vbi.vt.edu/Publications/largescalenetworks.pdf

Está disponível uma nova versão do TerraME. Ver o email do Tiago a respeito:

 Espero finalmente, ter corrigido os ultimos bugs do escalonador de eventos. 
 Certamente, esta é a parte mais complicada do código.
 Chamo a atenção para algumas mudanças:
       - O que antes se chamava "Environment" agora é chamado "Scale".
       - O que antes era chamado "SpatialIterator" agora se chama  "Trajectory".

 Corrigi erros apontados pelo Pedro:
       - A função "ForEachCell" que antes obrigava o retorno de um valor booleano, na nova versão, 
         torna o valor de retorno opcional. 
         Se a função recebida como parametro, quando avaliada sobre uma célula, não retornar 
         nada ou retornar o valor "true", fará com que o espaço celular continue 
         a ser percorrido. No entanto, se ela retornar o valor "false", 
         o percorrimento do espaço celular será interrompido.
       - A função "ForEachNeighbor" segue esta mesma lógica. Sempre que a 
         função recebida como parâmetro não retornar nada ou retornar "true", a 
         vizinhaça continuará a ser percorrida. Se ela retornar "false" o percorrimento é interrompido.
      - Me esqueci de corrigir a indexação das vizinhanças, elas ainda  começam no indice 0 (zero). 
        Só lembrei agora! Mas isso é fácil...

 Implementei novas funcionalidades solicitadas pelo Gilberto:
      - A função "ForEachCellPair(cs1,cs2, f(cell1, cell2))" recebe dois  espaços  celulares 
        como parâmetro e uma  função "f" que recebe duas células. 
        "cell1" pertence ao espaço celular "cs1" e "cell2" ao espaço celular "cs2". 
        Esta função segue a mesma lógica com relação ao valor de retorno da função "f". 
        Se retornar nada ou "true" os espaços celulares continuam a ser percorridos. 
        Caso contrário, o percorrimento é interrompido.