Reykjavik University
Fall 2005
Agent based modeling : Tech Report
Group 3
Target Groups & Bank
Ársæll Þór Jóhannsson
Hafþór Guðnason
Vignir Hafsteinsson
Agent Based Modeling
Final Project
Introduction
Modules
System overview
Bank
Target group
Different policies within target groups
Bank and market monitors
Message types
Bank
Target group
Discussion
Problems
Conclusion
Appendix A: Time schedule
Appendix B: Bibliography
3
3
3
5
5
6
7
7
7
8
8
8
9
10
11
2
Agent Based Modeling
Final Project
Introduction
The project described in this technical report was designed and implemented in the
course Agent Based Modeling and Simulation at Reykjavik University under the
direction of Kristinn R. Thorisson and Rögnvaldur J. Sæmundsson.
The projects goal was to simulate how innovational companies behave on a competitive
market. The model was as follows: Multiple companies are competing on the same
market. On the market there are several target groups that have variable preferences. For
the companies to be able to compete on the market they need three resources: capital,
employees and knowledge. For each of these resources there is an independent market
and the supply and demand varies over time. The knowledge market and the employee
market are intertwined since the knowledge of a company is dependant on its employees.
On all of these markets competitive situations between companies can occur.
With this model we wanted to see whether innovational companies or conservative
companies would do better and what influence education have on the firms and their
ability for innovation and adaptation.
The design of the project was based on the guide lines of the Constructionist Design
Methodology[1]. The simulation was split into multiple independent modules as follows:
Firm module, Target group module (multiple target groups make up the merchandise
market), Bank module (represents the capital market), Job-center module (represents the
employment market), University module (represents the knowledge market) and the
Individual module (represents a single employee in a firm or on the employment market).
The modules used Psyclone[2], a blackboard-based middleware, to communicate. The
modules were then categorized according to their nature and split between three groups.
One group implemented the employees, job-center and the university, a second group the
firm and our group implemented the target group and the bank. Each group was
responsible for their part of the project. To save work in merging the solutions together,
we elected leaders for each group and they designed a framework for the solution and
defined an interface for inter-modular communication. The rest of this report describes
the design and implementation of the target group module and the bank module and the
progress of that part of the project.
Modules
System overview
The project was written in java 1.5. The library log4j1 was used for logging and the
JFreeChart2 library was used for graphical interpretation of data in the monitors.
1
http://logging.apache.org/log4j/docs/
3
Agent Based Modeling
Final Project
The framework’s generic base-classes wrapped the openAIR3 library and simplified the
use of it. The framework simplified the posting of messages to whiteboards and message
handling. It also specified interrupts. Modules could register for interrupts that were
triggered at some interval, like at the beginning of the day or at the end. Another
advantage we got with this framework was that the message content that was being sent
in the form of XML data was encapsulated in generic data classes which provided the
methods for parsing the XML data and converting themselves to XML data. Therefore
we had the same structure on both ends to read and write messages, which made it easier
for different parts of the project to communicate. All the modules make use of the
framework by inheriting the BasePsycloneModule class which is an abstract class.
Figure 1 All the modules and most of the whiteboards in the whole solution. Message types in our
part are showed besides the lines.
2
3
http://www.jfree.org/jfreechart/
http://www.mindmakers.org/openair/airPage.jsp
4
Agent Based Modeling
Final Project
Bank
The role of the bank in this simulation was to lend the firms money. The reasons why
firms take loan in the simulation are mainly two: Either the firms need more money to be
able to pay their operational costs or the firms need money to be able to invest in more
production capacity or knowledge. Also, we wanted to see what influence limited or
unlimited resources, money in this case, will have on the behavior of firms and the ability
for new firms to enter the market.
When the bank receives a loan application, it evaluates the applicant by viewing how
much the applicant owes already and how much the bank can offer it. The bank does not
loan any firm more than 10 % of its total capital in order to distribute the risk. The bank
has limited capital so when the bank’s liquid resources are running low, it may have to
loan the applicator less amount than it applied for. In the worst case it will reject the loan
applications. The bank accepts loan applications by sending response with loan id and
amount to the loan applicator.
The bank advertises its current interest rates every day, so the firm can evaluate whether
it is favorable or not to take a loan. In our solution we have global rates that changes
every day and vary from circa 4% to 20 %. This variation simulates whether it is
inefficient to take loan or not. We use the following formula to calculate the rates:
f (n)  9 * sin( n / 40)  13
f(n) is rates where n is the day.
As most of the other modules the bank sends information, every day, about its capital and
liquid resources that triggers the monitor that updates its plots.
Target group
The target group module simulates a group of consumers in the market. Each group has
specified needs that they try to fulfill. The target group specifies what products the
consumers want and how much they want to pay for it. The firms try to produce goods
according to the target groups’ demand. The target groups listen to advertisements from
the firms and decide whether it should buy the product advertised and if so, how much
should be bought. The firm then confirms or denies the order made by the target group.
The target group has a finite amount of products it is willing to buy. Each target group
has a variable, max_quantity, which can be thought of as the number of consumers in the
target group. So it is possible to saturate a target group, that is if a company is able to
produce the product wanted sufficiently and at a price which is reasonable for the target
group. When a target group sees an advertisement for a product it checks if it is suitable
to its needs. The preferences of the target group are defined in a vector. Such is also the
case for the preferences the product fulfills. To find out how well the product services the
needs of the customer, the sum of the vector which is obtained by subtracting the product
vector from the target group vector. dist   Tg i  Pr od i
5
Agent Based Modeling
Final Project
If the product and target group vectors had the length of 2, this is the same as calculating
the Manhattan distance between the two “points”. The distance the product has from the
target group’s needs is used to calculate how much the target group is willing to buy
without regard for the price. We call this value maxBuyQuantity and it is calculated using
distancePercentageCost which is calculated using the distance from the product and
target group’s needs.
The maxBuyQuantity is calculated as the quantity which is left of the day multiplied by
the buyPercentage which is a percentage value calculated from the distance of the
preferences and the decayPercentage which determines how old the offer is. quantityLeft
is the amount that the target group has left to buy that day.
The following formulas are used for this:
buyPercentage = ( 100.0 - distancePercentageCost ) * decayPercentage
maxBuyQuantity = (buyPercentage/100.0) * quantityLeft
With the value of the maxBuyQuantity variable, it is possible to calculate how much
quantity of the product is to be ordered. The maxBuyQuantity variable dictates how much
quantity would be bought if the price was 0. So the price needs to be converted into a
percentage of how much should be ordered with regards to maxBuyQuantity. Each target
group has a variable, maxPrice, which dictates the upper limit of how much the target
group is willing to pay for the product. So if the product has a price which is greater than
maxPrice, the target group will not order anything. The amount is found with the
following formula:
 max BuyQuantit y * ad Pr ice
