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. Um dos pontos mais delicados do TerraME (mas necessário) é a revisão dos conceitos originais. Esta revisào deverá ser muito debatida, pois (como dito acima) muitos conceitos nasceram de reflexão longa do Tiago, e ainda não foram plenamente absorvidos pelo resto da equipe.

2. No curso, usamos os conceitos de CellularSpace, Cell, Neighbour, SpatialIterator e as funções ForEachCell e ForEachNeighbour. Eles foram suficientes para todos os exemplos. Precisamos de muitos exemplos adicionais que possam validar os demais conceitos do TerraME.

3. Minha intuição é que podemos descartar de vez os conceitos de Automatos Híbridos.No caso de Automatos Globais e Locais, seria bom construir exemplos de seu uso, para podermos entender melhor todas as implicações destes conceitos.

1. Estamos muito interessados em usar os conceitos de autômatos aninhados. A idéia é ótima, já está disponível na versão atual do TerraME. Seria muito útil amplia-la permitir usar automatos aninhados em programação “bottom-up”.

2. Consideremos duas situações distintas: (a) Dois espaços celulares na mesma resolução em tempos diferentes; (b) Dois (ou mais) espaços celulares com resoluções diferentes.

3. No caso (a), seria bom ter uma extensão da função ForEachCell que combine os dois espaços celulares na área onde haja intersecção. Minha sugestão é ForEachCellPair (cellSpace1,cellSpace2). (Update 21/Fev: O Tiago já implementou esta função - que rápido!).

4. No caso (b), a interface entre dois dados de resoluções e extensões distintas precisa de funções de passagem de escala que façam “upscaling” e “downscaling” de dados. Seria bom termos uma função adicional: ForEachNestedCell (cell, function( cell, nested_cell)); Essa função permitiria o “upscaling” e “downscaling” entre espaços celulares aninhados.

   Comentários Tiago:

4.1. TerraME não possui o conceito de células aninhadas, somente escalas são aninhadas (Scale ou Environment), e com elas todo seu conteúdo: espaços celulares, automatos e relógios. Então, o aninhamento de escala, necessariamente, não estrutura o espaço, não há como saber que células de uma escala interna são conceitualmente(na cabeça do modelador) refinamentos de uma células da escala externa. Esta estratégia evita que o modelador precise definir à priori a estrutura para o espaço, não enrijece as estruturas espaciais que poderiam ser criadas em TerraME, facilita a carga de espaço celulares a partir de sistemas de informação geográfica onde o conceito de mapas é forte. Contudo, TerraME fornece as ferramentas necessárias para criar “qualquer” estrutura espacial, através do conceito de vizinhanças: células em um espaço celular podem ter vizinhos em qualquer outro espaço celular.

4.2. Suponha os espaços celulares “cs1” e “cs2” como apresentados na figura abaixo. Nela, cada célula do espaço celular “cs1” possui 4 células de resolução mais fina no espaço celular “cs2”. Uma relação unidirecional (de cs1 para cs2) foi utilizada para implementar o conceito de aninhamento de celulas e permitir “downscaling”. Se as células de “cs2” também precisassem conhecer sua célula “pai/mãe” para permitir “upscaling”, então uma vizinhaça bidirecional deveria ser utilizada, bastaria incluir a células de “cs1” como vizinha das 4 de “cs2”.

Figura 1. Aninhamento de células por meio da relação de vizinhança.

4.3. Desta maneira, a função “ForEachNestedCell (cell, function( cell, nested_cell))” não existe em TerraME, mas sua funcionalidade pode facilmente ser implementada pela combinação das funções “ForEachCell” e “ForEachNeighbor”:

  ForEachCell( cs1, 
               function( cell )
                    ForEachNeighbor( cell,
                                     1, -- 1 refere-se ao índice da vizinhaça, que foi utilizada
                                        -- para implementar a estrutura espacial como discutido
                                      function( cell, neigh, weight ) -- neigh é uma nested_cell
 
                                          -- coloque aqui o seu codigo
 
                                      end
                    );
               end
  );

4.4. O codigo fonte abaixo mostra como vizinhanças podem ser criadas respeitando-se as coordenadas cartezianas (estrutura espacial) atribuídas pela biblioteca GIS TerraLib. No código, uma vizinhança de Moore é criada para cada célula do espaço celular recebido como parâmetro.A vizinhana de Moore, para o espaço bidimensional, inclui as 8 celulas imediatamente adjacentes e a própria células, totalizando 9 células.

-- Creates a Moore neighborhood for each cell
function CreateMooreNeighborhood( cs )
	for i, cell in ipairs( cs.cells ) do
		local neigh = Neighborhood();
		local lin = -1; 
		while ( lin <= 1 ) do
			local col = -1;
			while ( col <= 1 ) do 
				-- add nieghbor
				local index = TeCoord{ x = (cell.x + col), y = (cell.y + lin)};
				neigh:addCell( index, cs, 1/9 ); -- wheight = 0.111111 (9 neighbors)
 
				col = col + 1;
			end
			lin = lin + 1;
		end
		cell:addNeighborhood( neigh );
	end
end

4.5. O arquivo a seguir demonstra como o conceito de vizinhaça de TerraME pode ser utilizado para construir aninhamento de espaços celulares. É necessário o banco “rondonia.mdb” para executar o exemplo: demo1.luademo1.lua

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.