News:

SimuTranslator
Make Simutrans speak your language.

too much congestion

Started by chs, January 05, 2012, 10:10:27 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

chs

Same game as in the other post. 1970, pak brit exp 0.8.3. Changed a few settings for map generation, plus "assume cities connected = yes", otherwise standard settings.

In some parts of the map, connections including the nearest maybe 15 cities are as good as it gets, given the available vehicles.
The the city list statistics shows 90-98% of passengers transported in the region overall (was 98, now about 90, decreasing since I fast forward waiting for trams). Same statistic shows ca. 9000 city cars (map size: 512x512, 64 cities, 160k people).

Situation is the same for about 10 years (even when I transported 98%): there is too much congestion such that cities > ca. 3000 stop growing.

As I understand it, 2-10% of people travel by car, and these are enough to cause so much congestion to stow growth. Should some balance settings be improved or am I supposed to transport everybody, 100%?

jamespetts

Thank you very much for your report. It would help me if you could upload your saved game so that I can see in more detail what is happening here. The setting for assuming that all cities are connected, however, will be partly responsible, as it does not check to see whether there actually is a road connexion. Nonetheless, if you are transporting 98% of people and there is still a congestion problem, that is not how it was designed to work, so I shall have to run the saved game under a debugger to see exactly how the figures are being calculated. Do let me know when you have uploaded it.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

chs

#2
here you go..

https://www.mydrive.ch/
user: public@chs78
pwd: public

about the road setting: I choose the connection length very high (9900 iirc) such that there is a road everywhere. however, I did find cars travelling from A to B anywhere, and definitely not on a route that makes sense.

----

the older game (ending 1.sve) is a little earlier, with higher percentage. same growth situation.
also shows a maximum percentage of 104..

jamespetts

The percentages > 100% have been reported before, although I have never been able to track down the cause. I shall have a look at this to get more insight into the issue.

As to the cars' route not making sense, currently, cars do not attempt to find actual routes, as doing so the same way as player vehicles would take too much processing power and make the game very slow. I have an idea as to how to make cars follow sensible routes without each one having to perform computationally expensive route finding (which would be the basis of implementing basic traffic simulation in Simutrans, which would be a wonderful thing), but that would be quite a lot of work to implement, and takes a much lower priority than many other things that I need to do on Experimental at present.

Edit: Looking at the map, there are not an unreasonable number of cars on the road, but the congestion rating in the cities seems too high. This might be an issue with the congestion density factor. Before I look into adjusting this, however, can you let me know what changes that you made to the simuconf.tab file, and cityrules.tab file (if any)?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

chs

#4
I made the following changes:
- city isolation factor reduced to 16
- assume everywhere connected by road

Maybe (I did it sometimes) the following changes, but I think they dont matter
- reduce mountains in the landscape (hill level)
- reduce maximum transfers in route calculation to 6 (instead of 9)

Everything else is not changed = default as in official config files for download (the unzip&run package with these values is uploaded with the savegames, its what I use).

About the cars: I dont mind if they travel at random places instead of following calculated routes. Overall travelling at random (if they start at the origin of their travel) probably approximates real routes sufficiently good. I agree that the number of visible cars makes sense, its only the congestion (the number) that seems very high.

Something that may be related about visible cars: sometimes, in streets or cities with a lot of cars, cars seem to stack. There is a car waiting and another car moves to the same place in the other car. It simply moves over the other car and kinda merges. I have also observed the "unmerging", one car multiplying into lots of cars, where one by one moves away and the original car is still there.
Sometimes also buses got completely stuck in a traffic jam because private cars passed through my bus, and the bus had to wait for a car that was originally behind it. Does not happen often, and by now most of these buses are replaced by trams or trains. If that might be related I could upload another savegame when it happens again (happens once every 5 years or so.. at least what I noticed)

----

Just a though as very high congestion occurs only in bigger cities: if each car causes congestion, the total number of cars defines the congestion. Where 50 cars may cause a traffic jam in a small city, its no problem in a big city, because the cars are separated over more streets. So the length of all streets in a city radius should be taken into account, or an approximation of that value.
But guessing from what I read in the forums, things are well thought of before they are implemented, so I doubt this is it. No other ideas here..

jamespetts

Thank you for the information; that is useful. The congestion density factor will need looking at, in that case. Part of the issue seems to be connected to the fact that your towns are quite dense.

