Topic: Calibrating the passenger factor

[jamespetts]

Note: Although I have posted this on the Simutrans-Experimental board, much of this relates equally to Simutrans-Standard, as the code for calculating passenger and mail quantities is not distinct between the two. The reference to hourly quantities in the linked spreadsheet, however, is relevant only to Experimental.

Following discussion of the excessive passenger numbers in the recent Bridgewater-Brunel Simutrans-Experimental online game, I decided to look into the code to work out exactly how the passenger and mail generation is calculated to work out some bases for calibration. It turns out that, in simple terms, the code works like this: assuming a bits per month setting of 18 and a passenger factor setting of 8, each building in a city will be stepped once per month. Increasing the passenger factor from 8 to 9 will increase the monthly stepping from 1x per building to 1.112x, 10 will give 1.125x, 11 137.5x and so forth. Increasing the bits per month by 1 will double this number, but will also double the month length, and vice versa on decreasing it by 1.

Each step will generate exactly one packet. This packet might be either mail or passengers and can contain one or more of either mail or passengers (but not both). Each packet has a 3/4 chance of being a passenger packet and 1/4 chance of being a mail packet. The number of passengers or bags of mail in the packet is determined by the passenger/mail level shown in the building's dialogue box. For passengers, 6 is added to the level, and the resulting number divided by four. For mail, 8 is added to the level, and the resulting number is divided by 8. Fractions are rounded down to the nearest whole number. This has the consequence that buildings with a passenger/mail level of zero still generate passengers and mail, and still generate passengers and mail at exactly the same rate (1 unit per packet in both cases) as buildings with a level of 1. It takes a mail level of 8 to increase this number beyond 1 for mail, and a passenger level of 2 to reach a packet size of 2, and of 6 to reach a packet size of 3. Any intermediate numbers have precisely the same effect as the next number down: in other words, building levels [0 and 1], [2,3,4 and 5], and [6,7,8 and 9] all have exactly the same effect on passenger generation as each other and building levels [0,1,2,3,4,5,6 and 7] and building levels [8,9,10,11,12,13,14, and 15] all have exactly the same effect on mail generation as each other. I should note that the passenger factor affects what level that buildings are set to be.

Adding these together, a town with 100 buildings (a small but solid town in Simutrans terms) each of level 0 or 1 will produce 75 passengers and 25 bags of mail per month if the passenger factor is 8 and the bits per month setting is 18. However, at the settings currently in use on the Bridgewater-Brunel server (taken from Pak128.Britain-Ex 0.8.4), being a passenger factor of 10 and a bits per month setting of 21, in a town with 100 buildings all of which have a level of 0 or 1, 750 passengers and 250 bags of mail would be generated each month.

If we assume an average generation of 1.25 packets per step on the basis that some significant number of buildings will be at level 2 or over, we get 937.5 passengers per month and 312.5 bags of mail per month. A town of 200 buildings, not an uncommon size for a larger town, would have figures of twice this level: 1,875 passengers and 625 bags of mail per month.

Not all of these passengers and bags of mail would be transported, of course: many would not be able to reach their destination at all or in time, but even at a rate of 16% for passengers and 18% for mail (which are the percentages actually transported from the town of Caringford in the online game), this still gives numbers of 150 passengers per month for a 100 building town or 300 passengers for a 200 building town, and 56 bags of mail per month for a 100 building town or 112 bags of mail per month for a 200 building town. (In fact, these figures underestimate the load, because every town has a town hall of at least level three, and often has attractions, such as a church, which has a level of 12: the real figures for Caringford, a town of 134 buildings, are 1,917 passengers generated of which 442 were transported in the last complete month as at the date of writing).

