November 30, 2005

Practical Matters:

Try out software for teleconferencing between Virginia and Montreal.

Theory/Discussion:

We discuss basic agent behavior and possible ways to incorporate the BDI agent architecture into the agent formalism I will create. We want primitives for encoding beliefs, desires, and intentions, but the formalism will not focus on them.

The Professor says that I should look for a simple, goal-seeking MAS example, one that would better show agent beliefs, desires, and intentions than the flu example.

We look at the problems of dealing with both discrete and continuous environments in the formalism. Agents could exhibit continuous behavior (holding up a chair, for example). The Professor makes the point that it's best to bring continuity/discretization to the surface and make it the user's responsibility. A discrete formalism can always emulate continuous environments to a certain level of abstraction.

We attempt to work out the details of agent simulation. The idea of neighborhoods is one that will be key to simulating the concept of "nearness" of agents. Nearness is not limited to physical proximity of agents, however; neighborhoods can be used to model cellular phone networks and other communication environments. Communication is perhaps the most important aspect of agent-based systems, and being in another agent's neighborhood implies a means of communication. Neighborhoods would also be useful for environment experts.

Professor Vangheluwe brings up the notion that the execution kernel should be able to give an agent a list of others in its neighborhood. Agents communicate with other agents through the environment manager, which handles inter-agent connections. The execution kernel can only access an API that reads the state of the world. It does not update the state, does not consume time to access the state, and does not produce output. The execution kernel does have meta info, however; it knows the type of data in each agent. Is the execution manager responsible for warning agents of physical obstacles in the environment? Obstacles could possibly be agents, too.

We discuss Marc's work on Himesis. It has a kernal and an API for describing graphs. It takes a symbol table approach; it is a graph but it acts like a dictionary for symbol data.

The Professor stresses the importance of having a neutral programming language to model agent behavior. It's likely that any new language that I design will be used in Bill's work. I should start by building an AST in memory using Himesis. To speed up development, I could create an XML file from an AST walk that would be used to automatically rebuild the AST when needed.

To do:

1. Use Marc's Himesis to work on the neutral programming language. Start with basic ints then move to characters, strings, variables, if's, and while loops.
2. Use Himesis to create, in memory, a basic actor that will eventually become a modified DEVS agent. The actor should be able to query the execution manager and get a list of its neighbors (in this case, just the actor itself).
3. Look for a scenario for agent simulation that better exemplifies BDI.

July 13, 2005

Practical Matters:

Theory/Discussion:

Professor Vangheluwe and I discuss Rhapsody's model to code translation. The default code Rhapsody generates for certain data structures confuses me, but the Professor explains that the code is probably generated to be as efficient as possible. I am still annoyed that the Rhapsody manual does not state the translations outright. He says that XJTech's AnyLogic requires one to model threads; Rhapsody does this for you.

We discuss some of the questions I'll have to raise and answer for my thesis. How good is Rhapsody for model-based design? How good is Rhapsody, AnyLogic, and PythonDEVS for agent-based design? For instance, does Rhapsody model interactions between agents well? In the Flu domain, is an Environment agent necessary for Rhapsody to simulate it properly?

We also discuss how compiled models require no meddling in source code. Once one begins manually editing code, formal analysis becomes impossible.

Finally, Professor Vangheluwe mentions the possibility of using a TCP/IP port for my animations. The animation would run on the data the three formalisms generate.

To do:

1. Rhapsody presentation. Examine Rhapsody in-depth and prepare a presentation on the software for August 5th. Focus on model-based design, not agent-based.
2. Flu animation. Use TKInter or AToM3 to animate PythonDEVS Flu simulation.
3. Literature research. Read paper from 1976. See if PythonDEVS Flu model (and soon, other models) fit with the data. This is specific to the Flu domain, but quantitative comparison of the models to the data is better than just qualitative comparison.

June 8, 2005

Practical Matters:

Theory/Discussion:

Professor Vangheluwe and I discuss ILogix Rhapsody, model compilers, and hierarchies in models. Rhapsody generates code in several programming languages. Object-oriented code may be easier to read through; but once a model is compiled, one is usually most interested in the code's efficiency. Object-oriented code may also mangle certain details of formalisms in order to make use of objects and class-hierarchy; this is certainly unwanted.

Model compilers also have the benefit of being useful for model analysis purposes. And models compiled into languages that do not require virtual machines are difficult to reverse-engineer, a significant security advantage if desired.

Hierarchies are extremely important to the way we view the world; models should reflect that. Hierarchical statecharts would be a statecharts-derived formalism that directs messages between states in a lower level of the hierarchy to the states in higher levels. One could abstract the models to only the top X levels and still understand the mechanics of the model. Wil Wright's new game "Spore" hints at this idea of abstracted hierarchy.

To do:

1. Rhapsody presentation. Examine Rhapsody in-depth and prepare a presentation on the software for July 8th.
2. Flu animation. Use TKInter or AToM3 to animate flu simulation from 522 project. Focus on making the simulation time correspond--through some factor alpha--to the real time (see image above). While animations have their limitations, they are a nice way to present simulation data to people who are not familiar to simulation or the domains. Animations are good explanation tools.
3. Literature research. Read papers on multi-agent systems and the formalisms used to model them. Find out which journals, researchers, and authors are the most recognized and referenced. Discover what has already been done in the multi-agent modelling field and what challenges are currently being faced. Think about which of those challenges should be targeted in the Thesis.

May 18, 2004

Practical Matters:

Theory/Discussion:

Professor Vangheluwe and I discuss the direction of my Reading Project and Thesis. Since Eystein will work on the connection between discrete agent behavior and its continuous emergent counterpart, I'll concentrate my efforts on the discrete aspect of multi-agent computing. The Reading Project will give me the knowledge required to pinpoint one or two of the most current challenges faced in the area of multi-agent modeling and simulation. In the Thesis, I will make my own formalism to (hopefully) overcome these challenges.

The idea of continuity is the thread that ties together the research conducted by the MSDL. A good model should lead to a good simulation but also translate in some way simple way (through a compiler, etc.) to a working piece of software. The final consequence of an accurate model/simulation setup should be the high possibility of a real-world implementation.

To do:

1. The Flu model and simulation. Read up on the domain, try to find solid data if possible, but focus on modelling it and animating the simulation. Think about one could possibly alter the Flu simulation for the Bullying domain. Qualitative results (graph of emergent behavior should be reasonable) are desired, but quantitative results would be nice.

2. Modelling formalisms. Examine and compare different formalisms, i.e. XJTech AnyLogic and I-Logix Rhapsody, in regards to the Flu domain and multi-agent modelling in general. Examine how important aspects of agent modelling (concurrency, communication, probabilities, etc.) are translated into the formalisms.

   Explore multi-agent projects such as SWARM.

3. Literature research. Read papers on multi-agent systems and the formalisms used to model them. Find out which journals, researchers, and authors are the most recognized and referenced. Discover what has already been done in the multi-agent modelling field and what challenges are currently being faced. Think about which of those challenges should be targeted in the Thesis.