Incidentally, the congestion system does not currently work in the way that you suggest: it is not based on the number of actual car sprites in the towns, but the number of logged car journies. The formula is best summarised by quoting from the explanatory text for the congestion density factor setting in simuconf.tab:

Quote
# "Congestion density factor" is the factor by which the population density (in
# citizens per tile) is divided to get a factor multiplied by the number of cars
# per tile per month to get the congestion figure. In simple terms, the lower this
# number, the easier that it will be for cities to register as congested, and
# the more likely that it is that passengers will opt for public (i.e., the player's)
# transport instead. If "congestion density factor" is set to zero, then the congestion
# will be calculated using a much simpler formula that does not depend on the city's
# population density at all. 

The actual code is here:


const uint16 city_size = (ur.x - lo.x) * (ur.y - lo.y);
    const uint16 cars_per_tile_thousandths = (city_history_month[1][HIST_CITYCARS] * 1000) / city_size;
    const uint16 population_density = (city_history_month[1][HIST_CITICENS] * 10) / city_size;
    if(cars_per_tile_thousandths <= 400)
    {
        city_history_month[0][HIST_CONGESTION] = 0;
    }
    else
    {
        const uint8 congestion_density_factor =welt->get_settings().get_congestion_density_factor();
        const uint16 percentage = congestion_density_factor > 0 ? ((((cars_per_tile_thousandths - 400) / 45) * population_density) / congestion_density_factor) / 10 : (cars_per_tile_thousandths - 400) / 30;
        city_history_month[0][HIST_CONGESTION] = percentage;
    }


Does this make things clearer?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

chs

#6
Logically, what imho defines the congestion is the size of the city (city_size, roads, something like that) and the number of cars (city_history_month[1][HIST_CITYCARS], car journeys, 100% minus whatever the player transports).
So mathematically it would be something simple like "city_history_month[1][HIST_CITYCARS] / city_size = simpleCongestion", modified by constants to get the right scale. That is exactly what happens if you dont set a congestion densitiy factor. Am I correct so far?
If yes, the problem is solved by changing that setting to zero. Unfortunately, when I did that, the congestion values did not significantly change over several months (probably the config value is saved in the savegame).

Since city_history_month[1][HIST_CITYCARS] = %whatPlayerTransports * nofPeoplesJourneysInTown
the simpleCongestion already (indirectly) includes the population density. So the description seems not entirely correct.

When a congestion density factor is set, a complex congestion is calculated, again simplified:
complexCongestion = simpleCongestion * population_density * configValue

To achieve the described purpose for "Congestion density factor", you could simply calculate simpleCongestion * configValue. So I do not understand the logic behind the more complex formula.

Edit: some clarifications for better understanding

jamespetts

I did try to run your saved game with a congestion density factor of zero (which does trigger what you describe as "simple congestion", although note that the number of car journeys is calculated precisely in any event, and no further calculation by subtracting the number of player transport journeys is necessary), not just by changing simuconf.tab, which would not have worked for the reason that you gave, but actually modifying the value in memory using a debugger; the results were similar to those which you experienced: no real change. The problem either way is partly that your cities are very dense - there are a great many car journeys in a small physical space: this will give high congestion readings even with the congestion density factor set to zero (and therefore the simple calculation used). (The system was calibrated, I think, with less dense cities). I can look into setting progressively higher congestion density factors until the level of congestion in your cities is reduced to something sensible and setting that as Pak128.Britain-Ex's default value to that.

In the long term, I should like to change the way that congestion is calculated completely by looking at the number of road tiles in a city that have actual stationary traffic on them (excluding player vehicles stationary because they are loading/unloading) and the proportion of time in a month in which they have such stationary traffic, but this will need me first to set up a system where private cars follow actual routes as described above, which will be a long time in the coming, unfortunately.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

chs

Thank you for your analysis.
So the easy solution is to increase the density factor to a level where congestion is normal, for maps where the cities are closer together like this one. Maybe doubling it makes sense, since I divided the minimum city distance also by 2. Since there are 2 dimensions, density may have increased 4 times, so x 4 may be the right adjustment. 
By looking at the visible number of cars in a "representative" city, what congestion value would you guess?


