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

Conceitos gerais sobre o TerraME

Novas funções em TerraME

Agentes em TerraME

Interface TerraView - TerraME

Gerencia do TerraME

1. O Pedro implementou os conceitos de Agentes no TerraME. Ele tem um exemplo muito bom sobre segregação. A implementação do Pedro é um caso que ilustra o conceito de programação multi-paradigma em TerraME. Funcionalidades de agentes já haviam sido previstas pelo Tiago em suas noções de (“Global Automata” e “Local Automata”). Considerando a lógica de permitir programação “top-down” e “bottom-up”, seria bom ter os dois conceitos em paralelo na nova versão do TerraME.

Comentários do  Tiago: 

1.1 Já se perguntaram qual a diferença dos agentes implementados pelo Pedro e um objeto(ou tabela) qualquer? (Nao tento, nem de longe, diminuir o trabalho do Pedro, quero colaborar) Eles não se comunicam, não possuem fluxo de execução independente, não são autônomos. Então, porque são agentes? Somente porque o nome da classe (função construtora) é Agent? A autonomia é requisito básico para a noção de emergência! Se os agentes não são autônomos, então existe um algoritmo que os controla. Se eles não se comunicam, então não são capazes de colaborar ou agir socialmente. Se existe somente um fluxo de excução, o modelo é inerentemente sequencial. Talvez, a falta dessas características permita que um bom modelador possa fazer um prognóstico sobre o comportamento do módelo apenas lendo seu código. Então, a simulação de processos emergentes seria limitada por essas questões. 1.2 Até mesmo nos automatos celulares, cada autômato é autônomo. Ele detem o controle sobre seu estado(discreto) interno, é ele quem decide quando deve mudar de estado. Tais autômatos somente são influenciados pelos que existem em outras células, se o modelador assim desejar e implementar regras dependentes da vizinhaça. Mas é ele quem avalia sua vizinhaça, e nunca o contrário, alguém de sua vizinhaça lhe ordena uma mudança.

1.3 Ao meu ver, as máquinas de estado são o modelo mais simplificado de autonomia, esse é um dos motivos que me levaram a adotá-las em detrimento dos Agentes na forma clássica proposta pela área de Inteligência Artificial.

1.4 Não acredito em agentes inteligentes, que necessitam representar internamente aquilo que conhecem do mundo que habitam, e que tomam decisões com base nesse conhecimento. Eles são demasiadamente difíceis de codificar, em 40 anos de pesquisa, ainda não foi encontrada um representação computacional para o conhecimento que tenha completude e ao mesmo tempo seja eficiente. Marvin Minsky tentou e não conseguiu, mas apontou vários caminhos futuros e mostrou que a lógica de predicados (ou lógica de primeira ordem) é insuficiente. Por que então devemos seguir nesta direção? Finalizo com uma frase que encabeça o artigo de Rodney A. Brooks do MIT Artificial Intelligence Laboratory: “Elephants don't play chess”.

1.5 Acredito que a real inteligência seja um fenômeno emergente de ações básicas tomadas por agents simplificados que sejam leves e eficientes. Acredito que não seja necessário manter uma representação interna do conhecimento do agente. O que o agente sabe é o que ele percebe em combinação com seu estado interno. Por esse motivo, adotei a idéia de “agentes situados” que na verdade, são implementados como máquinas de estados cujo estado(discreto) é correlacionado ao estado (continuo e discreto) do mundo por ele habitado: autômatos situados, como propostos por Stanley J. Rosenschein and Leslie Pack Kaelbling do Department of Electrical Engineering and Computer Science do Massachusetts Institute of Technology.

1.6 Algumas questões: Como processos simultâneos no espaço, isto é, processos que ocorrem simultaneamente em todos os locais do espaço (como a regeneração de uma floresta) poderia ser simulado por um único agente? Um agente pode estar em mais de um local no mesmo instante? (Haveria como garantir, de forma elegante e eficiente, que a avaliação desse agente na célula anterior, e a provavel alteração do seu estado, não afetaria sua avaliação na célula seguinte?) Se vc vai usar vários agentes para resolver este problema, então vc ocupará mais memória, terá que codificar a gerência dos agentes (criar, destruir, amarzenar lista de referências aos agentes, etc), terá que coordená-los e ainda garantir exclusão mútua no acesso a varáveis compartilhadas.

1.7 Sugestões para leitura (na ordem que deveriam ser lidos):

• Wooldridge, M. J. and N. R. Jennings (1995). “Intelligent agents: Theory and practice.” Knowledge Engineering Review 10(2) (http://www.csc.liv.ac.uk/~mjw/pubs/ker95.pdf)
• Brooks, R. A., “Elephants Don't Play Chess”, Robotics and Autonomous Systems (6), 1990, pp. 3–15.(http://people.csail.mit.edu/brooks/papers/elephants.pdf)
• Rosenschein, S. J. and L. P. Kaelbling (1995). “A situated view of representation and control.” Artificial Intelligence 73(149-73).(http://people.csail.mit.edu/lpk/papers/sitaut.ps)

 Comentários do  Miguel:  

1.1 - A questão do uso do framework TerraME para explorar modelos que envolvam a utilização de “agentes” é bastante interessante. Independentemente do que queira se definir como um “agente”, e literatura, como mostrou o Tiago, está cheio destas definições, o TerraME possui vários mecanismos interessantes para se desenvolver, não um modelo de agente único, mas na verdade vários, e isso é que é o interessante ali. POdemos ter sim agentes reativos, agentes situados, agentes cognitivos, enfim é possível explorar em TerraME um universo com o equivalente (mal comparando) a uma programação “multi-paradigma” para agentes e mais interessante, fácil de construir diferentes modelos de agentes. O fácil se refere não a “programação”de modelos multi-agentes por modeladores, mas para a experimentação ainda no ambiente TerraME. Por exemplo, agentes do tipo que temos no REPAST são possíveis no TerraME. Os mecanismos permitem. O que não temos é a maneira de construção destes agentes como o REPAST proporciona. Ou seja, precisamos neste momento é estudar mais os ambientes disponíveis para a criação de sistemas com agentes, e verificar com nossos problemas, o que precisamos, o que já temos, o que podemos facilitar, no universo TerraME, para quem deseja trabalhar com “agentes” em seus modelos.

1.3 - É preciso utilizar TerraME também como plataforma de inovação! Uma coisa é mante-la simples e com possibilidade de uso por vários setores e a outra e não nos restringirmos a pensar e criar mais idéias, que os mecanismos nos permitem: precisamos EXERCITÁ-LOS ao mesmo tempo em que tornamos seu uso mais simples.

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.