Whilst these figures may not seem very great at first glance, it does well to bear in mind that a Simutrans-Experimental month is defined in terms of a certain number of hours and minutes, and that the frequency of services is measured according to those hours and minutes rather than according to the number of months. In the current online game, following the default for Pak128.Britain-Ex 0.8.4, the bits per month setting is 21, with the result that there are 6 hours and 24 minutes (or 6.4 hours) in every month. 442 passengers and 645 bags of mail (also the most recent figure from Caringford) every 6.4 hours equates to 69 passengers and 100 bags of mail being transported every hour, and a total of 300 passengers and 74 bags of mail being generated every hour that might be transported if the networks were capable of it. For a game year of 1800, this seems rather excessive, and seems to account in part for the very great passenger and mail numbers seen in the game.

I attach this spreadsheet (in .ods format) to show my calculations in reaching these figures, and to encourage experimentation to suggest an optimum passenger factor as well as any refinements to the code better to simulate all of this more accurately.

Edit: I forgot one important feature of the passenger generation algorithm in the above description (and spreadsheet): return journeys. Every passenger trip other than one between two points in the same town generates a return trip. That is, if a passenger packet is generated at stop A bound for stop B, then, unless stop A and stop B are in the same town, a packet of the same size is automatically generated at stop B bound for stop A at the same time. This has the effect of substantially increasing the number of passengers over and above what the above calculations indicated.

[Junna]

Interesting. But how would one go about allowing for an increase in the total number of journeys as they become less time-consuming and as general income levels increases, towards the latter half of the 1800's (if one was to cut the passenger factor)?

If only we could simulate ticket prices, the demand could be regulated by increasing them to discourage excessive traffic (and certainly would add a very interesting dimension to multi-player games, if one has the ability to handle the flow satisfyingly.)

[jamespetts]

Journey time tolerance is intended to have this effect for passengers.

[Carl]

A little data from my GB map which might be interesting/useful.

This map runs at 23 bits per month (because of the low metres per tile -- 118 -- this yields a 12 hour month). The passenger_factor is set to 1. With realistic service patterns and convoy capacities, I find that this is *just about* a suitable figure -- if anything it yields slightly too large passenger volumes.

I'm sure this is partly because of the high bits per month figure, but I have thought for a while that it would be nice if this value was more fine-grained (and if values below the current '1' were available).

Of course, one can also mitigate passenger levels by fiddling with "alternate destinations" and passenger journey time tolerances, which is what I'll have to do on the GB map if passenger numbers start to get really out of hand.

[Milko]

Hello James

This document is very well done! (I almost understood everything even if my English leaves much to be desired ...  ). I suggest putting it among the documents in evidence.

Giuseppe

[jamespetts]

A little data from my GB map which might be interesting/useful.

This map runs at 23 bits per month (because of the low metres per tile -- 118 -- this yields a 12 hour month). The passenger_factor is set to 1. With realistic service patterns and convoy capacities, I find that this is *just about* a suitable figure -- if anything it yields slightly too large passenger volumes.

I'm sure this is partly because of the high bits per month figure, but I have thought for a while that it would be nice if this value was more fine-grained (and if values below the current '1' were available).

Of course, one can also mitigate passenger levels by fiddling with "alternate destinations" and passenger journey time tolerances, which is what I'll have to do on the GB map if passenger numbers start to get really out of hand.

That is very interesting. May I ask - how do you work out what constitutes the right level of passengers in the first place?

[Carl]

Nothing too precise. I take the "right level" of passengers to be that at which most services are decently loaded, but not too often overcrowded -- and given the realistic service frequencies this seems to require a passenger factor of 1.

[jamespetts]

Nothing too precise. I take the "right level" of passengers to be that at which most services are decently loaded, but not too often overcrowded -- and given the realistic service frequencies this seems to require a passenger factor of 1.

Do you find that all the services are realistically loaded in this case, or are some overloaded and some underloaded?

[Carl]