About calculating congestion in the future.
I understand that for the calculation of the exact value, every car needs an exact route, which is not easily implemented. Maybe it is possible to approximate the real congestion in a simpler way.
Congestion in city A is caused by
1) cars starting in that city,
2) cars with destination in that city
3) cars travelling through that city.
1) and 2) are exactly known, if my understanding is correct.
3) requires exact routes, which are not available yet. Lets say we use a global value for this, equal for all cities (based on the average journey lenght and the estimated number of cities travelled through, both are easier to determine I think).

Together with the number of street tiles in a city, it would be possible to calculate the congestion density for each city. Lets say in average, a private car journey starts in city A, drives through 2 more cities B and C, and ends in City D. Using this method, the congestion caused in cities A and D is correctly assigned to these cities. The congestion caused in B and C as shared equally by all cities on the map. Cities in corners of the map have very little "drive-through" cars, while those in the center have much more. So instead of equally sharing the congestion between all cities, it could be modified by a factor depending on the cities location.
dtc = average number of drive through cities, 2 (cites B and C) in the above example
- cities with only 1 street connection to another city: zero (cannot drive through)
- corner cities: 0.2 (quite rare, only for drives along the border)
- cities located "about dtc/z city from the border": x 1/z
- cities located "about dtc cities from the border": x 1
- cities located "more in the center of the map": x 1.5

This should result in a relatively good congestion value, in particular for maps with a well developed transportation system (in maps where only half the cities are developed, part of their congestion would be shared by other cities).

To calculate a congestion density based on this, 1 fixed location value per city is necessary (can be determined quite exactly if someone has proper math skills), the average city distance and the average number of drive-through cities. I am guessing that all of these values can be calculated relatively easy (compared to implementing an exact route for each city).


Just thinking about another, even more simple idea. I think there already is a representation of cities connected by road. Basically, we have to appy the congestion for the drive-through cities to the right cities. Lets say we have exact dtc = 4 (edtc, where it was average above). Apply congestion equally as follows
- 1/b for each city directly connected to the starting city "distance 1 city", where b is the number of these cities
- 1/c for each city connected to any "distance 1 city", excluding the starting city" and other "distance 1 cities", where c is the number of those new cities
- do the same starting from the destination city (approximation is closer than if we continue this)
for uneven edtc values, just apply one half the congestion.
Provided we know how cities are connected, this would be quite easy and probably very accurrate. This is only the idea, it would have to be detailed in several poins I think.


Let me know what you think about this idea, in particular about the second one. Seems to me way better than the first one.

jamespetts

Firstly, I am not sure why the spacing between cities (as opposed to the internal densities of the cities themselves) would have an effect on congestion in the current model; you changing the city isolation factor would make no difference given that you have set assume everywhere connected by road to on, and would make only a relatively minor, indirect difference if you had turned it off.

Secondly, the existing congestion model already does track cars entering and leaving cities, the sum of which is the "traffic" figure seen in the city graphs. It does this by registering a private car transport route at the origin and destination for every passenger journey which is undertaken by car. When assume_everywhere_connected_by_road is off, it will use as part of the calculation of whether to take a private car in the first place a calculation as to whether the origin and destination cities (or destination industry or attraction, as the case may be) are connected by road, and the average maximum speed of the type of road connecting them. If assume_everywhere_connected_by_road is on, it will assume that everywhere is connected to everywhere else with a particular type of road. Journey times are approximated accordingly (taking into account also the weighted average maximum speed of city cars presently available), and passengers will only travel by car if the journey times thus approximated are within their tolerance.

What you propose seems to be a rather large amount of effort for probably not much increase in the realism of the traffic simulation: measuring the cars "passing through" a city does not seem of itself very useful, especially since it is entirely possible to bypass cities completely. What I have planned is loosely based on the way in which the people who made Sim City 4 dealt with the problem of it being too computationally expensive to calculate lots and lots of routes through a relatively complicated network constantly: to have fixed private car routes from specific origins to specific destinations which are updated only periodically.

In the game as it currently stands, unless you turn assume_everywhere_connected_by_road on, the game will in any event calculate routes between each city and each other city, and also between each city and each industry and each attraction, but discard the actual route tiles once the average time per straight line tile for the journey is known. I had initially thought of simply using these routes, but realised that this would not be effective for journeys inside cities, or where cities are close together, such that the distance between two cities is less than, equal to or not much more than distances within the cities.

