Upload
vukhanh
View
215
Download
0
Embed Size (px)
Citation preview
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