For the most part loadings are realistic. There are some obvious and explicable distortions, though. High Speed services from Kent are extremely popular and usually full -- whereas of course in real life this is mitigated by the fact that there is a supplement payable to travel on such services. On the other hand, London Underground services tend not to be as busy as one would expect -- except in the very centre of London. This is presumably because it's quite difficult to simulate the fact that Londoners are much more likely to use public transport. (There are mechanisms in Experimental which can do this to a certain extent, of course, but I have not yet pushed these to their limits.)

[jamespetts]

For the most part loadings are realistic. There are some obvious and explicable distortions, though. High Speed services from Kent are extremely popular and usually full -- whereas of course in real life this is mitigated by the fact that there is a supplement payable to travel on such services. On the other hand, London Underground services tend not to be as busy as one would expect -- except in the very centre of London. This is presumably because it's quite difficult to simulate the fact that Londoners are much more likely to use public transport. (There are mechanisms in Experimental which can do this to a certain extent, of course, but I have not yet pushed these to their limits.)

Is this with or without a realistic level of private car transport?

[Carl]

Now that I'm not sure about. I have private car display set to low for performance reasons (since the map is hideously large). I don't know whether that's just a visual feature or if it turns off private car simulation altogether -- and I'm afraid I'm not too familiar with the appropriate values governing the level of private car usage.

[jamespetts]

You need to look in the city chart window. The city car level relates only to the number of vehicle objects appearing on the road, not the number of journeys made by private car. That is determined by privatecar.tab file in the /[pakset]/config folder. If there is no privatecar.tab (giving variable values by year), a flat figure of 25% access to a car is assumed.

Edit: I have looked at your latest save, and you have car ownership at a steady 25%, meaning that no privatecar.tab is defined. I also notice that the trains seem rather on the deserted side: eleven out of five hundred and something. This seems to be the passenger density of very early on a Sunday morning: 1 is probably too low for Pak128.Britain-Ex.

[o_O]

It seems like the effect of building levels should be more continuous.  Each level should always produce more then the previous, allowing level to simulate a combination of density, relative wealth, and the progression of time.  This would especially help balancing earlier years, where routes can get clogged with slow, low capacity 1800's vehicles trying to move around 1900's levels of cargo. 

[jamespetts]

Or even 1700s vehicles trying to move around 1800s cargo. I am minded to agree in principle. The question is implementation...

[o_O]

Maybe the number of passengers in a 'packet' should be a float and .1234 passengers is treated as one passenger with a 12.34% chance of spawning.  Then building level would matter and passenger/mail balancing could be done with building levels and the level formula, independent of the strange passenger factor and bits per month stuff.

[jamespetts]

We can't have floats in running code, sadly, because rounding/truncating differs between different platforms, which causes desyncs when playing online. What we have to do is multiply by 100 or 1,000 (or even more) and use percentages or permilles, etc.

[jamespetts]

Looking into this topic further, I have found this research, which shows that, on average, each person makes 1,100 trips per year, 84% of which are 16km (10 miles) or under, and 14% of which are between 16 and 80km (10-50 miles), the remaining 2% of which are above 80km (50 miles). The first step, therefore, is to reflect these values in simuconf.tab, which I have done on my Github branch for the forthcoming 0.9.0.

Given that there are 8,760 hours in a year, 1,100 trips per year equates to 1 trip per person every 0.13 hours. However, those journeys are not spread evenly throughout the day: many hours of the day are spent asleep, time in which no journeys are made. Because Simutrans does not represent fluctuating demand at different times of day, but instead represents an average day time demand, the inactive night-time hours must be removed from the calculation. If we remove 8 hours from the day to represent per person sleeping/resting time, get a figure of 5,844 (24 - 8 * 365.25) active hours per year. Dividing 1,100 trips per 5,844 active hours results in a figure of 0.19 journeys per person per hour, or approximately one passenger trip every five active hours per head of population.