What I plan to do instead is to have fixed routes to a particular destination cities, attractions and industries stored in tiles individual tiles. Only one route to a particular city (including the city in which the tile is located), industry or attraction can start at any given tile. These routes are renewed periodically, and the particular part of the destination city at which the route ends is selected randomly. The rate of renewal would be set by a parameter in simuconf.tab. Whenever a private car journey is required from a particular start tile (passenger journeys - even in Standard - always originate at a particular building, not station), the system would perform a search of a predefined number of surrounding tiles (the radius being set by a simuconf.tab parameter). If a non-obsolete route is found to the destination city, industry or attraction, then that route would be used. If not, a new route would be calculated. If no route at all could be found, the destination would be marked as unreachable in the surrounding tiles so as to prevent multiple repeated failed searches consuming excessive computational power.

The cars would then all drive along the route to their destination. The number of cars would be based on a reworking of the existing "traffic level" simuconf.tab parameter, which would be reworked so as expressly to become a private car occupancy rate setting, and the number of car journeys adjusted accordingly. It would probably be better for the "traffic" graph in the city then to show only outgoing cars, so that players can more easily use it to tell what proportion of people from that city use the car to get to their destinations (making it comparable with the "transported" and "passengers" graph).

Congestion would be calculated completely differently: every road tile would record the time in the current and previous month that road vehicles have been stationery upon it. The congestion in a city would be calculated by adding up all of the values for road tiles within that city and normalising them, probably based partly on constants set in simuconf.tab.

Further, journey times would also henceforth be based on actual recorded journey times by the private cars completing their routes (each would store their journey start times, and would register their total journey time on completing their journeys). For cases in which no private cars have yet completed the particular journey, the time would be approximated in a similar fashion to the way in which it is approximated now. The actual routing mechanism (both for city cars and player vehicles) will take into account the congestion on each tile when calculating the best route. It will probably be possible to create an overlay map, much as in Sim City, showing congestion per road tile as various colours.

That way, congestion will be simulated as accurately as the power of contemporary computers allows: congestion measurements in cities will be based on actual traffic jams, and roads will become congested with actual cars based on their actual usage, simulated accurately. There will be incentive to alleviate congestion along specific routes by upgrading roads (the role of the public player being thus enhanced), and player vehicles will both contribute to and suffer from congestion in a realistic manner.

This will take some considerable time to implement, however. In the meantime, I can try to adjust the congestion density factor as discussed above to produce reasonable numbers in denser cities such as yours.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

chs

#10
I see that this is a bigger project, and also that I lack in depth knowledge how it works.

For the intermediate solution, I intend to start a new game and with same city density settings and use higher congestion value. It might take a few weeks until the game is sufficiently developed to know how this turns out. I will post the results here.

Edit: is my understanding correct, that turning off assume_everywhere_connected_by_road does not solve the issue?

Edit2: first results, since congestion values where too low first

756 x 756, 128 cities, min city distance 16, played 1 year without building anything, in 1978
- lots of cars, no more big changes observed
- always the first "permanent traffic jam" messages appeared)
- congestion density factor: 30

270000 people, assume_everywhere_connected off: congestion 20-30
180000 people, assume_everywhere_connected on: congestion 20-120

jamespetts

That will be a sensible way of testing, yes. Turning off assume_everywhere_connected_by_road will not solve the issue, as, even if everywhere was, in fact, connected by road, the congestion that you are experiencing given the proportion of passengers that you transport should not be anywhere near as high as it is; best leave that setting turned on for your test games to ensure that maximum road use still produces reasonable congestion values.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

chs

Did a third game, with settings as follows:
- 756 x 756, 128 cities, min city distance 16 (only change!), played 1 year without building anything,
- 1950, congestion density factor: 15 (default value), ca 160k people
- assume_everywhere_connected off

congestion is between 20 and 120, perfectly reasonable.

In this game, the only difference between the original game with too high congestion values is the setting "assume_everywhere_connected". When it is on, the congestion is much too high. If its off (default), congestion is fine. So it seems that this parameter causes high congestion values.

jamespetts

As indicated before, it only causes high congestion values by the mechanism of allowing everywhere to be connected by road. May I ask - were there road connexions between all the towns in your 1950 game?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

chs

Yes, all cities are connected by road (though I did not increase the connection length).

jamespetts

Hmm, that's interesting. It is possible that there is some bug with the assume_everywhere_connected_by_road setting, or perhaps just a design error consisting of giving too high an average speed for car travel when that is activated - I shall have to look into that.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.