Page 1

Intelligent Tools for Policy Design

Deliverable 2.12 FUPOL Model Parameterization. Validated Version

Page 2

Project  Reference  No.   287119    Deliverable  No.   D  2.12  

Relevant  workpackage:   WP  2    

Nature:   Report    

Dissemination  Level:   PU  

Document  version:   v0_6  

Editor(s):   Roman  Buil  /  Miquel  A.  Piera    

Contributors:   Roman  Buil,  Miquel  A.  Piera,  Boyong  Wang,  Shaoyu  Wang,  Olatunde  Baruwa  

Document  description:   The   objective   of   this   document   is   to   define   the   model   parameterization   for  

different  domains  

     

Deliverable 2.12 FUPOL Model Parameterization. Validated Version

Page 3

 History  

Version Date Reason Prepared / Revised by

0.0 12/02/2014 Definition of TOC and data tables Roman Buil, Miquel A. Piera

0.1 28/02/2014 Inconsistencies (Vodno and Bicycles) Roman Buil

0.2 11/03/2014 Bicycles update Roman Buil, Olatunde Baruwa

0.3 12/03/2014 Edition Romualdo Moreno

0.4 16/03/2014 Yantai preliminary tables Roman Buil, Boyon Wang,

Shaoyu Wang

0.5 17/03/2014 Revision Miquel A. Piera

0.6 18/03/2014 Final revision and edition Roman Buil

Page 4

Table of Content

1   MANAGEMENT SUMMARY ........................................................................ 5  

2   DOCUMENT GUIDELINE ........................................................................... 6  

2.1   Purpose of the Document .......................................................................... 6  

2.2   Target group ............................................................................................ 6  

3   RECREATION ACTIVITIES ORGANIZATION: VODNO MOUNTAIN -

SKOPJE ......................................................................................................... 6  

3.1   Avoiding data inconsistencies ..................................................................... 6  

4   BICYCLE INTER-MODALITY: SKOPJE ...................................................... 7  

4.1   Avoiding data inconsistencies ..................................................................... 7  

4.2   Tables Update .......................................................................................... 8  

4.2.1   Tracks ................................................................................................ 8  

4.3   UsersData1 and UsersData2 ...................................................................... 9  

5   URBAN ECONOMICS: YANTAI ............................................................... 10  

5.1   Indicators List ......................................................................................... 10  

5.2   Sectors .................................................................................................. 11  

5.3   Industries ............................................................................................... 11  

5.4   Suppliers ................................................................................................ 12  

5.5   Clients ................................................................................................... 12  

5.6   Sectors Percentage ................................................................................. 13  

5.7   Min Max Level ........................................................................................ 13  

5.8   Upgrade ................................................................................................. 14  

Page 5

1 Management Summary

This document pretends to be used as a parameterization example for any city using

the FUPOL simulation software. Parameterization deliverables structure is modified in

order to introduce the excel file with data tables used to generate the .csv files used

as inputs for the simulation model. Parameterization deliverable consists on this

document and one excel file for each domain with any parameterization update.

Deliverable D2.11 includes some updates for Skopje models parameterization, and

the first version of the Yantai parameterization. Parameterization will be updated

along the full FUPOL project according to the validation and implementation of the

models, into deliverables:

• D2.15 FUPOL Model Parameterization. Prototype Version

• D2.18 FUPOL Model Parameterization. Definitive Version (month 44)

Each deliverable will be focused in a particular policy, in concordance with the

particular user case being developed at the same time; however, they will include

the policy user cases that have had some update.

Page 6

2 Document Guideline

2.1 Purpose of the Document

The main objective of this document is to specify the required data and its structure,

in order to prepare a simulation scenario using FUPOL models.

Cognitive and Causal Models deliverables (D2.5, D2.8, D2.11, D2.14 and D2.17)

already present the data needed for each element defined inside a simulation model;

therefore, the structure of parameterization deliverables (D2.9, D2.12, D2.15 and

D2.18) is modified in order to explain the input data tables needed to generate the

.csv files to feed the simulation software.

2.2 Target group

The target group of Deliverable 2.12 are mainly the simulation end-users, which can

be policy makers, city administration officials and citizens, because it contains the

