Our current implementation of Abstract Country defines all the fields as protected. What it means is that the agent can modify every parameter, e.g. country A may double their available cash every tick.
This would be considered cheating and we assume that no country would do it as it would destroy the game. This is however very unprofessional from the software engineering point of view.

Do you think we should stick to the way it is implemented now or
Change implementation so all the fields are private and we have protected getters to access the functions. This would require some work to modify most of the functions in AbstractCountry.

Not really an issue, but I just wanted to let you guys know that the final version of data.csv is now available in my repo (http://www.github.com/ncocacola/kyotoCountryData).

This contains all and exclusively the data that will be inputted into the program via Jonathan & Max's interface.

All the information you need is in the README.md, otherwise, send me a message and I'll try to help.

Cheers,

Nicolas

Hey guys,

Please make sure that anything you do in /src/main/test is done on the JUnitTests branch.
During "work days", development is merged into it every hour or so (to get the most up-to-date code to test) and JUnitTests is merged into development at the end of each day (this is done mainly to avoid "polluting" development with test commits during the day - if you think there's a better strategy to be used, please suggest it).

Also, Darby, it seems you've broken the folder structure ("java.uk.ac.ic.kyoto.trade" instead of "uk.ac.ic.kyoto.trade") :P

Any questions about the branch, feel free to ask :)

Cheers!

Bananaman

We need check that each of the functions called at the end of years and sessions are called in the right order and at the right time.

For example monitors issues need to be performed before emissionTargets are updated.

Further to that, the list of functions to call should be filled and finalised as much as possible

Did we decide on the method to apply sanctions on countries that have not met their targets.
I guess that unlike sanctioning for cheating, there should be no sin counting.
I will implement it when we agree on the method.

There's no to-do list on GitHub. There's a whole bunch of different ones in google docs. Lets drop the google docs one and move to a GitHub solution where individuals can be assigned to and take ownership of targets. Then branches/commits can be associated with problem solutions. Hopefully this will better structure our code!

Using Trade Protocol or otherwise, we should be able to implement the clean development mechanism. (Annex 1 countries investing in non-annex1 countries, providing the monetary benefit for the 'investee' and generating carbon credits for the investor. Note: This is not the same as a purchasing transaction.)

Tom is trying to fix this.

If you look at both handlers, they are a bit messy when it comes to errors. They may throw NotEnoughXXX errors, which is good. The problem is that their behaviour in case of any other error is uneven:

• some functions use try catch blocks and return 0 or MAX_VALUE in case of error
• some don't use try catch blocks at all, and leave it to countries to catch any errors

The issue with the former is that we don't have any feedback on errors. since handlers don't have access to countries' loggers, they have no way of indicating that something went wrong - they can only return some ridiculous variable.

So my proposition is to go with the latter in every function, i.e. do not catch any errors and adjust return variables in the handlers, leaving it to the countries to catch any errors and decide what to do with erroneous reutrn variable.

I am happy to do the cleaning up in both handlers if everyone agrees

timeService.getCurrentTick() currently always returns 0.

This is quite a serious issue as it is used to calculate year ends etc.

At the moment the emission targets are stored in two places: in shared state handled by CarbonTarget and in each country as a field.

If we decide that our solution is service based, we should get rid of the emissionTarget field in Abstract Country and query the shared state whenever we need to access this information.

Is my thinking correct here?

The types that we use for describing different parameters of countries are really inconsistent. E.g. available to spend (which at the beginning of the the game is a fraction of a GDP) is long while GDP is double.
As the unit of everything are quite arbitrary, I suggest to use long for each variable except those that express ratios, rates and percentages (none of the parameters is such). This way, we would avoid type conversion problems and division of doubles problem.

If you agree with me, I will implement the change and. the constructor is going to change! :D

There is now some very dangerous looking methods which generate no warnings in both these files due to my meddling with the types in Abstract Country (all longs now doubles), please could the respective owners of these classes spend some time checking everything works?

In the current implementation of Abstract Country, we include functions that are used for reporting, monitoring taxations etc. However, not all the countries (e.g. NonAnnexOne), need this functionality.

I suggest moving the Kyoto specific functionality to a separate class that extends from Abstract Country.

Do you agree and is there anyone that volunteers for doing it?

EU renamed to AnnexOneReduce
Commies renamed to AnnexOneSustain

Better reflects the agents that will be instantiated under these behaviours.

Single Agent attempts to reduce carbon output.

Someone has to run a half-marathon tomorrow.
I will try handling it.
Wish me luck :D

We're thinking of making (some?) variables of AbstractCountry package protected, meaning the variables are only visible to classes within the package.

This has the effect of preventing countries accidentally changing variables when they shouldn't be, but still allowing the handlers to access the variables.

Speak now, or hold your peace.

A single agent in a world without the Kyoto protocol. Their Carbon emissions increase unchecked (linked to their GDP growth).

I remember that there was a default constructor in the Simulation class. Without that the simulation cannot run. The constructor is as follows:

public Simulation(Set<AbstractModule> modules) {
    super(modules);
}

The group 3 branch is currently 187 commits behind development. Developing on a branch that is so far behind development will likely cause problems when you try to merge back in.

Could you please sort this by merging development into group3 - be extra careful about what changes are introduced, it is likely you will need to manually resolve some conflicts.

Basically, the issue in the handler is that the price of planting trees only depends on the arable area left for a country. But this is not realistic - imagine a situation:

• Country A has 1000 area, and 50 arable area.
• Country B has 60 area, and 50 arable area.

Cost of planting trees in both is the same now. However, it shouldn't be the case - Country A is heavily "crowded", so that little area left should be much more precious than for country B (much smaller country), of which most area is unoccupied.

My proposition is to base the price on the percentage of area left (arableArea / landArea) instead. This is analogous to CarbonReductionhandler model, where the price of reducing carbon depends on the cleanIndustry factor. This would mean we could use similar formula.

I would be happy to modify CarbonAbsorptionHandler when CarbonReductionHandler is working.

What happens now is, when you plant trees, you get a single reward in carbon offset.

This is slightly illogical - trees absorb carbon all the time, not just once. Conceptually, the ideal situation would be to grant carbon offset every year, for each tree block planted since the start of simulation. However, this would be difficult to implement - we don't store the amount of planted trees anywhere.

Another solution would be to reduce carbon output every time you plan trees. The problem is, this influences your dirty industry (carbonOutput / energyOutput), which in itself influences the price of carbon reduction. So, after plantng trees, it would be more expensive to clean your industry, which doesn't make sense.

Hence, the only viable solution that has been proposed is to introduce another variable: carbonAbsorption. Every time you plant trees, it is increased by some amount, measured in CO2 per year. So in effect, the condition you have to satisfy every year becomes:

carbonOutput - carbonAbsorption - carbonOffset <= emissionTarget

I have started to implement it, and will merge with development soon. This means, every country has to modify their constructor slightly (just add another variable).

If anyone has any issues, comments etc, write here. If everyone's ok with that, I will close this issue in the evening.

The country variables have now been changed to package protected.

This means to access variable values you'll need to use getters in your behaviour.

@georgePil , @whitebloodcell , @n1kunj

Nik believes that there aren't enough possible strategies for country behaviours and that everyone would just act on the last tick of each year.

To spread trades/investments more, it was suggested to introduce a spending cap per tick.

So today we came to a problem that after finishing the trade protocol functions should be called for every country to change the carbon offset and change the cash. These functions are implemented in the super class i.e. AbstracCountry but the problem with this is that every country can choose not to call this function and when the initialise their trade protocol. This means countries can do whatever they want in these functions which breaks the game.

So what I suggest is the following:

1. Initialise trade protocol in AbstractCountry: This gives the added advantage that all countries can have access to this tradeProtocol. If they wish to not use this then they can remove the canHandle() method in the processInput function.

2. Override the tradeProtocol carbon and cash changing functions with the ones that Stuart wrote today

3. Create an abstract function acceptExchange which is overriden in the sub classes which will have the country's own shizzle...

A single agent attempts to cap its carbon output without adversely affecting GDP.

We're testing carbon absorption and we're unable to invest enough money to perform any improvement in whole units of carbon.

Something to look into.

It always returns 0 because it uses longs instead of doubles, meaning carbon reduction is pretty much free for me in my test case. It's a bit late today but at some point we all need to sit down and properly figure out what number format we should be using for all variables. If we keep using longs for everything, we're going to have a bad time.

I suggest doubles and millions of dollars for everything, otherwise we're losing so much information, especially as a lot of stuff seems to be calculated using loops (rounding error after rounding error = problems).

I have read through "Carbon Offset - A Meaning Of", and have two questions:

• According to the model, the carbon offset that we buy only lasts till the end of the year. Say, a country has a carbon output of 110, and its target is 100. Then, if it doesn't invest in reduction/absorption etc, it has to buy 10 credits from other countries every year in order not to face sanctions. Shouldn't credits last for entire session, instead of being "cancelled" every year?
• As far as I know, it was decided that each of the countries' session target would be divided into smaller year targets. Could someone explain why? Shouldn't it depend on the country when they want to limit their emissions/buy credits etc? This way, there would be much more room for strategy of when reduction/absorption/buying/investing is most profitable. As it is in the document now, an idea of "session" becomes meaningles, since the targets and offsets are set again every year anyway.

In order for countries to be able to increase their energy output and thus their economic growth, countries should be able to "build" factories and thus those factories have an effect on the energy output.. Do you think we should have a general constant value for that effect or just let countries decide? Also what would the cost be for those "factories", because countries should not be able to spend unlimited number of money on increasing energyoutput since energyoutput is used for calculating GDPrate ?

Hey guys (more specifically Adam and Webbo),

With regards to the data.csv file which will contain all the input data for the program, I have come across an issue that needs to be solved.

We agreed with Stuart and Tory, that countries where some data is missing would be removed from the data set (typically small islands that don't really matter). For the specific case of former Soviet Union countries, where a lot of 1990 data is missing, we agreed we'd input 1992 data instead.

The issue now is about a bunch of countries (mostly African - 53 countries in total), where we don't have the Fossil fuel % (i.e. we have carbon emissions data, so we know they use fossil fuels, but we don't know what percentage of their total energy consumption is from fossil fuels/carbon emissions).

The Fossil Fuels % will not be inputted into the program, but it is used to calculate the energyOutput field (i.e. if all the energy consumption of the country was fossil-based, how much carbon would it use)
using the formula energyOutput = carbonEmissions/FossilFuels.

Since we do not have the Fossil Fuels % for these 53 countries, we can't get energyOutput and thus do not have a full data set.

Three possible solutions to this problem:

• Remove these countries from the data set (we'll still have 120 countries to work with, but Africa will be poorly represented).
• Make up Fossil Fuels % and thus Energy Outputs for these countries.
• Get rid of energyOutput and find another way of doing what Adam does with it.

It'd be awesome if you could give me some input on what you think about this issue.

List of countries with this problem:
Antigua and Barbuda, Bahamas, Barbados, Belize, Bhutan, Burkina Faso, Burundi, Cambodia, Cape Verde, Central African Republic, Chad, Comoros, Djibouti, Dominica, Equatorial Guinea, Eritrea, Fiji, Gambia, Grenada, Guinea, Guinea-Bissau, Guyana, Kiribati, Laos, Liberia, Madagascar, Malawi, Maldives, Mali, Marshall Islands, Mauritania, Mauritius, Namibia, Niger, Palau, Papua New Guinea, Rwanda, Saint Kitts and Nevis, Saint Lucia, Saint Vincent and the Grenadines, Samoa, Sao Tome and Principe, Seychelles, Sierra Leone, Solomon Islands, Somalia, Suriname, Swaziland, Tonga, Tuvalu, Uganda, Vanuatu

Time Service needs @Inject statement in its constructor. Also constructor needs to be public.

I know Stuart fixed it but I think he still hasn't pushed the stuff so till then I will leave this issue open so that people don't go crazy when simulation throws exceptions.

I was looking into the Monitor service. There is a particular problem in declaring Monitor as a service. Essentially you can register a service as a global service i.e. Actions or ActionHandlers can use them or you can register them as ParticipantServices. Either way, services are used for reading or writing shared states in the environment.

The monitoring function is basically determining which agent to monitor and put sanctions on agents who cheated. The only way a monitor can provide sanction (in an unhacky way!) is through protocols.

Do you guys think we should change the monitor to an Agent instead of an Environment Servie?

In the Energy Usage Handler, when a reduction in energy output is required/occurs this is probably removal of factories since they pollute ( carbon output) but also produce energy (energy output). Should there be an increase in the arablelandarea since factories are removed?

I can see that a lot of development was done on Monitoring service, but it is now using the strategy of randomly choosing the country to monitor and charging it for it. Why exactly are we using this strategy?

There were 3 strategies that we have considered:

1. Taxing the transaction. We decided not to use it as transactions are done between the countries and no body is actually controlling them, so there should be no body that implements taxation
2. Monitoring can always happen. Monitoring service can basically monitor every time it wants. This was a bad idea because it is really unreal and makes cheating really impossible.
   3.Each country pays the service each year a constant amount of money. Monitoring service can use it to monitor any country that they choose based on some algorithm (e.g. countries that cheated most in the past will be monitored more frequently). This was the strategy that we have decided is most realistic and fair.

Why are we then charging the country that we monitor? In this case we can basically monitor every country in every round and they will have pay for it. Doesn't seem either fair nor real (as countries would never accept such conditions and wouldn't join kyoto)

Can @maxrev17 and @webbo89 come up with a list of data that they want to be able to represent?

Farhan can then implement a DataToMongoDB function which will be called at the end of every year/session in Abstract Country?

Currently, the carbon reduction handler works in a flow of control perspective, but the values it returns for given investments are way out of range. (A marginal investment (10% of availableToSpend) when carbonOutput is 30,000 tons results in an output change in excess of 900,000)

carbonAbsorption is effectively the equivalent of carbon offset, except that it is not reset to 0 upon the end of a session.

If this is the case, does it get spent in the same manner as carbon offset when countries do not meet their target? If so, which takes priority? If not, does that not make carbonAbsorption the same as carbonOutput?

So I just discovered that if we made an organisational repository it would have been much better. I didn't know about this thing until today. Basically its much neater than having it on someone else's account, because having it on an organisation gives us more admin management facilities, looks cooler!!

I can transfer the repository but the issue is I don't know what could happen if I do. Things can get messed up!! I emailed github about this issue and I hope they get back to me.

However once our development commits become a bit infrequent and we are at a good position I suggest that we move to the new repository in the organisation. I created the organisation:

www.github.com/kyotoprotocol

let me know what you guys think!

According to the document How Time Works ( A Brief history thereof) agents need to be added to the monitoring service, connect to reporting service and query for emission targets initially.

Addressing to the author :p or anyone who might know, it is my belief that Non-Annex 1 countries do not require to do this.

Also since Non Annex 1 countries are not being monitored then do not require to -Pay monitor tax or submit any reports for monitoring.

Correct me if I m wrong

Cheers!

These can be removed from the constructor as they're calculated in game.

Currently, most functions return unrealistic data.

We need to focus on balancing the input data as soon as possible!

Current work in Balancing