TripEnergy Implementation

TripEnergy Implementation in Simmobility

This document summarizes the changes made in Simmobility to implement TripEnergy for energy calculations as well as how to run Simmobility with the energy module activated. These changes build off of the changes made for the MITEI project, but are different in some respects. The TripEnergy functions and data are all pre-compiled and uploaded to github as a static library tripEnergySO.a, allowing Simmobility to access all of the functions required to calculate energy requirements in a way that is hopefully as efficient as if its source code were compiled with the rest of Simmobility.

How to Run Simmobility with Energy Model Active

This section gives instructions on how to run Simmobility MT and process the outputs, with a focus on where the procedure is different from a normal run.

Running Simmobility with TripEnergy

• In Simrun_Midterm.xml:
  • In the procedure mapping, change the day activity schedule procedure to <mapping name="day_activity_schedule" procedure="get_persons_between_veh"/>.
  • In the supply portion of the file, add the line <energy_model enabled="true" type="tripenergy" outputtrips="true" outputtripfile="energy_output.csv" outputlinks="true"/>. This turns on the energy model. outputtrips creates a new csv file (named by outputtripfile) with one entry for each completed trip, including information on vehicle type, trip distance and duration, and trip energy consumption. If outputlinks is true, there are also three new columns added to the segment output in out.txt that give the energy consumption on each link during each timestep, which can be further processed to visualize energy consumption. Note: the tripenergy model should only be run for Tripod-related projects. For questions, contact Sankaran at sankara@mit.edu.
• In the stored procedures:
  • Create/update a procedure get_persons_between_veh to load the current DAS with vehicle information. The difference here is that in loading agents to the network, a join is performed between the DAS table and the vehicle_0123 table in order to determine what specific vehicle type is driven by which individual. A list of which vehicle type IDs refer to which vehicle types is available in simmobility/dev/Basic/medium/models/tripEnergySO/allvehicle_info.txt. Each individual's vehicle type ID is then assigned to that individual's PersonParams object. If a different procedure needs to be used to load DAS, the lines performing the join from the stored get_persons_between_veh query should be added to the new procedure. Sample sql code is below:

CREATE OR REPLACE FUNCTION get_persons_between_veh(
    IN start_time numeric,
    IN end_time numeric)
  RETURNS TABLE(person_id character varying, tour_no integer, tour_type character varying, stop_no integer, stop_type character varying, 
      stop_location integer, stop_mode character varying, primary_stop boolean, arrival_time numeric, departure_time numeric, 
      prev_stop_location integer, prev_stop_departure_time numeric, prev_stop_taz integer, stop_taz integer, id bigint, ind_id bigint, 
      drivetrain character varying, make character varying, model character varying) AS
$BODY$
  select 
	person_id, 
	tour_no, 
	tour_type, 
	stop_no, 
	stop_type, 
	stop_location, 
	stop_mode, 
	primary_stop, 
	arrival_time, 
	departure_time, 
	prev_stop_location, 
	prev_stop_departure_time, 
	prev_stop_zone, 
	stop_zone,
	COALESCE(vehicle_0123.id,-1),
	COALESCE(vehicle_0123.ind_id,-1),
	COALESCE(cast(vehicle_0123.drivetrain as character varying),'-1'),
	COALESCE(vehicle_0123.make,'NULL'),
	COALESCE(vehicle_0123.model,'NULL')
    from demand.das_april18_pathprocess_90p
    left outer join synpop_boston_12.vehicle_0123 on cast(left(person_id, strpos(person_id, '-') - 1) as bigint) = vehicle_0123.ind_id
   where person_id in (
		select person_id 
		from demand.das_april18_pathprocess_90p 
		where prev_stop_departure_time 
			between $1 and $2 
			and tour_no = 1 
			and stop_no = 1)
   and stop_mode not like 'Park Ride' and stop_mode not like 'On Demand' and stop_mode not like 'Bike'
   order by person_id, tour_no, stop_no;

Processing outputs:

• Link-level outputs: Run simmobility/dev/Basic/processEnergy/summarizeOut.py. This is a (crude and inefficient) script that parses out.txt and outputs a simpler csv with one line for every timestep of the simulation. The line contains information on total distance driven, total time driven (i.e. number of vehicles on the road times the timestep duration), and total energy consumption (in Joules) during this timestep. These time-series energy use outputs can be compared to validation outputs from MOVES by running the matlab script simmobility/dev/Basic/processEnergy/compareGBAtoMOVES.m
• Trip-level outputs: Run simmobility/dev/Basic/processEnergy/makeSimmobilityPlots.m, which makes some plots based on energy_output.csv. Note: the energy information disaggregated by specific vehicle types only works for data from virtual city (where there are only 4 vehicle types active). This might also be a little bit buggy elsewhere. Also note, this only accounts for energy from completed trips, so total energy use info might be less than that reported by out.txt, perhaps significantly so if there is unresolved congestion.

Driver Movement Facet Class (And BusDriver Movement Facet)

We keep track of a vehicle's partial trajectory as well as its total distance and time traveled and energy use in the MovementFacet class for the mid-term driver role. An identical process is used for Bus Drivers.

Stored Info

• Partial Trajectory The previous three advance interval average speeds are stored in an array of length 3 called speedCollector.
• Trip Summary Information A running total of the trip's distance, total time, and energy consumption are kept in totalEnergyUsed, totalDistanceDriven, and totalTimeDriven.