information about the indispensable data required to use the FUPOL simulation

models developed. The document includes the specification of data tables or files

type for the different sets of data required to properly formalize the simulation

scenario.

The internal project target groups are the other team members dealing with WP3,

WP4 and WP5 (regarding data visualization).

3 Recreation Activities Organization: Vodno Mountain -

Skopje

This section extends section 4 of deliverable 2.9.

3.1 Avoiding data inconsistencies

During the testing phase of the Vodno Mountain model, some inconsistencies were

detected:

Page 7

1. In the “UsersData" table there were activities performed in some resources

that were not included as allowed activities in the “Resources” table. This fact

causes inconsistent results. Therefore, any activity that is performed in some

resource by some user (indicated in the "UsersData" table), must be included

as allowed activity for such resource (indicated in the "Resources" table).

2. Some of the columns regarding the sequence of activities of each user type

were incomplete. For example, the row of "U71" includes activity "A7" to start

at 10:00am; however, duration and resource were not indicated, which causes

an error during the simulation. Therefore, for each row, one activity, its

duration, the start time and the resource where it will be performed are

indispensable. After the first activity, if another activity is included in the

sequence, activity, duration and resource must be specified. If some of them

are missing, the model cannot be run.

3. Some rows refers to car and bike races that take place in the mountain just

once every certain weeks or months. Unfortunately, it is not possible to run a

simulation indicating a specific day for the race. Therefore, considering that

the races are not frequent, it is suggested to run the first simulation without

the data regarding the racers, and then, in one week simulation (simulation 2)

it is possible to check what could happen if one day there is a race in the

mountain.

Together with this document, there is an excel file

(InputData_VodnoSkopje_vfJan2014.xlsx) in which the tables have been modified in

order to avoid these inconsistencies.

4 Bicycle Inter-Modality: Skopje

This section extends section 5 of deliverable 2.9.

4.1 Avoiding data inconsistencies

During the testing phase of the Bicycles model, one inconsistency was found:

1. The last 11 rows of the "Stations" table were incomplete and they caused

problems during the simulation. To avoid this problem, they were deleted

Page 8

together with all the paths going through them; however, the final solution

must include all the needed information for each station together with the

tracks from and to them (in the "Tracks" table). Therefore, any row of the

"Stations" table must include the first 11 columns and the last 4 columns.

4.2 Tables Update

Some of the tables have been modified during the final model development stage.

There is an excel file (InputData_BicycleSkopje_vfJan2014.xlsx) attached to this

deliverable with the modifications mentioned bellow. The Bicycle Inter-modality

tables are reduced to 5. Profiles and Municipalities tables are not used.

Following subsections include an explanation about the tables with some modification

since the deliverable D2.9 were presented.

4.2.1 Tracks

There is one more column in this table: "bike track status", which indicates if the

track is already conditioned for bikes ("Existing"), if it is already "Planned", if it is

"Possible", or "Impossible". And the already mentioned column (in D2.9) named

"quality of current bike track" indicates the quality of the "Existing" bike paths with

values between 0 and 1. If the bike path does not exist, then the quality column is 0.

Current columns are:

• Origin/point1

• Destination/point2

• Distance

• Quality of the track

• Bike track status

Figure 1: Tracks Table

Page 9

4.3 UsersData1 and UsersData2

Both tables have been modified. Modifications in "UserData1" table are:

1. Column "Personality" has been deleted and the personality of the agents is

generated randomly.

2. Durations of the trips are also deleted due to they are calculated after

generating the agents origin (as indicated by the end user) and after applying

the Dijkstra algorithm, which generates the list of stations inside the user

bicycle trip.

3. Two new columns are added: "week days" and "week end". They indicate if

the trips are made during the week or in the weekend.

Due to the modification 3 inside the "UserData1" table, there is one modification in

the "UserData2" table. The seven columns regarding the "daysOfWeek" are removed

due to they indicated the same than the new parameters "week days" and "week

end". The difference is that they were filled in considering generic data for all the

users, and they are currently filled in for each user row, which makes the data more

real.

Figure 2 and Figure 3are the new "UserData1" and "UserData2" tables.

Figure 2: User Data Table 1

