-
Notifications
You must be signed in to change notification settings - Fork 29
Preday System
This page attempts to succinctly summarize the overall design and flow of information in the Preday System of SimMobility, include a summary of the functions thereof. (NOTE: this is still work in progress)
PredaySystem Functions:
predictUsualWorkLocation
predictTourMode
constructTourModeParams
predictTourModeDestination
predictTourTimeOfDay
predictSubTours
-
predictSubTourModeDestination
: -
predictSubTourTimeOfDay
: predicts time period of subtour activity constructIntermediateStops
generateIntermediateStops
predictStopModeDestination
predictStopTimeOfDay
fetchTravelTime
calculateArrivalTime
calculateDepartureTime
calculateTourStartTime
calculateTourEndTime
calculateSubTourTimeWindow
blockTravelTimeToSubTourLocation
constructTours
getRandomNodeInZone
getFirstNodeInZone
PredayManager Functions:
-
loadPersonIds
:- calls the following
populationDao
methods:getIncomeCategories
,getAddresses
andgetAllIds
- the corresponds SPs must exist in the database for Persons to be loaded successfully
- calls the following
-
loadZones
:- gets all parameters for zones from network database
-
loadZoneNodes
-
loadPostCodeNodeMapping
-
loadCosts
-
loadUnavailableODs
: loads the unavailable origin destination pairs; e.g for private modes:const std::string DB_GET_PVT_UNAVAILABLE_OD = "SELECT "+ DB_FIELD_TCOST_ORIGIN + ", " + DB_FIELD_TCOST_DESTINATION + " FROM " + DB_TABLE_TCOST_PVT + " WHERE info_unavailable = TRUE";
-
dispatchLT_Persons
:- Distributes long-term persons to different threads and starts the threads which process the persons
- Also accounts for single-threaded case
- Depending on what mode of preday is being run, one of these two functions are called:
computeLogsumsForLT_Population
(logsum mode) orprocessPersonsForLT_Population
(simulation mode).
Currently, getAddresses
executes the query in the SP synpop12.getaddresses_aditi()
:
CREATE OR REPLACE FUNCTION synpop12.getaddresses_aditi()
RETURNS TABLE(address_id bigint, postcode integer, taz_code integer, distance_mrt double precision, distance_bus double precision)
LANGUAGE plpgsql
AS $function$
BEGIN
RETURN QUERY
(
SELECT synpop12.sla_addresses.address_id,
cast(synpop12.sla_addresses.sla_postcode as integer),
demand.postcode_node_map.node_zone,
synpop12.postcode_amenities.distance_mrt,
synpop12.postcode_amenities.distance_bus
FROM synpop12.sla_addresses,demand.postcode_node_map,
synpop12.postcode_amenities
WHERE synpop12.sla_addresses.address_id =
synpop12.postcode_amenities.address_id
AND synpop12.sla_addresses.sla_postcode not in ('000000','999999','881091')
AND synpop12.sla_addresses.sla_postcode::bigint = demand.postcode_node_map.postcode
);
END;$function$
This SP returns the postcode ID, TAZ ID, MRT distance and Bus Distance for all address IDs for the population.
Here is an excerpt of the first 10 lines of output from the SP (select synpop12.getaddresses_aditi()
in psql
):
getaddresses_aditi
--------------------------------------
(1,0,23,1.65803739,0.986284272)
(2,1,17,1.688481697,0.176789371)
(3,2,17,4.155894104,2.496732718)
(4,3,18,3.448476969,0.935323782)
(5,4,24,0.462769223,0.44654096)
(6,5,7,0.867990472,0.590665825)
(7,6,21,2.460223466,0.696569724)
(8,7,20,1.72407327,1.432121356)
(9,8,19,3.726448416,1.868370401)
(10,9,20,3.569378391,2.09445594)
Below are snippets of the relevant tables.
demand.postcode_node_map
table:
postcode | postcode_zone | node_id | node_zone | node_postcode_distance
----------+---------------+---------+-----------+------------------------
0 | 23 | 51 | 23 | 99.57216822
1 | 17 | 45 | 17 | 628.5636693
2 | 17 | 90 | 17 | 176.5118655
3 | 18 | 92 | 18 | 430.1252246
4 | 24 | 62 | 24 | 167.7026194
The zones (TAZes) are subsets of the postcodes.
synpop12.sla_addresses
table:
address_id | sla_postcode | taz_id | x_coord | y_coord | primary_postcode | status_0812
------------+--------------+--------+---------------+---------------+------------------+-------------
1 | 0 | 23 | 366722.971678 | 138853.08784 | t | 0
2 | 1 | 17 | 370621.67408 | 139516.020701 | t | 0
3 | 2 | 17 | 374245.873626 | 139124.893613 | t | 0
4 | 3 | 18 | 373582.093849 | 142731.728244 | t | 0
5 | 4 | 24 | 370935.033375 | 143423.244607 | t | 0
6 | 5 | 7 | 367350.426553 | 143184.23181 | t | 0
7 | 6 | 21 | 367347.747512 | 146481.997364 | t | 0
8 | 7 | 20 | 370983.480189 | 146654.574143 | t | 0
The synpop12.postcode_amenities
table:
address_id | sla_postcode | taz_id | mrt_station | distance_mrt | distance_bus | distance_express | distance_pms30 | distance_cbd | distance_mall | mrt_200m | mrt_400m | express_200m | bus_200m | bus_400m | pms_1km
------------+--------------+--------+-------------+--------------+--------------+------------------+----------------+--------------+---------------+----------+----------+--------------+----------+----------+---------
1 | 0 | 23 | SC1 | 1.65803739 | 0.986284272 | 0.099572168 | 1.057905068 | 2.717167614 | 1.14 | f | f | t | f | f | f
2 | 1 | 17 | NS1 | 1.688481697 | 0.176789371 | 0.176789371 | 1.058097214 | 3.423081497 | 1.14 | f | f | t | t | f | f
3 | 2 | 17 | SC3 | 4.155894104 | 2.496732718 | 0.176511866 | 2.021189467 | 6.878215466 | 1.14 | f | f | t | f | f | f
4 | 3 | 18 | NS5 | 3.448476969 | 0.935323782 | 0.935323782 | 1.978261409 | 7.041848217 | 1.14 | f | f | f | f | f | f
5 | 4 | 24 | NS4/SC4 | 0.462769223 | 0.44654096 | 0.16770262 | 0.388305031 | 3.793507219 | 1.14 | f | f | t | f | f | t
6 | 5 | 7 | SC5 | 0.867990472 | 0.590665825 | 0.135579131 | 0.317977943 | 1.855746838 | 1.14 | f | f | t | f | f | t
7 | 6 | 21 | SC5 | 2.460223466 | 0.696569724 | 0.438422587 | 0.57903861 | 5.126539234 | 1.14 | f | f | f | f | f | t
8 | 7 | 20 | NS5 | 1.72407327 | 1.432121356 | 0.314532891 | 1.790862456 | 6.197386616 | 1.14 | f | f | f | f | f | f
It is important to note that in Virtual City, the postcodes have a one-to-one mapping with the addresses.
There are 217 postcodes in Virtual City and thus 217 addresses (IDs), as well.
PersonParams.hpp
private:
long addressId;
unsigned int postcode;
int tazCode;
double distanceBus; //km
double distanceMRT; //km