New Functions

• Update Stored Trajectory The function onNewDriverVelocitySample() is called each new timestep for each vehicle on the network, taking as input the vehicle's average speed over that advance interval. This function adds the most recent advance interval average speed to the last position of the speedCollector array and shifts the previous two back one space, so that it now contains the average speeds for the current advance interval as well as the previous two. It is also called once at the end of a trip with an input of 0.0 to account for the vehicle stopping during the last timestep. The energy function is then called to calculate energy consumption during that timestep.
• Output Trip Summary Data New functions are created to return the stored values for the trip's distance, total time, and energy consumption: getTotalTime(), getTotalDistance(), and getTotalEnergy().

Energy Model Base Class

High level (mostly method agnostic) functions are defined for the energy model class. These placeholders are overwritten with TripEnergy-specific functions later. They are called within the driver movement facet class when a vehicle is advanced on the network.

Events During Supply Simulation

• Vehicle moves one advance interval One of two functions is called, either computeEnergyWithSpeedHolder() for a personal vehicle or computeBusEnergyWithSpeedHolder() for a bus. It then calculates the energy consumption represented by that three-speed array and returns the energy value, which the movement facet class then uses to update its running totals. An additional function, computeTrainEnergyWithSpeed() is currently in development. Because we are not using as detailed of an energy model for trains, the only information on train movement required is the average speed over a single advance interval. This function is currently also set up to take information on the train line and the occupancy of the train, both of which will be used in later updates to the energy model.
• Vehicle finishes trip When a trip is completed, the trip's total energy information, as well as other summary data such as speed and distance, are written to the energy output file.

TripEnergy Model Class

Loading Databases

TripEnergy requires access to data on vehicle characteristics and driving patterns that are collected elsewhere and summarized and aggregated offline. These are loaded just once at the beginning of the simulation and accessed by the energy functions whenever energy is calculated

• Vehicle Information An array of structs vehs contains information on 10694 different personal vehicles, including mass, drag coefficients, and engine efficiency. This is created by the function loadVehicles() just once when the TripEnergyModel is created.
• Driving Behavior An array called moments of length 438,976 contains information on typical high-resolution driving behavior for trips given different medium-resolution inputs. This is initialized empty and filled by the function loadDrivingSO(). An array called spdBins of length 38 is also created, and it defines the bins used in assigning high resolution driving behavior to simmobility trajectories.

Choosing Vehicle Types

TripEnergy calculates energy consumption for a trajectory using a set of very specific vehicle types, e.g. 2012 Toyota Camry. One option (used in virtual city) is for the vehicle types stored in the vehicles database table to consist only of different powertrain types (HEV, PHEV, BEV, ICEV, FCEV), and so the function convertToVehicleDatabaseId() translates these general powertrain types into IDs for specific vehicles in the TripEnergy vehicle data. Note that for now FCEVs are not included in the TripEnergy data, and PHEVs are not implemented fully (they can either be assumed to be operating in fully electric or fully gasoline powered mode, but the control logic behind switching modes is not implemented). The other option (used in GBA) is for the vehicle types (stored in the vehicles_0123 table) to consist of the actual vehicle type ID in allvehicle_info.txt.

Do Energy Calculations

• Read Input Params The function setupParamsVariables is called once at the beginning of the simulation to determine which sorts of output to generate, which are read from energy_model_params.xml (or whatever file is specified in Simrun_MidTerm.xml). The option trip_output = 1 will print a csv with a row for each trip. The option timestep_output will print a file with name "timestep_file".csv with a row for each vehicle, for each timestep (note, for now veh_type_ID and segment_output are no longer used).
• Smooth trajectory and call TripEnergy The functions computeEnergyWithSpeedHolder() and computeBusEnergyWithSpeedHolder() take in the speed collector and timestep length and output an energy estimate for the middle of 3 timesteps in the speed holder. computeEnergyWithSpeedHolder() (for personal vehicles) also takes a pointer to the person object, which is used to determine the vehicle type used for the trip. In these functions, the partial trajectory is first smoothed to remove extreme accelerations, and then it is combined with information on vehicle type to calculate energy. For the bus version, a single bus model is hard-coded in. Eventually, different bus types can be assigned to different routes based on the bus depots that serve each route.
• Internal TripEnergy Functions To calculate energy, an internal TripEnergy function so_script() is called and passed speedCollector, a vehicle type ID, as well as the input data moments and vehs or buses. so_script() processes the data further and calls another internal function getEnergy_TS_3d() which performs the driving behavior matching and the actual energy calculations. Another internal function histc() is called during this process.

Other Changes

• MT_Config.cpp Changed to read whether or not to use an energy model, as well as which one (in the mid_ftr_tripenergy branch "tripenergy" is the only option, but the MITEI branch will have multiple options).
• ParseMidTermConfigFile.cpp Also changes to read in energy model info
• ParseEnergyModelXmlConfig.cpp Read in the actual energy params file
• LinkStats.cpp Changes to output energy information for each link in out.txt. NOTE: These changes were not developed for Tripod and are untested and might not work.
• SegmentStats.cpp Similar to above, also not currently used.
• MesoPathMover.cpp Also changed to allow outputs at the link level.

TO DO

• Verify that bus trajectories are accurate. Most important, I still need to make sure that advance intervals where the bus is waiting at a stop are correctly added to partial trajectories.
• Add trains.