Figure 3: User Data Table 2

Page 10

5 Urban Economics: Yantai

The relevant elements of the model are the industries, their relations (client -

supplier), their capacity to upgrade in order to improve the value of the important

indicators, and the expectations of the City of Yantai about the annual energy

consumption of the city, total CO2 emissions, sectors representation in respect on

the total industrial park of the city, etc.

One of the excel files (InputDAta_Yantai.xlsx) attached to this deliverable contains

the data tables for the Yantai use case. The file includes 8 tables. Some of them are

already fixed:

1. IndicatorsList

2. Sectors

3. Industries

4. Suppliers

5. Clients

6. SectorsPercentage

7. MinMaxLevel

8. Upgrade

Following subsections include an explanation about the tables and how to fill them

in.

5.1 Indicators List

Figure 4 shows the indicators list included as information inside the excel file.

Page 11

Figure 4: Indicators List (informative)

5.2 Sectors

This table is also informative as it can be seen in Figure 5.

Figure 5: Sectors List

5.3 Industries

Industries table include all the important information about the industries attributes.

It includes existing industries and expected new industry profiles. It gets the value of

each indicator for each industry and also some other attributes:

• ID

• Description/name

• SectorID

• Latitude/Longitude (just for administrator user)

• Upgrade Capacity: indicates if the industry has capacity to upgrade or not.

• Upgrading: It will be an attribute that will show if the industry is trying to

upgrade or not.

Page 12

Figure 6 and Figure 7 present the industries table.

Figure 6: Industries Information Part 1

Figure 7: Industries Information Part 2

5.4 Suppliers

Figure 8 presents the data needed to indicate the suppliers of each industry, which

must be also industries included in the industries table. ID column indicates the

industry Id which is supplier of the industry ID indicated in the "ID principal

Industry/Compay" column. The revenue variation percentage is the affectation of the

supplier if the principal industry is closed.

Figure 8: Suppliers Table

5.5 Clients

The Clients table is similar than the Suppliers table. The only difference is that the

IDs are from clients instead of suppliers (See Figure 9).

Page 13

Figure 9: Clients Table

5.6 Sectors Percentage

Figure 10 indicates the percentage on industries of each sector expected for the

years of the simulation. Decisions will try to drive the percentages to the percentages

indicated in this table.

Figure 10: Sectors Percentage Table

5.7 Min Max Level

Min Max Level table indicates the minimum and maximum values for the summation

of all the industries indicators. Some of the indicators must be limited with the

minimum and some others with the maximum.

Figure 11 and Figure 12 present the table in which it is possible to indicate also the

limits year by year.

Page 14

Figure 11: Minimum Values Table

Figure 12: Maximum Values Table

5.8 Upgrade

The upgrade table indicates the capacity of the industries to upgrade. There two

types of upgrade: technically and financially, and the real capacity is the minimum of

both. The other columns are:

• Max Percentage of Improvement: it indicates the maximum percentage of

updating for all the indicators if the technically and financially parameters was

10.

• Real Improvement: it is the final improvement considering the max

percentage of improvement (MaxPerImp) and the minimum between

technically (Tech) and financially (Finan) parameters. It is obtained using the

following equation:

𝑅𝑒𝑎𝑙𝐼𝑚𝑝   =  𝑀𝐼𝑁(𝑇𝑒𝑐ℎ,𝐹𝑖𝑛𝑎𝑛)  ∗𝑀𝑎𝑥𝑃𝑒𝑟𝐼𝑚𝑝  /  10

Page 15

• Percentage of update progress: It indicates the percentage of the real

improvement that the administrator considers the industry will satisfy. If it is

100, it means that the administrator trust the industry and the improvement

will be exactly the real improvement value. If it is less than 100, it means that

the administrator does not trust the industry at all and they expect that the

final improvement of the industry will be a percentage of the indicated real

improvement.

• Initial Improvement: Even an industry could improve some amount; it is

possible to just use part of it if it is enough to keep staying in a good position

in the administrator list. The value can increase or decrease during the

simulation. This column indicates the initial value, which will be between 0

and MIN(Tech,Finan).

Some lines of the table are shown in Figure 13.

Figure 13: Upgrade Table