In 0.8.4, a sample town generated 3,007 passengers in a month, which is 6 hours and 24 minutes long (or 6.4 hours long). 3,007 / 6.4 = 469.84 passengers per hour, which, when divided by 0.19, gives a figure of 2,472.84. In the game, the town reports having 4,972 of population and 223 buildings (for reference, this is Chillhead from the Bridgewater-Brunel online game, taken in the year 1808). Oddly, that suggests that there are too few, not too many, passengers being generated. The issue might, therefore, be in the proportions of them that are allowed to travel longer distances: the defaults in 0.8.4 are:

Local: 58%
Mid range: 28%
Long distance: 14%.

(The ranges are defined differently).

Have I done something wrong in this calculation, or do people agree that all this points to the conclusion that the issue is not the passenger factor per se, but the proportion of people prepared to travel long distances?

[ӔO]

Possibly change the factors to:
Local: 60%
Mid: 32%
Long: 8%

[jamespetts]

Hmm, I think that nothing less than using fully realistic figures will suffice here, especially given the scale of the problem, which very small changes seem extremely unlikely to fix. In the Github repository, I have edited the relevant parts of simuconf.tab to the following:

Code: [Select]

# The program will generate three groups of passengers: (1) local;
# (2) midrange; and (3) long distance. The program will look for a town within
# the specified distance ranges for each class of passenger. If it cannot
# find such a town within a certain number of tries, it will pick a random town.
# The ranges *may* overlap. These values are in kilometres.

local_passengers_min_distance = 0
local_passengers_max_distance = 16
midrange_passengers_min_distance = 16
midrange_passengers_max_distance = 80
longdistance_passengers_min_distance = 55
longdistance_passengers_max_distance = 16384

# The following are percentage chances. They represent the chances that
# any passengers generated will try to find a town within each of the three
# ranges, respectively.
#
# 84% of journeys are 10 miles (16km) or under
# 14% of journeys are 10 - 50  miles (16-80km)
# 2% of journeys are >50 miles (80km)
# See: http://www.sustrans.org.uk/assets/files/connect2/guidelines%2016.pdf
# Allow for some overlap, however, between midrange and long distance.

passenger_routing_local_chance = 84
passenger_routing_midrange_chance = 12
# (Longdistance by inference = 4)
# passenger_routing_longdistance_chance is 100 minus the sum of the two above values,
# but not stipulated individually.

# Passengers have a maximum tolerance level for how long that they will
# spend travelling. The further that the passengers want to go, the more
# time that they will be prepared to spend travelling. The number is
# expressed in minutes. For each packet of passengers, the number of
# minutes travelling time (including waiting time) that they are prepared
# to tolerate is randomised between the minimum and maximum amount using a
# normal distribution, meaning that the numbers are more likely to be in
# the middle of the range than at either end. The local, mid-range and
# long-distance passenger groups correspond to those above.

min_local_tolerance = 2
max_local_tolerance = 75
min_midrange_tolerance = 5
max_midrange_tolerance = 240
min_longdistance_tolerance = 30
max_longdistance_tolerance = 4320


[ӔO]

If you were to do that, I do think the passengers would need to be broken down further for more realistic results.

Off the top of my head...

Local
- Tourist
- Shopper/errands
- Commuter/student
- Commuter/local worker

mid distance
- Commuter/suburbia (anywhere, as long as travel time within 1hr)
- Shopper/by car

long distance
- Business trip (anywhere, as long as comfortable)
- Vacationist
- Immigrant/Emigrant

By far, the largest total number would be commuters.

[sdog]

Isn't mid distance (>16 km) a bit unusual for shoppers? Going more than a few km would immediately cancel out any bargain price.


James, the short distance does most likely include walking as mode of transport too. This would remove a very large number of those trips. I'd expect at 84% you greatly overestimate public transport use. (hardly anyone would take a bus for a trip below 1 km)

[ӔO]

We canadians do cross the border occasionally to buy stuff from the states when they have black friday or other amazing deals.
But yes, it's a very limited percentage. Probably not even 1% of us will do it, since it requires a few thousand dollars investment to save several hundreds.

