Occupancy KPI - capacity issues, effect of population sample size

[val-ismaili]

Comments apply to TE simulations

time java -Xmx120g -jar target/gelato-0.0.1-alpha-with-dependencies-eb19697.jar \
-mc /mnt/efs/simulations_refresh/10pc/workdist_5km_20230826/200/output_config.xml \
-mo /mnt/efs/simulations_refresh/10pc/workdist_5km_20230826/200 \
-o /mnt/efs/analysis/vi/gelato/baseline

1. kpi-occupancy-rate.csv presents as effectively infinite. This is due to the inclusion of taxis that are listed as capacity = 0 but Mean [numberOfPeople] = 1 (see intermediate-occupancy-rate.csv)

2. Seems possible for other vehicles to exceed an occupancy rate of 1. See veh_50192_bus which listed in intermediate-occupancy-rate.csv has a capacity = 14 but Mean [numberOfPeople] = 14.9433198380566. I'm unclear on the cause of this - could it be the inclusion of the driver (unsure if / how we handle this)?

3. capacity of bus and rail are listed as 14 and 200 respectively. As I understand, capacity is being pulled from the transit vehicle file input to matsim. The current calculation of occupancy works for PT if we are lowering the real capacity of PT vehicles to be in-line with the simulation population size. If this is not accounted for, we need to enable a method to account for scaling capacities based on population sample size. This seems like a place users are likely to trip up over so maybe worth a note in the documentation on the method / requirements?

[divyasharma-arup]

@syhwawa to check if the capacity of taxi should be 1, also check if any other modes have strange capacity settings.
@divyasharma-arup to look into the max number of people on different modes.

[syhwawa]

Hey, @val-ismaili @divyasharma-arup

1. In the Transport East simulations, the 'taxi' mode has been defined as an expensive 'car' in the matsim config rather than a PT mode, and no capacity value was set for the taxi. I think the actual capacity for a taxi should be considered as 1, reflecting the typical number of passengers a taxi serves per trip, excluding the driver.

2. From the Paris-East Galato intermediate-occupancy-rate.csv outputs, no bus occupancy rates exceeding 1 were observed. There are some occupancy rate values close to 1. This situation might be a modeling artifact rather than a realistic outcome, or when the code calculates the rate, it does count the driver which the capacity doesn't count driver(code), or there are outliers or variations from the outputs.

3. Regarding the setup of the capacity of modes in the simulations, you're correct. The PCE (Passenger Car Equivalent) value in the output_transitvehicles.xml is often scaled to fit with the population scale. This approach is documented lightly in the MATSim Bible.

[divyasharma-arup]

hi @syhwawa, would you be able to add details to KPI_Data_Requirements_and_Expectations.md as to where should a user ensure the capacity for vehicles are correct when configuring MATSim for the Occupancy KPI? This should include guidance on scaling.
I believe we've concluded that the occupancy for vehicles do not include the driver, therefore the capacity setting should not include driver either.

[divyasharma-arup]

Typo on my part, @KasiaKoz, the occupancy for vehicles likey includes driver, but we're not sure how that works for each mode. Below are the requested action items to refine the occupancy KPI:

• Ensure users are clear about the assumptions we make on the capacity of a vehicle: that it does not include driver, and all modes should have a non-zero capacity value set.
• Determine how to confirm whether or not each mode has a "transit driver" or similar (does DRT have a concept of a "transit driver")?
• For the modes that we have identified as having a driver, remove that driver from the occupacny metrics (assuming capacity does not have the driver included either). Removing the driver could simply be subtracting 1 from the occupancy count (or starting these vehicles with a -1 occupancy?). Or it might mean parsing through the events to find where the person_id == veh_id for specific modes.
• How do we handle scaling of capacity and agents? For now, recommend we document this, but need to determine if this is something we should solve for to ensure accuracy of KPI outputs.