SILO Melbourne walk anomoly

[carlhiggs]

Looking into my copies of health indicator and traffic flow files created as part of HealthExposureModelMEL, I was struck by the outlying size.

This was for the Melbourne test example --- a small 231 person (100 household) subset of the actual Greater Melbourne (~4 million) person synthetic population that I have been struggling to process due to long processing times (eg see #159 ). So, the overall file sizes here are small, but the relative difference is the point --- walk takes longer to process, and its interesting that the walk files here have more data.

I wonder --- Are more people being routed further than they should by walk mode specifically for some reason, and is the cause of the longer processing times?

Let's look into it, first with the test data, noting that these files have not to date been able to be generated for Melbourne due to the outsize sample size meaning 'walk' is taking more than a week to process for a single day:

File sizes and number of records by mode for health indicators and traffic flows

type	mode	n_files	avg_size_kb	median_size_kb	avg_nrows	median_nrows	total_rows
healthIndicators	autoDriver	7	10.6	11.2	60.3	63.0	422
healthIndicators	autoPassenger	7	3.9	4.3	21.1	24.0	148
healthIndicators	bicycle	7	0.5	0.4	1.4	1.0	10
healthIndicators	pt	7	1.5	1.5	10.1	11.0	71
healthIndicators	walk	7	28.8	30.5	189.1	197.0	1324
traffic_flows	bike	7	6.8	3.4	498.6	249.0	3490
traffic_flows	car	7	522.3	561.9	36962.1	39749.0	258735
traffic_flows	walk	7	15651.0	15991.4	1116650.1	1141197.0	7816551

Without even looking at the content of these files, it is clear something is going wrong. It suggests that

• there are more walking trips than other modes combined, and
• those 231 persons are making walking trips over many more roads than other modes that would be expected to take you further

That is, these summary statistics of file sizes and number of records for health indicators and traffic flows suggest that more people seem to be walking than expected, and they are walking too far. This might explain the symptom of this mis-routing which we appear to be experiencing --- impossibly long walk processing times for health indicators. Perhaps this is a side-effect of mis-routing, for some reason.

Let's look further.

Number of links and activity duration for trips by mode (from health indicators)

Number of links (n)

mode	min	p25	p50	p75	max
autoDriver	10	248.75	414	571.75	1335
autoPassenger	60	366.5	582.5	898	1672
pt	0	0	0	0	0
bicycle	46	232	261.5	516	801
walk	0	576.25	6340	10215.25	22630

Activity duration (mins)

mode	min	p25	p50	p75	max
autoDriver	-1	5	43	284.75	726
autoPassenger	-1	7.5	50	246	670
pt	-1	34.5	118	409	583
bicycle	-1	-1	-1	-1	545
walk	-1	-1	35	142	785

As inferred from the file sizes of healthIndicators and traffic flows, looking at the health indicator data we see that travel times are longer than for other modes, and the number of links traverse an order of magnitude or two higher than for other modes including driving.

That's not plausible so we need to look into what is driving that.

While the Brunswick test example (20,000 people, but in an area of 56 SA1s, instead of 10,000 SA1s), as a small delimited study region processes much quicker, however the sizes of these files display the same pattern.

So, the Brunswick test example that runs SiloMEL and RunHealthExposureOffline each in ~9mins can be used instead to explore what might be giving rise to this instead of the Melbourne 100 household test data that runs the latter in 7.5 hours. If we can fix it for Brunswick, we can then run for the 100 household test data, that should then process much quicker giving confidence of proper processing times for Greater Melbourne.

matsimPlans

I'm not sure how best to approach analysing these XML documents, so have taken a crude approach ---- I opened up matsimPlan_Friday.xml that exists in the same folder for Brunswick and did count of occurances of different modes:

	Melbourne - 100hh (n)	Brunswick (n)
bike	0	3,009
car	154	19,126
walk	564	44,904

So, walk is an outlier there too

SiloMEL MATSim outputs

Going further upstream in the process, considering the outputs of SiloMEL.java that these are based on the file sizes for 2018.output_events.xml.gz on a Thursday for Brunswick is 6.6MB for carTruck, compared with 14.4MB for bikePed.

For the 100hh data across all Melbourne, its 53.1MB for carTruck, and 1.1MB for bikePed.

Its a bit confusing but --- it probably makes sense because the all Melbourne dataset contains all interstate freight, so quite a few truck trips; Brunswick restricted this to just Brunswick (very few). Brunswick has 20,000 people doing bikePed trips and the 100hh dataset 231 people. So maybe this looks like it makes sense.

I think more attention needs to be paid to how the RunExposureOfflineHealth events files are generated...

I'll look into this now, but so I don't accidentally lose the above, I'll add this comment now.

[carlhiggs]

The matsimPlans are actually generated through MITO as part of the SummarizeData7daysMEL, so perhaps whatever is causing this is that far upstream.

Looking at trips.csv, for both the 100 household and Brunswick tests, there are approx 3 times as many walking trips as car trips, which doesn't seem right.

BUT if I go back to a copy of trips.csv I have from August, walk counts are much lower and of shorter average duration for the same population:

	autoDriver	walk	bicycle	pt	autoPassenger
August - 100 household test
trips	841	374	87	184	559
duration	129.453	85.17647	62.56322	293.3043	104.3882
October - 100 household test
trips	422	1324	10	71	148
duration	161.6825	116.5733	106.4	217.8873	142.8514
October - Brunswick test
trips	38570	108195	8898	5773	18972
duration	205.7839	107.6191	217.8211	333.6648	139.3166

So, that's a big increase in proportion of walking trips, from August to October.

The big thing that happened in August was calibration...

[carlhiggs]

This might be a red herring --- the last calibration comparison i ran, evalauting the impact of switching from 10 to 5 calibration groups [^1] doesn't show this pattern, suggesting the change in distributions would have occurred later than 25 September when this HTML was generated:

https://jibeproject.github.io/trips-vis/trip_calibration_comparison%20-%20pre%20vs%205%20groups.html

Mode Share Comparison (%)

mode	Pre-Calibration	Post-Calibration	VISTA	VISTA_noWeight	improvement_pre_to_post	improvement_direction
Driving Car	44.8	44.8	45.9	50.4	0.07	Similar
Car Passenger	26.5	26.4	28.3	24.1	0.09	Similar
Public Transport	7	7.1	6.9	7.3	0.05	Similar
Walking	18.1	18.2	17.2	16.5	0.07	Similar
Cycling	3.6	3.6	1.8	1.7	0.04	Similar

So at that point in late September, the mode shares were as expected from MITO....

The change may have come later?

[carlhiggs]

Just a thought (noting here to look into it tomorrow), rather than being an issue in Mito, it's possible it could be in Silo's invocation of Mito. That could explain why the previous calibration comparison looked fine (it was generated directly from Mito). Perhaps trips.csv generated via silo might differ than the calibrated version generated directly from Mito. I should confirm this. If they differ, the issue might be in the silo Mito MATsim runner.

I'll check this out tomorrow.

[carlhiggs]

Re MITO, I just ran this for Brunswick and checked out the resulting trips.csv: it effectively displays the same counts/durations, albeit with some small differences to the SILO-generated that must relate to the MITO MATsim runner implementation / differences in random seed for simulation:

mode	MITO trips.csv count (2025-10-30)	duration
autoDriver	42373	210.8046
autoPassenger	20517	130.5912
bicycle	10473	200.4905
pt	6531	327.1651
walk	102512	116.344

mode	SILO trips.csv count (2025-10-28)	duration
autoDriver	38570	205.7839
autoPassenger	18972	139.3166
bicycle	8898	217.8211
pt	5773	333.6648
walk	108195	107.6191

The slight difference notwithstanding, this does suggest that the higher than expected proportion of walking trips (which may account for processing of walking trips being apparently unprocessable for Greater Melbourne) arises in the MITO process at some point, rather than SILO.

One thing worth considering/looking into is whether the changes in trip counts relate to recent replacement of the coefficient look up in MITO and SILO with hard-coded coefficients (#169 ). This involved changes for utility functions by purpose; in principle the results should be unchanged (it was intended to change how these were looked up, not the values, as I suspected this could have been a bottle neck). But it should be checked out that this change didn't unintentionally cause the change in trip counts. If that were the case, it would be an unrelated/coincidental issue to the long processing time for walk (as this motivated that change).

[carlhiggs]

fwiw,

16 September SILO results (full population) had expected proportions of mode share:

> trips <- fread("C:/Users/E33390/OneDrive - RMIT University/General - JIBE working group/melbourne/simulationResults/SILO - 2025-09-16/1_reference/microData/trips.csv")
|--------------------------------------------------|
|==================================================|
> mode_summary <- trips[
+ , .(n = .N,
+ pct = 100 * .N / nrow(trips),
+ avg_activity_duration = mean(activity_duration, na.rm = TRUE)),
+ by = mode
+ ][, .(mode, n, pct, avg_activity_duration)]
> mode_summary
            mode        n       pct avg_activity_duration
          <char>    <int>     <num>                 <num>
1:    autoDriver 15604207 44.725379             139.50506
2:       bicycle  1184882  3.396154              94.01367
3:            pt  2298721  6.588683             267.29680
4:          walk  6395500 18.331028              87.91844
5: autoPassenger  9405622 26.958756             112.17008
> 

Actually, so does the full population that was processing on EC2 up to this week (21 October 2025; just copied to shared drive off the EC2 via S3 yesterday):

> trips <- fread("C:/Users/E33390/OneDrive - RMIT University/General - JIBE working group/melbourne/simulationResults/SILO - 2025-10-21/base/2018/microData/trips.csv")
|--------------------------------------------------|
|==================================================|
> mode_summary <- trips[
+ , .(n = .N,
+ pct = 100 * .N / nrow(trips),
+ avg_activity_duration = mean(activity_duration, na.rm = TRUE)),
+ by = mode
+ ][, .(mode, n, pct, avg_activity_duration)]
> mode_summary
            mode        n       pct avg_activity_duration
          <char>    <int>     <num>                 <num>
1:    autoDriver 15600830 44.715691             139.53575
2:       bicycle  1188583  3.406762              93.87316
3:            pt  2290725  6.565763             268.18926
4:          walk  6397000 18.335324              87.87677
5: autoPassenger  9411801 26.976461             112.13527

So maybe this is all a red herring. These are both runs that proved impossibly long to process due to walk times --- and there aren't excessive walk results in trips.csv.

It seemed a convenient theory that maybe we couldn't find the reason in the health exposure model because the cause of long processing times was upstream. But perhaps those trip proportions were not as expected purely because they were using test cases, not the full population.

The full population results using the most recent versions of the software, and older, look as they should.

So on reflection I think something in the health exposure model is the issue - not MITO.

[carlhiggs]

An update following exploration after catch up with @Qinnnnn and @CorinStaves, who suggested logging the individual trips --- great suggestion. I have done this for the 100 random household Melbourne example that takes 7.5 hours to complete the exposure health analysis for 231 persons with 1904 trips.

I'm not exactly sure of the implications but have found some interesting insights, I think that could be leads potentially (time to follow, notwithstanding).

I confirmed that walking trips are the issue --- it was strongly suspected before, but now confirmed in the table below.

Short story of leads after finding something interesting

After left joining the trip log info with processing duration to trips.csv I found that trips with outlying duration all had t.distance_walk, t.distance_bike and t.distance_auto < 0.2 (specifically, set as 0.19946). I don't know if this relationship will hold for Greater Melbourne (worth a look), but this is a strong lead for the test data.

As per below plot (with log10 axes displaying linear values), all trips having processing duration longer than 1.2 seconds had t.distance_* of 0.19946. Its not the full story --- in itself, durations with that distance are spread. However, having t.distance_walk greater than that value is clearly predictive of not having a long duration.

Looks like something is wrong for trips to have that 0.19946 value.

There is something else wrong (some microdestination Y coordinates appear to have X coordinate like pattern; needs investigating). I've noted this below. I will investigate and fix this, but this does not appear to influence duration (the minority of trips with origins or destinations having apparently coordinate issues were under 3 minutes, most under 1 minute; i.e. the long trips all had valid coordinates).

Long story told while exploring

In particular I explored NA values for departure_time_return (RRT, NHBO, NHBW) as I noticed that the trip with maximum processing time had NA duration. I believe the NA for duration is added in MITO here; but also, after looking at the below I think its just coincidence and not related --- NAs only accounts for less than a third of processing time (2.4 hours, out of 6.6 hours for walk trips in total).

Note that I believe the walk-skewed trip distribution here is due to my artificial very small example in which I have configured use of modified small size skims to fit processing within memory constraints on my local computer. However, this test serves as a good (quicker/cheaper running) proxy for the full analysis that is commensurately slower and is yet to complete.

Most walking trips take 30 seconds, but a minority take up to an hour per trip.

	n	%	Duration (minutes)	Hours
			Average	Max
EndTime
N/A	497	26.1	0.29	58.28
not N/A	1407	73.9	0.18	18.40
Mode
autoDriver	422	22.2	0.002	0.014
autoPassenger	148	7.8	0.004	0.016
bicycle	10	0.5	0.008	0.016
walk	1324	69.5	0.300	58.279
TOTAL	1904	100.0	0.209	58.279
Mode==walk
N/As	374	28.2	0.379	58.3
not N/As	950	71.8	0.269	18.4

So, walking trips account for 6.6 hours of the processing time (that's most of it).  

However, as per below table, fewer than 6% of the walking trips (77/1324) take up 5.5 of those 6.6 hours (83%).

Walk processing minutes	<=	>	Duration hours total
	n	%	n
0.5	1206	91.1	118
1	1247	94.2	77
2	1279	96.6	45
4	1304	98.5	20
8	1316	99.4	8
16	1321	99.8	3
32	1323	99.9	1

This means we could look at the characteristics of the 5 longest trips perhaps as case studies

Other things that need to be fixed

While exploring I noticed that there are a number of micro destinations listed in the trip analysis with anomolous Y coordinates. Neither X nor Y coordinates are associated with duration I believe (good), but I picked up on the error from the following plots:

A minority of Y coordinates appear to be in the domain of the X coordinates:

That will need to be fixed, and is a separate issue (they aren't long to process).

[UPDATE 2025-11-06: this actually is an issue that was previously addressed, except for in the 100 household test microdata subset; I will update the 100 household test microdata with the corrected schools.]

[Qinnnnn]

Hi Carl,
Thanks for your deep analysis. It is useful for further diagnose the issue.

As I remember, the value of 0.19946 is set to all the intrazonal trips that have origin and destination in the same zone. (@CorinStaves, do you remember why we set it as this value?).

Based on your plots, I have two thoughts:

1. it is abnormal to have so many intrazonal trips in a such small test dataset. We need to review the MITO outcome (e.g. share of intrazonal trips by mode, trip length distribution by mode)

2. Intrazonal trips usually shouldn't cause issues in routing. We also have intrazonal walk trips in Manchester but they didn't cause long processing issue. I still have the gut feeling that the issue might associate with memory allocation/thread process.

To get some further insights, could you share the following files with me?

• MITO trips.csv file
• Silo log file
• the logging of individual trips if they are not traced in the silo log file
• snapshot of memory allocation

[carlhiggs]

Thanks Qin --- I'll follow up on e-mail with these files on Monday after doing some corrections specific to the 100 household test dataset, so we aren't misled.

Great to know about interzonal trip aspect. I think the interzonal trips will be influenced by using modified OD matrix skims for the test case -- I restricted to only those zones containing home_SA1, school_SA1, and work_SA1 locations for randomly selected households for development test purposes only, so that I could run the analysis on my local computer with 64GB of RAM. Using the full Melbourne skims I was running out of RAM running it locally. I did this for an initial test case of 10 households, but then increased the sample for 100 households, but apparently didn't increase the skim size, which was an oversight. The 100 household test was still using the 10 household skim matrices with 36 zones.

Prior to returning to the 100 household test data, I had been using the Brunswick suburb only test region (20,000 persons) as a more realistic and fast running test dataset. That has skim matrices just restricted to SA1s within the Brunswick SA2. The walk time issue isn't as apparent in that data though, I believe because it is confied to a single SA2. For that reason, I switched for this analysis to the earlier 100 household test scenario.

Looking into the Y coordinate issue I noted above, that related to an earlier issue with schools that I previously addressed for the main analysis, and the Brunswick test analysis. Aparently I overlooked correcting this in the 100 household test data (jibeproject/syntheticPopulationMelbourne#39).

I'll aim to re-run the tests on AWS with the 100 hh dataset (so it is quicker to run) with the full Melbourne skims and using the updated version of school microdata. I can try commenting out the path calculation as you previously suggested, as I've corrected the bit of code required to ensure there are attempts to have 0 partitions.

[carlhiggs]

Hi @Qinnnnn @CorinStaves, as per above, I corrected the school data for the 100hh test microdata (this was already correct for Greater Melbourne, but during diagnostics I realised I hadn't corrected this for the older test dataset). I re-ran both SiloMEL and RunExposureHealthOffline, and this has improved things for the test data, with run time of approximately 3.5 hours, instead of 7.5 hours. I have saved the outputs in the JIBE working group Melbourne folder in a sub-folder under simulation results (I'll send link in an e-mail).

So --- while there are some long running trips now, there are notably fewer; only 8 longer than 1 minute, compared to 77 previously.

Of the 8 trips with duration > 8 minutes, they were all walking trips. One had duration of 37 minutes, two had duration of 14 mins, one of about 10 minutes, and the others 3 minutes or less. So, a small number of outlying trips for the 100 household data, but it seems for Greater Melbourne they must add up.

These trips were HBR, NHBO and NHBW trip purposes; HBR seems more likely to have the longer duration:

I also noticed, 203 records in my processed dataset linking logs with trips.csv didn't have duration estimates; I think this means that for whatever reason the log record for those trips didn't get called. I'm not yet sure why. I've saved a copy of the linked dataset in the simulation results too (the log file derived columns including duration and memory estimates are at the far right of the columns).

Here are the top 8 duration records:

hh.id	p.ID	t.id	originZone	originType	originId	originX	originY	destinationZone	destinationType	destinationId	destinationX	destinationY	t.purpose	t.distance_walk	t.distance_bike	t.distance_auto	time_auto	time_pt	time_walk	time_bike	mode	departure_day	departure_time	activity_duration	departure_time_return	Day	Mode	StartTime	EndTime	Duration (ms)	StartMemory (MB)	EndMemory (MB)	MemoryDelta (MB)	StartCPU (ms)	EndCPU (ms)	CPUTime (ms)	Duration (mins)	has_duration
1325846	3588205	815	2113322	household	1325846	321877.2	5807862	2112935	poi	1398	322521.1	5805353	HBR	2.762402	2.762346	2.8136	2.990855	12.01436	63.08041	8.823256	walk	wednesday	710	67	840	thursday	walk	42600s	49260s	2239458	58841	56007	-2833	0	2211000	2211000	37.3243	TRUE
1363876	3784483	1605	2130518	poi	2965	346386.3	5789666	2119540	poi	3772	332040.7	5806357	NHBO	0.279512	0.279512	0.421068	0.51416	5.666265	5.708455	1.392173	walk	friday	689	-1	NA	thursday	walk	41340s	NA	858216	58135	54165	-3969	0	841812	841812	14.3036	TRUE
1084349	2166798	1596	2129328	poi	581	354889.9	5789178	2145414	poi	49	346067.7	5794621	NHBO	0.279512	0.279512	0.421068	0.51416	5.666265	5.708455	1.392173	walk	saturday	591	-1	NA	saturday	walk	35460s	NA	840522	57280	57852	571	0	825578	825578	14.0087	TRUE
1084349	2166798	1598	2129328	poi	581	354889.9	5789178	2137218	poi	3536	339281.1	5775674	NHBO	0.279512	0.279512	0.421068	0.51416	5.666265	5.708455	1.392173	walk	saturday	751	-1	NA	saturday	walk	45060s	NA	590484	58025	55758	-2266	1171	582968	581796	9.8414	TRUE
1393568	3949113	1346	2142801	poi	2011	326426.7	5821360	2113356	poi	2235	322088.2	5807854	NHBW	0.279512	0.279512	0.421068	0.51416	5.666265	5.708455	1.392173	walk	saturday	465	-1	NA	saturday	walk	27900s	NA	168939	57275	57904	629	0	166750	166750	2.81565	TRUE
110340	615889	821	2116510	household	110340	333913.5	5808723	2131906	poi	592	334034.1	5808321	HBR	0.65385	0.651938	0.670489	0.764375	18.75381	14.93215	2.452442	walk	friday	680	52	746	thursday	walk	40800s	44400s	158969	58135	56896	-1239	0	150875	150875	2.649483	TRUE
1318778	3531921	1521	2113733	poi	965	323618.3	5810137	2112623	poi	602	320211.1	5811825	NHBO	0.279512	0.279512	0.421068	0.51416	5.666265	5.708455	1.392173	walk	thursday	590	-1	NA	thursday	walk	35400s	NA	133643	55924	54878	-1046	796	133203	132406	2.227383	TRUE
1251180	3123757	1319	2110602	job	11209	321326.7	5816940	2113345	poi	1326	322237.4	5806965	NHBW	3.461076	3.460715	3.526063	3.938176	14.12656	76.27906	11.32087	walk	monday	938	-1	NA	thursday	walk	56280s	NA	100110	56845	56609	-236	0	95984	95984	1.6685	TRUE

In case of use for the exploration here is the section of code where I've defined walk weights -- HBA isn't defined, because that's not defined for walking in the RunSkimsMelbourne file that these values are drawn from. But I don't think that's the issue, because NHBW and NHBO do have values defined, and some of the longer trips relate to those.

silo/useCases/melbourne/src/main/java/de/tum/bgu/msm/health/MatsimTransportModelMELHealth.java

Lines 475 to 510 in 305dfd8

	// Walk weights
	Function<org.matsim.api.core.v01.population.Person,double[]> walkWeights = p -> {
	switch ((Purpose) p.getAttributes().getAttribute("purpose")) {
	case HBW -> {
	// https://github.com/jibeproject/matsim-jibe/blob/3d1a34d60a9a1aae5945967b728d5254ba596dd6/src/main/java/skim/RunSkimsMelbourne.java#L131
	return new double[]{0, 2.2560371};
	}
	case HBE -> {
	// https://github.com/jibeproject/matsim-jibe/blob/3d1a34d60a9a1aae5945967b728d5254ba596dd6/src/main/java/skim/RunSkimsMelbourne.java#L140
	return new double[]{0, 0.8270912};
	}
	case HBR -> {
	if ((int) p.getAttributes().getAttribute("age") < 16) {
	// https://github.com/jibeproject/matsim-jibe/blob/3d1a34d60a9a1aae5945967b728d5254ba596dd6/src/main/java/skim/RunSkimsMelbourne.java#L151
	return new double[] {0.6866997, 0.6779886 + 1.0379374};
	} else {
	// https://github.com/jibeproject/matsim-jibe/blob/3d1a34d60a9a1aae5945967b728d5254ba596dd6/src/main/java/skim/RunSkimsMelbourne.java#L150
	return new double[] {0.6866997, 0.6779886};
	}
	}
	case HBS, HBO -> {
	// https://github.com/jibeproject/matsim-jibe/blob/3d1a34d60a9a1aae5945967b728d5254ba596dd6/src/main/java/skim/RunSkimsMelbourne.java#L162C120-L162C132
	return new double[]{0, 0.3421390};
	}
	case NHBW -> {
	// https://github.com/jibeproject/matsim-jibe/blob/3d1a34d60a9a1aae5945967b728d5254ba596dd6/src/main/java/skim/RunSkimsMelbourne.java#L176
	return new double[]{0, 4.3210968};
	}
	case NHBO -> {
	// https://github.com/jibeproject/matsim-jibe/blob/3d1a34d60a9a1aae5945967b728d5254ba596dd6/src/main/java/skim/RunSkimsMelbourne.java#L184
	return new double[]{0, 5.7158683};
	}
	default -> {
	return null;
	}

I was curious if duration related to distance between coordinates and derived a quick Euclidean distance estimate to check this independent of travel distance/time estimates ---- interestingly, they are relatively short trips. In particular, the one that took longer than half an hour was for a destination only 2.6km away. However, most trips of up to 100km were processed in seconds.

The above plots were generated using a quick Shiny dashboard mock up; its not perfect, rather quick and dirty but in case of use, I've put a copy of that in the shared folder too. It accepts a trips.csv file, and if available a log file containing the specific log warnings I introduced for monitoring trips, and allows download of the processed data (I included a copy).

I'm still stumped with what might distinguish the longer trips here, so love to hear your thoughts!

[carlhiggs]

I looked further at the analysis outputs from the above run.

First, distribution of trips by travel mode makes more sense now:

However, after looking at the exposure data and summarising the distribution, outlying values become apparent for total travel time (equivalent to 95 days), negative time at home and upper end of mmetHr for walk:

Exposure/outcome variable percentile distribution summary

	0	25	50	75	100
totalTravelTime_sec	0.0	8447.8	18504.6	230955.7	8227111.5
totalTravelTime (hours)*	0.0	2.3	5.1	64.2	2285.3
totalActivityTime_min	0.0	227.5	772.0	1803.5	4549.0
totalTimeAtHome_min	-15542.5	7008.8	8266.9	9439.7	10080.0
severeFatalInjuryCar	0.0	0.0	0.0	0.0	0.1
severeFatalInjuryBike	0.0	0.0	0.0	0.0	0.0
severeFatalInjuryWalk	0.0	0.0	0.0	0.0	0.0
mmetHr_walk	0.0	0.0	1.8	158.9	4772.5
mmetHr_cycle	0.0	0.0	0.0	0.0	129.7
mmetHr_otherSport	0.0	0.0	14.3	17.5	22.8
exposure_normalised_pm25	9.9	12.5	13.7	18.2	57.5
exposure_normalised_no2	8.6	12.0	15.0	23.1	64.4
exposure_normalised_noise_Lden	7.1	31.3	39.0	52.5	194.1
exposure_normalised_ndvi	0.2	0.4	0.4	0.6	1.5
exposure_noise_HA	7.9	9.5	13.8	28.4	762.1
exposure_noise_HSD	2.1	2.4	3.4	7.7	13.5

*derived

The excessive total travel time was not immediately obvious previously with travel time in seconds, but is clear once rescaled to hours and days.

The individual with 95 days travel time across 7 days is a synthetic population child (#3784483) also had a negative totalTimeAtHome_min of -14628.8, and was one of the 14 minute processing time trips.

There were 62 individuals (/231) with total travel time across 7 days greater than one day, and 55 with total travel time greater than 7 days.

Looking further, the 5 longest processing durations were of individuals classed as 'unemployed for occupation ¹:

and (the important bit) they are all female:

And looking at this aspects combined, it seems that it might be unemployed, females doing NHBW, NHBO and HBR walk trips that dominate long processing times:

Some trips for other occupations undertaken by females also can take a few minutes, but employment seems to exacerbate.

So there is something perhaps in how demographics are contributing to trip times.... And I expect this pattern is magnified in the Greater Melbourne data, the long processing times being a symptom of some demographic-based misconfiguration somewhere.

Footnotes

1. There is a classification scenario that is a bit odd which I noticed--- children who are not students have been classed as 'unemployed' -- i.e. the child with 95 days travel time is an unemployed 1 year old... I am not sure how else they should be classified though of the four occupation values.. perhaps -1 instead? ↩

[CorinStaves]

Very interesting diagnostics but agree still a mystery. At this stage the next thing I would do is filter down to just to the problematic trips and start to debug exactly where the problem is occurring. Of course that's only possible if there's not too much stochasticity and trips are the same each time. If not, an alternative could be to have the debugger break after a something takes longer than e.g., 60s, and investigate from there. Happy to set up / look at this together over a call.

A couple new things that come to mind too:

1. I wonder if it's possible to test changing the router back to FastDijkstra and rerunning? Since these are all shorter trips, perhaps MATSim's A* algorithms is getting confused for some reason (unlikely but worth testing)

2. Both NHBW/NHBO have very high link weights for speed limit, have we checked this is attribute is never negative on the network? (and there's nothing else the might be causing final link cost to be negative for walk trips)

[carlhiggs]

Thanks @CorinStaves great suggestions to look into! I am at a conference this week, so not much scope to look in depth right now, but can look into this when back in Melbourne.

I had a quick look at speed limit (carSpeedLimitMPH) and there are no negative values (range is 3.1 to 68.4 MPH; that's about 5 km/h to 105 km/h which sounds about right). I also looked at width while I was at it; I don't expect it should effect walking (although I don't know) but mentioning as odd/surprising that 9% of edges (104745/1160050) have width of zero (none negative though).

I don't expect the width will impact walking, and I expect there is a good reason it was done, but wanted to check as there were car routing warnings that perhaps related to this --- so at risk of conflating issues, I'd love to hear your thoughts if this is a problem/explanation for the below (excerpt below; there are many many of the 'DefaultTurnAcceptanceLogic' type warnings, as per #66 )

2025-11-08T18:51:36,783  WARN QueueWithBuffer:499 Link 108293out too small: enlarge storage capacity from: 0.7733333333333334 Vehicles to: 1.74 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,783  WARN QueueWithBuffer:499 Link 108293rtn too small: enlarge storage capacity from: 0.7733333333333334 Vehicles to: 1.74 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,783  WARN QueueWithBuffer:499 Link 108294out too small: enlarge storage capacity from: 0.45333333333333337 Vehicles to: 1.0200000000000002 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,783  WARN QueueWithBuffer:499 Link 108294rtn too small: enlarge storage capacity from: 0.45333333333333337 Vehicles to: 1.0200000000000002 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,783  WARN QueueWithBuffer:499 Link 108295out too small: enlarge storage capacity from: 0.5333333333333333 Vehicles to: 1.2000000000000002 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,783  WARN QueueWithBuffer:499 Link 108295rtn too small: enlarge storage capacity from: 0.5333333333333333 Vehicles to: 1.2000000000000002 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,783  WARN QueueWithBuffer:499 Link 108296out too small: enlarge storage capacity from: 0.18666666666666668 Vehicles to: 0.42000000000000004 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,783  WARN QueueWithBuffer:499 Link 108296rtn too small: enlarge storage capacity from: 0.18666666666666668 Vehicles to: 0.42000000000000004 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,783  WARN QueueWithBuffer:499 Link 108297out too small: enlarge storage capacity from: 0.5866666666666667 Vehicles to: 1.3200000000000003 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,784  WARN QueueWithBuffer:499 Link 108297rtn too small: enlarge storage capacity from: 0.5866666666666667 Vehicles to: 1.3200000000000003 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,784  WARN QueueWithBuffer:499 Link 108298out too small: enlarge storage capacity from: 0.6133333333333334 Vehicles to: 1.3800000000000003 Vehicles.  This is not fatal, but modifies the traffic flow dynamics.
2025-11-08T18:51:36,784  WARN QueueWithBuffer:502 Additional warnings of this type are suppressed.
2025-11-08T18:51:39,787  WARN DefaultTurnAcceptanceLogic:55 Cannot move vehicle x10_9918_truck from link 109785out to link 520493out
2025-11-08T18:51:39,787  WARN DefaultTurnAcceptanceLogic:55 Cannot move vehicle x10_7580_truck from link 527762out to link 737302rtn
2025-11-08T18:51:39,789  WARN DefaultTurnAcceptanceLogic:55 Cannot move vehicle x10_16909_truck from link 259884out to link 259878out
2025-11-08T18:51:39,790  WARN DefaultTurnAcceptanceLogic:55 Cannot move vehicle x10_13920_truck from link 159785out to link 17596rtn
2025-11-08T18:51:39,790  WARN DefaultTurnAcceptanceLogic:55 Cannot move vehicle x10_19145_truck from link 157567out to link 796807out
2025-11-08T18:51:39,790  WARN DefaultTurnAcceptanceLogic:55 Cannot move vehicle x10_17782_truck from link 192903out to link 447060out
2025-11-08T18:51:39,790  WARN DefaultTurnAcceptanceLogic:55 Cannot move vehicle x10_3528_truck from link 104678out to link 159791out
2025-11-08T18:51:39,790  WARN DefaultTurnAcceptanceLogic:55 Cannot move vehicle x10_10308_truck from link 131655out to link 324096out

[carlhiggs]

Update for @Qinnnnn @CorinStaves @BelenZapata85 --- following a catch up with Qin, I re-ran the exposure analysis using a modified trips.csv file only containing the 8 outlying trips from the 100 household test data that had durations > 1 minute. The idea was, if the durations of processing of these trips was notably reduced compared to the full run, the issue would be largely attributable to system resources (less constrained, presumably, processing fewer trips). Conversely, if durations were largely replicable for these trips, then the issue would appear to relate more to interaction between data and code.

Here are the log excerpts from the relevant trip metrics before and after restriction to the 8 trips:

full 100 household exposure analysis, from 11 November (as reported above)

2025-11-11T00:48:40,509  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1346, Day: saturday, Mode: walk, StartTime: 27900s, EndTime: N/As, Duration: 165204ms, StartMemory: 56098MB, EndMemory: 53865MB, MemoryDelta: -2232MB, StartCPU: 15ms, EndCPU: 160453ms, CPUTime: 160437ms
2025-11-11T00:54:35,542  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1598, Day: saturday, Mode: walk, StartTime: 45060s, EndTime: N/As, Duration: 518883ms, StartMemory: 54390MB, EndMemory: 57408MB, MemoryDelta: 3017MB, StartCPU: 1109ms, EndCPU: 511718ms, CPUTime: 510609ms
2025-11-11T00:58:27,563  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1596, Day: saturday, Mode: walk, StartTime: 35460s, EndTime: N/As, Duration: 752248ms, StartMemory: 56103MB, EndMemory: 57483MB, MemoryDelta: 1380MB, StartCPU: 15ms, EndCPU: 737718ms, CPUTime: 737703ms
2025-11-11T01:27:49,628  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1605, Day: thursday, Mode: walk, StartTime: 41340s, EndTime: N/As, Duration: 795089ms, StartMemory: 55873MB, EndMemory: 53691MB, MemoryDelta: -2182MB, StartCPU: 0ms, EndCPU: 782296ms, CPUTime: 782296ms
2025-11-11T01:46:54,933  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1521, Day: thursday, Mode: walk, StartTime: 35400s, EndTime: N/As, Duration: 142150ms, StartMemory: 55558MB, EndMemory: 55033MB, MemoryDelta: -525MB, StartCPU: 968ms, EndCPU: 141937ms, CPUTime: 140968ms
2025-11-11T02:04:16,090  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1311, Day: thursday, Mode: walk, StartTime: 51780s, EndTime: N/As, Duration: 56734ms, StartMemory: 56429MB, EndMemory: 55273MB, MemoryDelta: -1155MB, StartCPU: 312ms, EndCPU: 56562ms, CPUTime: 56250ms
2025-11-11T02:41:48,377  WARN HealthExposureModelMEL:932 Trip metrics - ID: 815, Day: thursday, Mode: walk, StartTime: 42600s, EndTime: 49260s, Duration: 2309340ms, StartMemory: 56340MB, EndMemory: 54915MB, MemoryDelta: -1425MB, StartCPU: 15ms, EndCPU: 2271843ms, CPUTime: 2271828ms
2025-11-11T03:16:21,651  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1319, Day: thursday, Mode: walk, StartTime: 56280s, EndTime: N/As, Duration: 102475ms, StartMemory: 55644MB, EndMemory: 54842MB, MemoryDelta: -801MB, StartCPU: 0ms, EndCPU: 98921ms, CPUTime: 98921ms

running only the 8 trip analysis, from 1 December (new restricted analysis)

2025-12-01T19:15:55,329  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1346, Day: saturday, Mode: walk, StartTime: 27900s, EndTime: N/As, Duration: 148944ms, StartMemory: 54009MB, EndMemory: 54540MB, MemoryDelta: 530MB, StartCPU: 0ms, EndCPU: 146328ms, CPUTime: 146328ms
2025-12-01T19:22:05,108  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1598, Day: saturday, Mode: walk, StartTime: 45060s, EndTime: N/As, Duration: 518711ms, StartMemory: 54009MB, EndMemory: 52863MB, MemoryDelta: -1146MB, StartCPU: 0ms, EndCPU: 508656ms, CPUTime: 508656ms
2025-12-01T19:25:43,055  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1596, Day: saturday, Mode: walk, StartTime: 35460s, EndTime: N/As, Duration: 736671ms, StartMemory: 54009MB, EndMemory: 55454MB, MemoryDelta: 1444MB, StartCPU: 0ms, EndCPU: 722703ms, CPUTime: 722703ms
2025-12-01T19:50:52,349  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1605, Day: thursday, Mode: walk, StartTime: 41340s, EndTime: N/As, Duration: 808937ms, StartMemory: 54981MB, EndMemory: 52157MB, MemoryDelta: -2823MB, StartCPU: 15ms, EndCPU: 796187ms, CPUTime: 796171ms
2025-12-01T20:04:51,111  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1521, Day: thursday, Mode: walk, StartTime: 35400s, EndTime: N/As, Duration: 133841ms, StartMemory: 55434MB, EndMemory: 53009MB, MemoryDelta: -2424MB, StartCPU: 0ms, EndCPU: 130546ms, CPUTime: 130546ms
2025-12-01T20:17:45,018  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1311, Day: thursday, Mode: walk, StartTime: 51780s, EndTime: N/As, Duration: 53846ms, StartMemory: 52480MB, EndMemory: 52516MB, MemoryDelta: 35MB, StartCPU: 0ms, EndCPU: 52343ms, CPUTime: 52343ms
2025-12-01T20:54:31,486  WARN HealthExposureModelMEL:932 Trip metrics - ID: 815, Day: thursday, Mode: walk, StartTime: 42600s, EndTime: 49260s, Duration: 2260318ms, StartMemory: 52480MB, EndMemory: 51233MB, MemoryDelta: -1246MB, StartCPU: 0ms, EndCPU: 2223203ms, CPUTime: 2223203ms
2025-12-01T21:19:26,456  WARN HealthExposureModelMEL:932 Trip metrics - ID: 1319, Day: thursday, Mode: walk, StartTime: 56280s, EndTime: N/As, Duration: 101035ms, StartMemory: 54762MB, EndMemory: 53300MB, MemoryDelta: -1461MB, StartCPU: 0ms, EndCPU: 95156ms, CPUTime: 95156ms

So, excerpting the above and scaling from ms to minutes for duration (overall duration of processing and CPU time are basically the same, latter is slightly less), we see there is little difference in duration between the runs:

ID	2025-11-11 (duration mins)	2025-12-01 (duration mins)	after-before (mins)	after/before *100
1346	2.8	2.5	-0.3	89.3
1598	8.6	8.6	0.0	100.0
1596	12.5	12.3	-0.2	98.4
1605	13.3	13.5	0.2	101.5
1521	2.4	2.2	-0.2	91.7
1311	0.9	0.9	0.0	100.0
815	38.5	37.7	-0.8	97.9
1319	1.7	1.7	0.0	100.0

The repeat run durations are quicker in general, but not meaningfully so. In one instance, the duration was longer, implying some of the difference observed is noise relating to the system state from other processes running, or other sources of randomness.

To me it seems that there is indeed something peculiar about these trips/agents. The characteristics of which are summarised in a table below merged from trips, pp and exposure files).

p.ID	hh.id	t.id	originZone	originType	originId	originX	originY	destinationZone	destinationType	destinationId	destinationX	destinationY	t.purpose	t.distance_walk	t.distance_bike	t.distance_auto	time_auto	time_pt	time_walk	time_bike	mode	departure_day	departure_time	activity_duration	departure_time_return	Day	Mode	StartTime	EndTime	Duration (ms)	StartMemory (MB)	EndMemory (MB)	MemoryDelta (MB)	StartCPU (ms)	EndCPU (ms)	CPUTime (ms)	Duration (mins)	has_duration	hhid	age	gender	ethnic	relationship	occupation	driversLicence	workplace	income	schoolId	home_SA1	school_SA1	work_SA1	long_duration
3588205	1325846	815	2113322	household	1325846	321877.24	5807862.2	2112935	poi	1398	322521.07	5805353.4	HBR	2.7624015	2.7623462	2.8136	2.9908547	12.01436	63.080411	8.8232563	walk	wednesday	710	67	840	thursday	walk	42600s	49260s	2239458	58841	56007	-2833	0	2211000	2211000	37.3243	TRUE	1325846	34	Female	NA	married	2	NA	-1	98852	NA	2.061E+10	NA	NA	TRUE
3784483	1363876	1605	2130518	poi	2965	346386.26	5789666.4	2119540	poi	3772	332040.75	5806357	NHBO	0.2795123	0.2795123	0.4210678	0.5141599	5.6662649	5.7084545	1.3921726	walk	friday	689	-1	NA	thursday	walk	41340s	NA	858216	58135	54165	-3969	0	841812	841812	14.3036	TRUE	1363876	1	Female	NA	u15_child	0	NA	-1	98852	NA	2.07E+10	NA	NA	TRUE
2166798	1084349	1596	2129328	poi	581	354889.91	5789178.2	2145414	poi	49	346067.69	5794620.6	NHBO	0.2795123	0.2795123	0.4210678	0.5141599	5.6662649	5.7084545	1.3921726	walk	saturday	591	-1	NA	saturday	walk	35460s	NA	840522	57280	57852	571	0	825578	825578	14.0087	TRUE	1084349	43	Female	NA	married	2	NA	-1	98852	NA	2.09E+10	NA	NA	TRUE
2166798	1084349	1598	2129328	poi	581	354889.91	5789178.2	2137218	poi	3536	339281.06	5775673.8	NHBO	0.2795123	0.2795123	0.4210678	0.5141599	5.6662649	5.7084545	1.3921726	walk	saturday	751	-1	NA	saturday	walk	45060s	NA	590484	58025	55758	-2266	1171	582968	581796	9.8414	TRUE	1084349	43	Female	NA	married	2	NA	-1	98852	NA	2.09E+10	NA	NA	TRUE
3949113	1393568	1346	2142801	poi	2011	326426.69	5821359.5	2113356	poi	2235	322088.22	5807853.6	NHBW	0.2795123	0.2795123	0.4210678	0.5141599	5.6662649	5.7084545	1.3921726	walk	saturday	465	-1	NA	saturday	walk	27900s	NA	168939	57275	57904	629	0	166750	166750	2.81565	TRUE	1393568	22	Female	NA	o15_child	2	NA	-1	98852	NA	2.111E+10	NA	NA	TRUE
615889	110340	821	2116510	household	110340	333913.46	5808722.9	2131906	poi	592	334034.13	5808321.2	HBR	0.6538504	0.6519384	0.670489	0.7643753	18.753815	14.932148	2.4524418	walk	friday	680	52	746	thursday	walk	40800s	44400s	158969	58135	56896	-1239	0	150875	150875	2.6494833	TRUE	110340	67	Female	NA	relative	4	NA	-1	98852	NA	2.07E+10	NA	NA	TRUE
3531921	1318778	1521	2113733	poi	965	323618.35	5810136.7	2112623	poi	602	320211.1	5811824.8	NHBO	0.2795123	0.2795123	0.4210678	0.5141599	5.6662649	5.7084545	1.3921726	walk	thursday	590	-1	NA	thursday	walk	35400s	NA	133643	55924	54878	-1046	796	133203	132406	2.2273833	TRUE	1318778	50	Female	NA	lone_parent	1	NA	628355	98852	NA	2.13E+10	NA	2.061E+10	TRUE
3123757	1251180	1319	2110602	job	11209	321326.7	5816940.4	2113345	poi	1326	322237.36	5806965.4	NHBW	3.4610765	3.460715	3.5260634	3.9381758	14.12656	76.279061	11.320866	walk	monday	938	-1	NA	thursday	walk	56280s	NA	100110	56845	56609	-236	0	95984	95984	1.6685	TRUE	1251180	44	Female	NA	lone_parent	1	NA	11209	98852	NA	2.09E+10	NA	2.06E+10	TRUE

To sum up characteristics in common, these are

• walking trips
• by females
• half of whom were unemployed (4), employed (2), retired (1), or toddlers (1; I've since corrected the occupation classification for agents < 6 years, which might change routing if SiloMEL were run again); not students
• of different ages (1 to 67; I am hopeful with the occupation fix, toddlers won't be walking so far...)
• for discretionary purposes (HBR, NHBO, NHBO)
• going from POIs, households or jobs
• going to POIs (see below)
• POIs are of type eating establishments, recreation, social and culture, or primary health care

I couldn't perceive any obvious spatial patterning that could explain longer processing times; trips were distributed about the city (this was a random sample of households, not accounting for spatial clustering, so its representative perhaps that more households are in inner areas with higher population density).

In the below screenshot, origins are greens, destinations are orange, both are annotated with trip details (id, from, to and duration) and POIs (smaller circles) are overlaid that if zoomed in would show their type (at this scale, the text mostly doesn't appear, but are listed above).

Here are the details of POIs associated with the origins and destinations of the eight outlying trips:

type	X	Y	WEIGHT	Attribute	zone	id	WT	code	HBW	HBE	HBA	HBO	HBR	HBS	NHBO	NHBW
eating_establishments	346067.7	5794621	0.010939	bar	21202145414	49	0.104588	EE	0.449246	0	0	0	0.179057	0.284989	0.130917	0.290034
eating_establishments	320211.1	5811825	19.988	bar	20604112623	602	4.470794	EE	19.20376	0	0	0	7.654098	12.18232	5.596266	12.39796
eating_establishments	326426.7	5821360	9.786688	cafe	20902142801	2011	3.128368	EE	13.43753	0	0	0	5.355835	8.524385	3.915899	8.675277
eating_establishments	346386.3	5789666	0.009003	cafe	21203130518	2965	0.094883	EE	0.407557	0	0	0	0.162441	0.258542	0.118768	0.263119
eating_establishments	339281.1	5775674	1.783372	cafe	21401137218	3536	1.33543	EE	5.736177	0	0	0	2.286285	3.638867	1.671609	3.703279
eating_establishments	332040.7	5806357	0.653839	cafe	20804119540	3772	0.808603	EE	3.473257	0	0	0	1.384346	2.203335	1.01216	2.242337
primary_health_care	354889.9	5789178	0.025392	day procedure centre	21202129328	581	0.159348	PHC	2.119934	0	0.60028	0.522947	0	0	0.235104	1.099006
recreation	334034.1	5808321	0.047353	gym	21205131906	592	0.466485	RSPF	0	0	0	0	1.862365	0	0.353849	0.316602
recreation	323618.3	5810137	0.709028	gym	20606113733	965	0.917626	RSPF	0	0	0	0	3.663473	0	0.69606	0.62279
recreation	322521.1	5805353	0.090906	gym	20605112935	1398	0.549096	RSPF	0	0	0	0	2.192178	0	0.416514	0.37267
social_and_culture	322237.4	5806965	0.055447	hall	20605113345	1326	0.485254	SCL	11.55618	0	0	0.302424	0	0	0.066533	5.452575
social_and_culture	322088.2	5807854	0.204195	tourist attraction	20605113356	2235	0.672219	SCL	16.00869	0	0	0.418945	0	0	0.092168	7.553412

There is a potential source of oddity with destinations in that their IDs are only unique within their type and not overall -- so POI ID might be ambiguous. This can be seen in the below where I initially restricted micro destinations to the POI IDs listed as origins and destinations --- I had to select the below using spatial location intersection with origins and destinations to get the actual POIs as used in the trips as these weren't otherwise identifiable from the log data I extracted (its possible that SILO differentiates these using the type attribute; but mentioning in case you think the implementation of microdestinations could be contributing to this issue). In the following image you can see the duplicate ID POIs across Melbourne sharing the IDs of POIs actually used as origins and destinations (selected in yellow):

Looking at the network (not shown here), things seem to broadly make sense (except for widths perhaps, as above, but I don't expect that would impact walking).

I'm not really sure where to go from here with this, so any advice is welcome @Qinnnnn and @CorinStaves. I had a brief look into replacing the A* algorithm (SpeedyAlt) with FastDijkstra, but the implementations look a bit different so I wasn't sure if my changing of the code would cause more problems than solutions --- so I haven't tried changing this yet.

My feeling is there is probably some unexpected data pattern or code used to interpret data in some contexts that isn't as it should be, and that perhaps whatever this is, it might stand out to you Qin and Corin being more familiar with the MATSim/MITO/SILO stack.

Thank you for your help looking into this!