[kierongreen]

Maybe short/medium/long distance could be defined in terms of not just distance traveled but other factors. People in remote areas often travel much further than those in urban areas for work, shopping and so on.

[jamespetts]

Breaking down the distance factors further as suggested would require some quite fundamental changes to the basic way in which the passenger generation works; why is this necessary on the contingent that realistic figures are used for journey distances and time tolerances but not otherwise...?

[The Hood]

The other thing to consider (this may already be taken account of in Exp - I'm not familiar with it) is the fact that earlier in history people travelled less far. Even in recent times there is a significant amount of evidence to suggest that where people travel is governed by how long people are willing to travel. For commuters, this works out at pretty much 1 hour. Build a new road/railway or speed things up and it means you don't simply improve existing journeys, you also CREATE new journeys because you can now commute to new places in under 1 hour. So as transport speeds up, you get more journeys (which should be reflected in an increased transport network capacity with faster and higher capacity vehicles).

[jamespetts]

This is accounted for by the journey time tolerance feature in Experimental.

[asaphxiix]

I think it's a good idea, using realistic numbers, or maybe slightly less than real.

For era variance in travel distance, and in general, wouldn't journey time tolerance help mitigate the number of pax on the roads as well?

I'm not sure of its current performance, but pax seem to be quite tolerant in the online game, for the year 1821.

[greenling]

Jamespetts
it´s helpful then i here post a old time table out germany?

[jamespetts]

I don't think that a timetable per se would assist - what's really needed are the number of people actually travelling. Thank you for the offer, however.

I am experimenting with lowering the tolerances, too.

[greenling]

Jamespetts
In old Timetable can you read out how many people in the history be used a Train or a bus.

[jamespetts]

Jamespetts
In old Timetable can you read out how many people in the history be used a Train or a bus.

Perhaps they might be of some interest...

[sdog]

The timetables would provide not that much information. It would be needed to know what utilisation was aimed at, if the assumptions of the timetable where met, if operational constraints were more important (trains have to go back too) and if there was a correlation with passenger numbers intended at all (eg. 30 min timetable to meet city requirements for minimum service)


I don't see why having a more finegrained classification of travel distances would be sensible. Travel time ought to take care of that. Short, mid and long distance seems a very sensible classification. What i don't trust are the numbers you found. Unless they are transport specific, not general travel lengths, regardless of mode.

[jamespetts]

What i don't trust are the numbers you found. Unless they are transport specific, not general travel lengths, regardless of mode.

Do you mean the numbers that I found in the paper that I linked? Why do you not trust them? They specifically purport to be mode independent, as the purpose of the paper is to discuss methods of decreasing car usage in proportion to cycle and walking usage for short journeys.

[sdog]

I haven't seen the link on my first read, only after you mentioned it now that the article is linked.

The paper states 22% of trips are below 1 mile (1609 m?). I would not consider them as possible transport users. I suggest to remove them from the total and re-normalize. Doing so would yield
80% short distance, 14% mid distance, and 6% long distance. See the calculation below.

Code: [Select]

-- short
Prelude> 1- (0.05 + 0.11)/(1-0.22)
0.7948717948717949

--long
Prelude> 0.05/(1-0.22)
6.410256410256411e-2

--mid
Prelude> 0.11/(1-0.22)
0.14102564102564102

ps.: I'm surprised it's in miles 40 years after metrication. (I wonder how people estimate such distances as all odometers and way-signs would show km). That's not a criticism of the article of course, just a surprised observation.

pps.: At average speed (1.1 m/s) walking a mile would take 24 minutes. It's surprising there are people who take a car for such distances, the time saved could be at maximum 5 minutes (driving has more overhead, unlocking, starting, unparking, parking, etc) the cost involved with the greatly increased wear of a cold motor ought not be able to make driving economically sensible for anyone close to an average hourly income.

[jamespetts]

I have been looking carefully into how the passenger generation system works in practice, and also calibrating some figures. When I apply my new journey time tolerance settings to a saved copy of the Bridgewater-Brunel online game, the overall proportion of passengers transported falls from 9% to 4% - a step in the right direction.

However, some rough calculations based on stagecoach departure figures from this paper (see page 29), an assumption that stage coaches would on average carry 10 passengers each and these historical population statistics suggest that stage coaches transported an average of 654 people per "active" hour (as defined above) in 1800. This works out at 0.00004 journeys per hour per head of population.

In my modified version of the Bridgewater-Brunel game from 1808, however, with a population of 1,561,558, I get 56,126 passengers transported an hour total, or 0.035942 passengers transported per hour per head of population - nearly 100 times the historical figure for stagecoaches.

It has to be said that there must have been a goodly number of passengers transported by canals and boats of various kinds in 1800, so the figures for stagecoaches should be taken with some caution, but I should expect to see a difference of no more than one to one and a half orders of magnitude on the most generous assumptions about the numbers of passengers transported by canal (I cannot find any data on that), so a difference of a factor of 100 is still a long way off.

Trying to find the cause in the game mechanics, I think that I have narrowed things down to the journey time tolerance system. I have not found any bugs, per se, but the system is not quite doing the intended job, and I need to think carefully for a sensible solution.

As indicated above, the tolerance ranges for the various sorts of journeys are:

Code: [Select]

min_local_tolerance = 2
max_local_tolerance = 75
min_midrange_tolerance = 5
max_midrange_tolerance = 240
min_longdistance_tolerance = 30
max_longdistance_tolerance = 4320

These are realistic ranges in themselves, but the problem is how numbers are picked in the range. In 10.15 and previous versions, the system was very simple: a random number anywhere in the range would be found. A journey time tolerance would have an equal chance of being at any point in the range. I have modified this in my 10.x build to use a very simplified normal distribution generation mechanism suggested by Kieron, of dividing the maximum random number by 2, getting two random numbers with that halved maximum and adding them together.

Unfortunately, a normal distribution turns out not really to solve the underlying problem. Let me give some examples of an actual sequence of journey time tolerances generated in the game, trapped using the debugger (all values in minutes):

Local (0 - 16km)

38
27
46
33
61
46
42
43
37
71

Mid range (16 - 80km)

61
46
217
22
109
33
135
120
167
146
40
24
163
21
99

Long distance (55 - effective infinity km)

3170 (52 hours)
2606 (43 hours)
2121 (35 hours)
2424 (40 hours)
2441 (40 hours)
1754 (29 hours)
2648 (44 hours)
3321 (55 hours)
3492 (58 hours)
2671 (44 hours)
2836 (47 hours)
3340 (55 hours)
1875 (31 hours)
2725 (45 hours)
2329 (38 hours)
2971 (49 hours)
2206 (36 hours)
371 (6 hours)
2182 (36 hours)
1338 (22 hours)
2044 (34 hours)


Although long distance passengers now make up only 4% of those generated, with figures like these, virtually all of them will tolerate the sorts of journey times seen in the online game involving long stage coach journeys or sea voyages. Although there must be some passengers willing to travel for such a long time (according to the paper linked above, a journey from London to Manchester in 1750 would take 90 hours, and multiple day sea voyages were the norm), only a very small proportion of the passengers generated for long distance routes should be prepared to travel for this length of time - less than 1 in 100, probably. There should be substantial numbers of long distance passengers being generated with journey times of three, two and even one hour(s), with only a small number being prepared to travel for four or more hours.

Perhaps what I need is not a bell curve after all, but a decay function of some sort to make numbers at the shorter end of the range progressively more likely than numbers at the longer end of the range.

I should be very keen indeed to know from people here:

(1) whether this seems in principle a good idea (and more generally, whether anybody disagrees with my analysis above, and, if so, why); and
(2) any good suggestions for a formula to implement the decay method that I propose.