order _ quantity 
 max BuyQuantit y
max Pr ice
If order_quantity is greater than zero, an order is placed by sending a
abms05.product.quantity message to the WBMarket whiteboard. The firm then responds
with a confirmation message or a reject message if it cannot fulfill the order. This process
is repeated throughout the day n times.
Different policies within target groups
The target groups have different policies for how they change with time. These policies
are the price shift policy, product shift policy and the size shift policy.
The price shift policy determines how the maxPrice, which is maximum price a group is
willing to pay, develops over time. The logic which the policy follows is that if only a
small portion of the needs of a target group are being met then by time it will be ready to
pay a little more for the product to get its needs fulfilled. It also works the other way, that
is, if the target group is being well fulfilled then it will by time demand to get the product
for a lower price. This policy can be turned on or off.
The product shift policy determines how the preferences of the target group develop over
time. There are four different behaviors available for the product shift: BetterProduct,
6
Agent Based Modeling
Final Project
WorseProduct, NearestBetterProduct and BestBetterProduct. If BetterProduct is used for
the product shift policy then the target group will gradually want a product with higher
preferences. The WorseProduct policy is the inverse of the BetterProduct policy and will
cause a group to gradually incline towards a worse product. The NearestBetterProduct
policy will cause the target group to move towards products that are available on the
market and have slightly better preferences. The BestBetterProduct policy is to imitate
consumers that always have to have the latest and the greatest it will cause the group to
always jump on the product with the highest preferences on the market.
The size shift policy determines how the size of the target group max_quantity, which can
be thought of as the number of consumers in the target group develops over time. The
size shift causes the target group to randomly shrink or grow in size. This policy can be
turned on or off.
Bank and market monitors
These modules did not have any other purpose than listen to status messages sent to the
whiteboard WBStatistics and display the information in the messages in a graphical
manner. We did this to be able to do basic sanity checks on the system, and to be able to
get a detailed overview of the whole simulation.
Message types
Bank
Type
abms05.loan.advertisment
Action
Send
Whiteboard
WBNewspaper
Description
The bank sends information
about its current interest rates
daily by sending this message.
abms05.loan.collect
Send
WBFirm
abms05.loan.reply
Send
WBFirm
The first day in every month
the bank sends bill to the firms
that have loan in the bank, in
this message we have id of the
firm and the loan and how
much the installment is.
When the bank receives loan
application it replies with
amount loaned and current
rates.
7
Agent Based Modeling
Final Project
abms05.bank.status
Send
WBStatistics
This is just monitoring
information. E.g. Total and
current capital of the bank plus
current interest rates.
Request for loan. The bank
listens to this message. In this
messages is id of the firm and
how much loan the firm wants.
abms05.finance.loan.
request
Listen
WBBank
abms05.finance.loan.
payment
Listen
WBBank
This is payment of the loan
from the firm, included is id
and amount.
Action Whiteboard
Send
WBMarket
Description
The target groups send few
messages everyday with info
about how much they want to
buy and at what price.
Reject message from the firms
Target group
Type
abms05.product.quantity
abms05.product.advertisment. Listen
quantity.rejected
abms05.product.advertisment. Listen
quantity.accepted
abms05.product.advertisment Listen
WBMarket
WBMarket
WBMarket
Target group gets this if the
firms accept its deals
The firm sends this message
daily. This is information
about how much they want to
produce and at what price
Discussion
Problems
We had to spend more time than we expected to integrate the modules together in the
integration session. One of the reasons for that was in many cases that the values in the
messages that were being sent between the modules were not in the same scale. That
affected the execution of the solution because many wrong decisions were taken in the
modules when they got values in a different scale than was expected.
The most time-consuming problem we faced in our project was unpredictable behavior
by Psyclone. It did not seem to be able to handle the amount of external modules the
simulation required and its intense message flow. This lead to message congestion inside
Psyclone which caused delays and inconsistencies in the simulation. We were though
8
Agent Based Modeling
Final Project
able to solve this problem by distributing Psyclone and the blackboards over several
machines.
The biggest problem that we and the other groups left unsolved in the last integration
session was time synchronization between computers. Because the system depended on
each computer having synchronized clocks because a lot of messages were timesensitive, such as a time-out factor in advertisements. The synchronization wasn’t as easy
as we thought and even when we were able to make the clocks synchronized they became
unsynchronized after a few minutes of usage. This caused the modules to be working in
different days and inconsistency in the solution. We never got to the bottom of the
problem but the best guess was that it was because all the computers were connected on a
Microsoft Windows domain and the time controllers on that domain were not
synchronized.
Conclusion
We used the architecture that the leaders defined and it proved to be very good and only
minor adjustments were needed throughout the project. We also designed the internal
architecture for our part of the solution. Our original design proved good and solid and
stayed relatively unchanged throughout the project, though minor adjustments to single
classes where needed. The bank module was redesigned once but there was no need to
split it up or merge it to another module.
The whole project had no architectural challenges that could not be solved; however
things that were assumed to be trivial, such as time synchronization, and necessary third
party software caused the biggest problems.
Because of unforeseen technical problems the overall progress of the project was
considerably delayed. At the end of the course the system had finally become stable.
Because of these delays the course was over when all the groups had their modules
running and communicating correctly together. So we did not have the change to answer
the questions that Rögnvaldur raised in the beginning of this project. We were though
able to run the whole simulation for a considerable amount of time without complications
and it seemed to be functioning correctly. However to able to get some interesting
information out of the system considerable parameter tweaking is needed. Unfortunately
it has to be a project for some other groups and the questions are still left open.
The communication between groups through out the project was good. Several meetings
where held when critical decisions concerning whole of the project needed to be made.
The election of a leader for each group, proved to be a great idea and sped up decision
processes. Internal communication between group members in our group was good. We
divided the project into two sub-projects, and delegated them between group members. If
any major decisions where need to be made the whole of the group was consulted.
9
Agent Based Modeling
Final Project
Appendix A: Time schedule
Time spent in:
Hours
- Design architecture/framework of the 15
solution
- Design bank
2
- Design monitors
2
- Design target groups
10
- Programming bank
20
- Programming monitors
12
- Programming target group
80
- Integration sessions
30
- Defining message types
8
- Bugs in psyclone
15
- Bugs in Intellij
0
Sum
194
10
Agent Based Modeling
Final Project
Appendix B: Bibliography
[1] K. R. Thórisson, H. Benko, A. Arnold, D. Abramov, S. Maskey and A. Vaseekaran
(2004). “Constructionist Design Methodology for Interactive Intelligences”. A.I.
Magazine, Vol 25, Issue 4, pp 77-90. Menlo Park, CA: American Association for
Artificial Intelligence
[2] K. R. Thórisson, C. Pennock, T. List, J. DiPirro, “Artificial Intelligence in Computer
Graphics: A Constructionist Approach”, Computer Graphics Quarterly, Vol 38, Issue 1,
pp 26-30, New York, February 2004.
11