-
Notifications
You must be signed in to change notification settings - Fork 29
Mid Term Configuration
Simrun_MidTerm.xml is a configuration file specific to mid-term. This file allows users to configure
- Database from which the network is loaded
- Names of database functions (stored procedures) through which the various components of the network are loaded
- [Pre-day, within-day and supply model] (Mid-Term-Parameters) specific parameters
The first configuration is to specify the run-mode for mid-term.
<mid_term_run_mode value="withinday"/> <!-- Admissible values are "preday", "withinday"-->This configuration is used to determine whether to run preday or withinday+supply of mid-term.
The next section of the file contains groupings of the stored procedures that are used to load the demand, various components of the network and pathsets into the simulation. Each grouping is called a proc_map which is identified by a unique id. The structure can be seen in the example below.
<db_proc_groups>
<proc_map id="singapore" format="aimsun">
<!-- network -->
<mapping name="nodes" procedure="get_test_singapore_nodes()"/>
<mapping name="links" procedure="get_singapore_links()"/>
<mapping name="turning_groups" procedure="get_test_singapore_turning_groups()"/>
<mapping name="turning_paths" procedure="get_test_singapore_turning_paths()"/>
<mapping name="turning_polylines" procedure="get_test_singapore_turning_polylines()"/>
<mapping name="turning_conflicts" procedure="get_test_singapore_turning_conflicts()"/>
<mapping name="road_segments" procedure="get_test_singapore_road_segments()"/>
<mapping name="segment_polylines" procedure="get_test_singapore_segment_polylines()"/>
<mapping name="lanes" procedure="get_test_singapore_lanes()"/>
<mapping name="lane_polylines" procedure="get_test_singapore_lane_polylines()"/>
<mapping name="lane_connectors" procedure="get_test_singapore_lane_connectors()"/>
<mapping name="screen_line" procedure="get_screen_line_segments()"/>
<!-- public transit -->
<mapping name="bus_stops" procedure="get_singapore_bus_stops_17feb()"/>
<mapping name="pt_bus_dispatch_freq" procedure="get_pt_bus_frequency()"/>
<mapping name="pt_bus_routes" procedure="get_pt_bus_routes_17feb()"/>
<mapping name="pt_bus_stops" procedure="get_pt_bus_stops_17feb()"/>
<mapping name="mrt_road_segments" procedure="get_pt_mrt_segments()"/>
<!-- route choice -->
<mapping name="pt_stop_stats" procedure="get_pt_stop_stats()"/>
<mapping name="pt_vertices" procedure="get_pt_map_trvertices()"/>
<mapping name="pt_edges" procedure="get_pt_map_tredges()"/>
<mapping name="rail_transit_edges" procedure="get_rail_transit_edges()"/>
<mapping name="erp_gantry_zone" procedure="get_erp_gantry_zone()"/>
<mapping name="erp_section" procedure="get_erp_section()"/>
<mapping name="erp_surcharge" procedure="get_erp_surcharge()"/>
<mapping name="pt_pathset" procedure="get_pt_trpathset"/>
<mapping name="pvt_pathset" procedure="get_pvt_pathset"/>
<!-- demand -->
<mapping name="day_activity_schedule" procedure="get_persons_between"/>
<mapping name="freight_trips" procedure="get_testfreight_between"/>
<!-- to be enabled when running mid-term to extract trip-chains for short-term
<mapping name="restricted_reg_segments" procedure="get_section_banned_area()"/>
<mapping name="restricted_reg_nodes" procedure="get_restricted_region_nodes()"/>
-->
</proc_map>
.
.
.
</db_proc_groups> In the system section, the databases holding the road network and population data are specified. A sample is below.
<system>
<network_database database="dbid_from_simulation_xml" credentials="cred_id_from_simulation_xml" proc_map="proc_map_id_from_db_proc_groups"/>
<population_database database="long_term_dbid_from_simulation_xml" credentials="long_term_cred_id_from_simulation_xml" proc_map=""/>
<generic_props>
<!-- <property key="sampleproperty" value="samplevalue"/> -->
</generic_props>
</system>The element above specifies the unique identifiers for the database connection parameters and the corresponding credentials:
-
network_databaseshould point to the database where the road network, demand, pathsets and other pertinent data are stored. Theproc_mapattribute must point to a valid proc_map id from thedb_proc_groupssection of the same configuration file. Thedatabasevalue must correspond to theidof one of the<database>tags specified insimulation.xml. Similarly, thecredentialsvalue must correspond to theidof one of theplaintext-credentialorfile-based-credentialstags specified insimulation.xml. -
population_databasepoints to the database which hosts the population data from long-term. Note that theproc_mapattribute is left blank. This is because the queries to fetch data from the long-term database are directly programmed in the SimMobility source-code files. The values you insert asdatabaseandcredentialsmust have a correspondence withsimulation.xml, as explained in the bullet above. - There is also a
generic_propselement undersystemto allow developers to quickly add and test configurations for new features.
The workers section is for specifying the workgroup types and pertinent properties of the workgroups. A work group is a collection of worker threads which manage similar agent entities and perform similar kind of processing in the simulation. Sample of this section is as follows.
<workers>
<person count="7" granularity="5 seconds"/>
</workers>The only workgroup type that is used in mid-term at the moment is the person workgroup. This work group manages all person agents in the simulation and takes care of their processing. The count attribute is used to specify the number of threads to be created within this work group. The granularity attribute is used to specify the wall-clock time interval which this work group is to be processed in every time step of the simulation. The granularity must be a multiple of the base granularity specified in simulation.xml.
In order to enable buses in the simulation, the busControlle should be enabled. Moreover, it is important to make sure that the stored procedures pertinent to bus dispatch frequency, bus routes and bus stops are provided in the configured proc_map. The busline_control_type attribute is used to specify the control strategy for buses to reduce bus bunching. It can take values such as "headway_based", "evenheadway_based", "hybrid_based", or (default) "no_control". The value "headway_based" is commonly used; it avoids bus bunching by making consecutive buses on the same line maintain a specific headway. The format is as follows.
<busController enabled="true" busline_control_type="headway_based"/>The relative path of pathset_config.xml file is specified in the pathset_config_file element. This file contains configurations for pathset generation. See here for more details.
<pathset_config_file value="data/pathset_config.xml" />This config is used for enabling region restriction for private vehicles. The region must be pre-defined and kept in the database. The corresponding functions must be provided in the configured proc_map.
<region_restriction enabled="false"/>generateBusRoutes should be enabled to generate the bus routes based on stops data for each bus line. Bus route generation needs to be run once, only when adding new stops or new bus lines.
<generateBusRoutes enabled="false" />The travel_time_update specifies the frequency for which the output file link_travel_time will be updated. The sample configuration below specifies that the travel time output must be collected for 5 minute intervals (300 seconds).
<travel_time_update interval= "300"/>This element is used, for testing purposes, to completely prevent any agent from making trips in public transit modes. Note that this configuration does not however prevent buses and trains from running as per schedule. Setting this to true will prevent loading of the public transit graph and hence no agent will be able to choose a PT route. Any person agent in the demand who wants to do a bus or MRT trip is thrown out of the simulation.
<public_transit enabled="true"/>This element is used to configure trips, activities and sub trips output while running withinday. The enabled attribute is used to turn on/off the trip chain output. The trip_activities_file attribute is used to specify the file name for storing trips and activities information. The sub_trips_file attribute is used to specify the file name for storing sub trips information.
<trip_chain_output enabled="true" trip_activities_file="trip_activities.csv" sub_trips_file="sub_trips.csv"/>The supply holds the configuration settings that are specific to supply simulator.
<!-- config specific to supply simulator -->
<supply>
<!-- frequency of segment density, speed and flow output -->
<update_interval value="1" units="minute" />
<!-- these parameters are used to calculate dwell time of buses at bus stops-->
<dwell_time_parameters>
<!--parameters : minimum and maximum of fixed dwelling time, minimum and maximum of individual dwelling time-->
<parameters value="0.0, 0.0, 2.0, 3.0"/>
</dwell_time_parameters>
<!-- pedestrian walking speed in kmph -->
<pedestrian_walk_speed value="5"/>
<!-- default capacity value -->
<bus_default_capacity value="100"/>
<!-- file names to output statistics from supply -->
<output_statistics>
<journey_time file="journeytime.csv"/>
<waiting_time file="waitingtime.csv"/>
<waiting_count file="waitingcount.csv"/>
<travel_time file="traveltime.csv"/>
<pt_stop_stats file="ptstopstats.csv"/>
<subtrip_metrics file="subtrip_metrics.csv" enabled="true"/>
<screen_line_count file="screen_line_count.csv" enabled="true" interval="900"/>
<microsim_output enabled="true" segFilter="get_microsim_output_segment_id()" />
</output_statistics>
<!-- link category wise parameters used in speed density function -->
<speed_density_params>
<param category="1" alpha="3.0" beta="1.5" kmin="0.04" kjam="0.2"/>
<param category="2" alpha="3.0" beta="1.5" kmin="0.04" kjam="0.2"/>
<param category="3" alpha="3.0" beta="1.5" kmin="0.04" kjam="0.2"/>
<param category="4" alpha="3.0" beta="1.5" kmin="0.04" kjam="0.2"/>
<param category="5" alpha="3.0" beta="1.5" kmin="0.04" kjam="0.2"/>
<param category="6" alpha="3.0" beta="1.5" kmin="0.04" kjam="0.2"/>
<param category="7" alpha="3.0" beta="1.5" kmin="0.04" kjam="0.2"/>
</speed_density_params>
<!-- lua scripts used in withinday -->
<model_scripts path="scripts/lua/mid/behavior-models/" format="lua">
<script name="logit" file="logit.lua"/> <!--The main logit code for multinomial and nested logit models-->
<script name="pvtrc" file="pvtrc.lua"/> <!--private traffic route choice-->
<script name="ptrc" file="ptrc.lua"/> <!--public transit route choice-->
<script name="wdmw" file="wdmw.lua"/> <!--within-day mode choice for work trips-->
<script name="wdme" file="wdme.lua"/> <!--within-day mode choice for education trips-->
<script name="wdmso" file="wdmso.lua"/> <!--within-day mode choice for work shopping and other trips-->
</model_scripts>
</supply>Inline comments explaining each configuration are provided in the snippet above.
The supply section is followed by the preday section. This section holds the configuration settings that are specific to preday model. Explanatory comments are provided inline in the sample below.
<!-- config specific to preday simulator -->
<preday>
<!-- Control variable to run simulation, logsum computation and calibration. Admissible values are "simulation", "logsum" and "calibration" -->
<run_mode value="simulation"/>
<!-- Number of threads to create for processing the population in the preday demand simulator -->
<threads value="6"/>
<!-- prints person ids and tour details in console for each person if enabled -->
<console_output enabled="true"/>
<!-- table containing logsums for each individual in the population.
NOTE: This table is populated in logsum computation mode and used as input in simulation mode -->
<logsum_table name="demand.preday_logsum"/>
<!-- choice model scripts for preday -->
<model_scripts path="scripts/lua/mid/behavior-models/virtualcity" format="lua">
<script name="logit" file="logit.lua"/> <!--The main logit code for multinomial and nested logit models-->
<script name="dpb" file="dpb.lua"/> <!-- Day Pattern Binary -->
<script name="dpt" file="dpt.lua"/> <!-- Day Pattern Tours -->
<script name="dps" file="dps.lua"/> <!-- Day Pattern Stops -->
<script name="ntw" file="ntw.lua"/> <!-- Number Of Tours Work -->
<script name="nte" file="nte.lua"/> <!-- Number Of Tours Education -->
<script name="nts" file="nts.lua"/> <!--Number Of Tours Shopping -->
<script name="nto" file="nto.lua"/> <!--Number Of Tours Others -->
<script name="uw" file="tuw.lua"/> <!--Attend Usual Work -->
<script name="tmw" file="tmw.lua"/> <!--Tour Mode Work -->
<script name="tme" file="tme.lua"/> <!--Tour Mode Education -->
<script name="tmdw" file="tmdw.lua"/> <!--Tour Mode/Destination Work -->
<script name="tmds" file="tmds.lua"/> <!--Tour Mode/Destination Shopping -->
<script name="tmdo" file="tmdo.lua"/> <!--Tour Mode/Destination Others -->
<script name="ttdw" file="ttdw.lua"/> <!--Tour Time Of Day Work -->
<script name="ttdo" file="ttdo.lua"/> <!--Tour Time Of Day Others -->
<script name="ttde" file="ttde.lua"/> <!--Tour Time Of Day Education -->
<script name="tws" file="tws.lua"/> <!--Work Based Sub-Tours -->
<script name="stmd" file="stmd.lua"/> <!--Work Based Sub-Tours Mode/Destination-->
<script name="sttd" file="sttd.lua"/> <!--Work Based Sub-Tours Time Of Day-->
<script name="isg" file="isg.lua"/> <!--Intermediate Stop Generation -->
<script name="imd" file="imd.lua"/> <!--Intermediate Stop Mode/Destination -->
<script name="itd" file="itd.lua"/> <!--Intermediate Stop Time Of Day -->
<script name="zpa" file="zpa.lua"/> <!--Zone postcode assignment -->
</model_scripts>
<!-- preday calibration related parameters -->
<calibration enabled="false">
<!-- variables to calibrate -->
<!-- expected csv format: variable_name,lua_file_name,initial_value,lower_limit,upper_limit -->
<variables file="data/medium/preday_calibration_variables.csv"/>
<!--csv providing the observed values for the statistics to compute-->
<observed_statistics file="data/medium/preday_observed_HITS08_statistics.csv"/>
<!-- which calibration technique to use: SPSA/WSPSA -->
<calibration_technique value="SPSA"/>
<!-- logsums will be recomputed every x iterations if value is set to x -->
<logsum_computation_frequency value="5"/>
<SPSA>
<!-- max number of iterations that spsa must run for -->
<iterations value="20"/>
<!-- termination condition for spsa is (F(X_k+1) - F(X_k) <= tolerance ) where F(X) is the objective function -->
<tolerence value="0.000001"/>
<!-- perturbation step size for iteration k is given by c_k = c / ((1+k)^gamma) -->
<gradient_step_size initial_value="0.1" algorithm_coefficient2="0.101"/>
<!-- step size for iteration k is given by a_k = a / ((1+k)^alpha) -->
<step_size initial_value="0.16" stability_constant="100" algorithm_coefficient1="0.602"/>
</SPSA>
<WSPSA>
<!-- max number of iterations that spsa must run for -->
<iterations value="20"/>
<!-- termination condition for spsa is (F(X_k+1) - F(X_k) <= tolerance ) where F(X) is the objective function -->
<tolerence value="0.000001"/>
<!-- perturbation step size for iteration k is given by c_k = c / ((1+k)^gamma) -->
<gradient_step_size initial_value="0.1" algorithm_coefficient2="0.101"/>
<!-- step size for iteration k is given by a_k = a / ((1+k)^alpha) -->
<step_size initial_value="0.16" stability_constant="100" algorithm_coefficient1="0.602"/>
<!-- csv containing the weight matrix-->
<weight_matrix file="data/medium/preday_calibration_weight_matrix.csv"/>
</WSPSA>
<!-- output file to track the statistics and parameters for every iteration of calibration -->
<output file="preday_calibration_out.csv"/>
</calibration>
</preday>####Notes:
-
run_modecontrols the mode of execution of preday, to run simulation, calibration or logsum computation of the preday model. The values that run_mode take are "simulation", "calibration" and "logsum" respectively. - Preday is highly parallel. The input population can be divided equally among the threads and each thread can run completely independent of the others. The number of threads that are to be created for the preday demand simulator is specified in
threads. - If
console_outputis enabled, the person id and tour details for each person is printed on the console. -
calibrationsection holds all the configuration settings that are related to calibration of the pre-day model. This section is seldom used as calibration of preday model alone does not make much sense. Usually, mid-term is calibrated as a whole.