This page will be an overview on what was our experience in iterating through the CDM-s steps.

We've been given a ready to use set of models with already defined objective.
The main question is “How does the initial allocation of carbon quotas and the rules governing their trade influence the distribution and total release of carbon?”.
In the second step we needed to answer to the following questions:

• What is the data: The data is the whole behavior of the simulation. We are interested in statistics and all the numbers.
• Where is the data: Those numbers and statistic values are held within the messages. Listening to all of them with a module is enough to have all the information we need to answer to the main topic.
• How is it shared: The data is shared through the network and with messages with the use of the Blackboard system architecture.
• How is it processed/changed: The data is processed inside all the modules. All of them have tasks to do meanwhile they are exchanging messages with the other modules. The system will evolve itself just using its modules and their simple functions.

This accomplishes steps 1 and 2 of the CDM-s in which we should define objectives and questions to answer to during and at the end of the simulation.

In step 3 we had to define:

• Modules: this was given in the beginning with the specification of objective and the roughly defined modules.
• Blackboards: our blackboard architecture is implemented with a single WhiteBoard (naming by Psyclone framework) that is our Market. This is the most rational decision since in a double auction market the first functionality is to run a market accepting all the requests by the industries.
• Unit tests: we used a unit test in the beginning to troubleshoot the initial weird behavior that we were getting from the first implementation. This was really helpful for having a robust skeleton of the system before starting improving the rest of the functionality.
  

Step 4: the fun starts here..
This was one of the hardest step to go through because all the debugging, troubleshooting and important decision were made in this step after experiencing all the possible behaviors of the system.
We got stuck on this step because most of the important decision/problems are supposed to come up here.

• Expected communications: obviously we were really far from the expected system. Our modules were drowning the WhiteBoard because they were too fast to post messages and then some of the modules or even the Market were crashing. The solution was just slowing down the speed of the modules with a timer that allows all the publication/subscription to be successfull.
• Efficient information flow: this part was really helpful once improved. We needed to have a lot of information to be exchanged among the modules and we started giving static hardcoded parameters, then we moved to the command line options and then again we throwed all the “variable” values to the psySpec file as it is really easy to configure.
• Convenience with regard to programming languages and executables: we decided according to the teacher to use java because of its portability (and also because of the skills of most of the students). It could have been really an effort to use a c/c++ environment since we are three different users (mac, linux, windows), and again because we could have used a lot of code from the last year simulation. So the choice of using java was the most obvious.

First Iteration through 1-4 steps
Here comes the first break in the CDM-s flow. We needed to rethink something in the step 3.a and especially in their functionality like the message posting. And we needed to cut off temporarily the evaluation of the market of deciding who is trading with. For keeping the system as simple as possible we had to model the simulation as if it were running in a single country. This helped us a lot for focusing on building the right behavior for our system.

Step 6: assigning modules to team members.
..this was easy :) Marco was assigned to the Market, Ivar started to code the Industry module, and Vigdis was feeding the others with equations and numbers. The “math” work wasn't a real module assignement but it was clearly a very big effort since the numbers were gathered manually from all over the Internet under supervision of Rognvaldur.

Step 7: starting to code.
We really followed this step literally. We think that it's very important to write modules as empty boxes first and nontheless in a breadth-first approach.
The “shells” style of coding modules means that we built first the skeletons of the modules with the interface to post and receive messages. After the messaging system was working we started to code dummy functions inside the market and the industry.

Extension to the CDM-S:
We now needed to jump from 7 to 4 in order to test our system. This jump was needed to debug again the communication throughput and the efficiency of the information flow. Thanks to this new iteration (as it is not mentioned in the original CDM-S) we could easily debug and improve the resilience of the framework. We can say that we iterated from 7 to 4 more than twice..

After that we finally had our first version (0.2 in the svn repository) and we tested the system as described in step 8:
The system was working and doing what it was expected to do without errors, but after 10 seconds it stopped. The reason is that the modules had short life. The way we gave them parameters and demand functions was badly implemented (see step 9).

Step 9: Build Modules to specification.
This step was the most brain consuming! This was the main aim of the topic and we are not economist so we spent lot of hours deciding what equations and values to implement in the psySpec and inside the Industry module.
In this step we started to really need the timing.. it's been impossible to go on coding without a clock. So back to step 7 and building a Timer class. After that, again to step 4 to test the whole system with the new module.

Step 10/11:
The system is able to run on a single machine with 5 Industries and 1 Market showing a graph of what is the trend of bid prices, offer prices and responses from the market. Another couple of iteration to step 7 (as mentioned in step 11 of the original CDM-s) were needed to avoid some strange behavior (bugs described as well in the rest of the wiki).

Observation: we should have modelled a Timer earlier than when we did it.. We learnt that time passing is really important and helpful when testing and debugging.

Graphics, Charts and startup scripts: once the system was running we started to implement the part of simulation concerned in showing (and so “answering” to the initial questions) all the statistics, and a script to automate the starting up. The graphic part was easy to do since we had already the code from the simulation of last year, but Ivar spent a lot of time adapting the java classes to our system. The script is a bash script (so it runs just only on linux) that opens several shells with the java command for running every single module.