News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

[Strange Behaviour v3.4] On-and-Off Impact of Power on City Growth (+congestion)

Started by knightly, May 03, 2009, 04:47:50 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

knightly

Just started a brand new game in v3.4, built a wind power plant (together with transformers and powerlines of course) with more than enough power for the whole city, and fast-forward. As can be seen from the 1st attached image, power supplied completely satisfied power demand of the city at all times (the 2 curves overlapped).

For many months, city growth was zero. But for a few consecutive months, there might be certain extent of city growth, but would fall back to zero again later. Such on-and-off pattern repeated at indefinite intervals in an unpredictable fashion. Please see the 2nd attached image.

As long as power is constantly and sufficiently supplied at all times to the city, I would suppose its impact on city growth is more or less steady. So, is such on-and-off pattern the intended behaviour?

Edit: Changed title as discussion had broadened (jamespetts)

jamespetts

Knightly,

thank you for the feedback. Unfortunately, I haven't been able to reproduce such erratic behaviour. I also notice that the electrical output of the wind power plant is wrong at 3372MW, instead of the default 12MW, which I do not understand either. One thing that might cause cities to grow less than they otherwise might - especially large cities - however, is congestion. Congestion is measured in a percentage of the amount of congestion that is enough to stop city growth entirely, so, if the congestion is anywhere near 100, the city will grow either very slowly or not at all.
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.

Colin

Quote from: jamespetts on May 03, 2009, 08:00:29 PM
Knightly,

thank you for the feedback. Unfortunately, I haven't been able to reproduce such erratic behaviour. I also notice that the electrical output of the wind power plant is wrong at 3372MW, instead of the default 12MW, which I do not understand either. One thing that might cause cities to grow less than they otherwise might - especially large cities - however, is congestion. Congestion is measured in a percentage of the amount of congestion that is enough to stop city growth entirely, so, if the congestion is anywhere near 100, the city will grow either very slowly or not at all.

Question: Would putting two power stations close to a city help with the growth if one power station has reduced supply?

Best Regards

Colin
I may not agree with what you say, but I will defend to the death your right to say it

Thought for the day

When you are up to your backside in alligators, it is difficult to remind yourself that your initial objective was to drain the swamp.

knightly

1)
Quote from: jamespetts on May 03, 2009, 08:00:29 PM
I also notice that the electrical output of the wind power plant is wrong at 3372MW, instead of the default 12MW, which I do not understand either.

When I create the wind power plant as a public player, I deliberately set the production capacity to 8432 units, though I am not sure if, according to your implementation, the output in MW is 3372 after conversion. I did that in order to ensure that the plant can supply as much power as needed by that city.

2)
Quote from: jamespetts on May 03, 2009, 08:00:29 PM
One thing that might cause cities to grow less than they otherwise might - especially large cities - however, is congestion. Congestion is measured in a percentage of the amount of congestion that is enough to stop city growth entirely, so, if the congestion is anywhere near 100, the city will grow either very slowly or not at all.

I see. Since I didn't add any transportation in that city, this might be the cause. But the problem is, the city wasn't really congested at all. While I was watching the game in fast-forward mode, there were indeed quite a number of private cars driving around on the roads, but obviously far from congestion as we would normally define. The roads were not busy with traffic, and there weren't any queuing up of cars.

Please take a look at the attached image. With a sparse traffic as such, the congestion level is alarmingly 150, which is something beyond my comprehension. And given the following code in stadt::calc_growth() :

Quote
  //Congestion adversely impacts on growth. At 100% congestion, there will be no growth.
  float congestion_factor;
  if(city_history_month[0][HIST_CONGESTION] > 0)
  {
    congestion_factor = (city_history_month[0][HIST_CONGESTION] / 100.0F);
    growth_factor -= (congestion_factor * growth_factor);

  }
 
  wachstum += growth_factor;

growth_factor will become negative if it is > 0 and congestion level is 150 (congestion_factor = 150 / 100.0F = 1.5F). You can also see from the image that monthly congestion levels are generally quite high even when the traffic is sparse, so it is not surprising then that city growth is low.

Please also take a look at the following code from stadt::neuer_monat() which determines monthly congestion :

Quote
  float city_size = (float)(ur.x - lo.x) * (ur.y - lo.y);
  float cars_per_tile = (float)city_history_month[1][HIST_CITYCARS] / city_size;
  float population_density = (float)city_history_month[1][HIST_CITICENS] / city_size;
  if(cars_per_tile <= 0.4)
  {
    city_history_month[0][HIST_CONGESTION] = 0;
  }
  else
  {
    float proportion = (((cars_per_tile - 0.4) / 4.5) * population_density) / welt->get_einstellungen()->get_congestion_density_factor();
    city_history_month[0][HIST_CONGESTION] = proportion * 100;
  }

On the calculation of cars_per_tile :
(1) city_history_month[1][HIST_CITYCARS] aggregates the total number of city car pax generated in the interval of 1 month, but congestion depends on the ratio of currently running city cars to available road tiles at a particular moment in time.
(2) city_history_month[1][HIST_CITYCARS] counts the number of pax using private cars, but not the number of private cars generated. Overlooking this will surely overstate congestion.
(3) It is not very meaningful to divide by city size. Congestion depends only on the road tiles within the city.
(4) Player convoys are completely omitted from congestion determination.

On the calculation of proportion within the body of else :
- I really don't understand why the expression has to be multiplied by population_density. Higher population density does contribute to congestion, but that is already reflected by the increased number of city cars. Why then do you include population_density again in the formula when you try to estimate congestion based on cars_per_tile?

It seems that your current approach very much overstate congestion. When you revise or redesign your approach, please bear in mind the difference between busy traffic and congestion : even when there are many cars on the road, if the cars run uninhibited at their normal speed (subject to road speed limit of course), this can only be regarded as busy traffic, and should not be penalised. Congestion happens when cars drive at a very slow speed or even have to stop and wait.

Edit 1 :  Point 2
Edit 2 :  Point 2 again

prissi

Vehicles and convois know their congestion state. There one could add a routine which checks for cityroad and if yes, add it to this months congestion counter. Then one could use even an absolute value like 150 car waiting last month => congestion.

jamespetts

Colin, Knightly and Prissi: thank you for all your input. I think that I need to explain a little more about how congestion works in Simutrans-Experimental, as there seem to be misunderstandings (my forthcoming revised help texts should explain the issue clearly, too, if I ever get to finish them between all the bug fixing, although, absent those texts, I can see why misunderstandings might be generated). Congestion in Simutrans-Experimental is not based on the number of cars visible in the map view: it is based on (as Knightly has seen) a fairly complex formulation taking into account the population density, the number of car trips generated and the size of the city. The number of cars visible on the city roads depends on two factors: (1) the number of private car trips (measured in the "traffic" graph); and (2) the traffic density setting in simuconf.tab. The traffic density setting, however, has no effect on the calculation of congestion, and that is intentional: it is designed to limit only the number of private cars that are actually generated in the map window.

In Simutrans-Experimental, all private car trips are logged whether or not they generate private car graphics in the city. The number of private car trips is an inherent part of the simulation: firstly, passengers using private cars are using them instead of player transport, so the number of private car trips needs to be able to be monitored by the player to assess how competition from private cars is affecting player transport. Also, passengers being transported by private cars have as much (positive) effect on the growth of a city as passengers being transported by player transport, so that statistic is important for that reason, too. Finally, the number of private car trips is an important determiner of congestion.

Congestion is not (and is not intended to be) a measure of how congested that the actual roads are in the map window, since, as stated above, this will depend on the "traffic density" setting. Congestion is instead intended to be a measure of how well that the town's infrastructure can cope with the level of private car usage generated by that town (representing the sum of internal journeys, incoming journeys, and outgoing journeys). The absolute level of traffic is just one factor: the dimensions of the town is another (the more spread out that any given amount of traffic is, the less congested that it will tend to be, all other things being equal), and also the population density. At first blush, using the population density here might appear to be double counting, but in the fairly extensive testing that I undertook when I first coded this feature some months ago now, I found that it was necessary for congestion to scale realistically with the size of a town in Simutrans terms. Don't forget that, in reality, a city's population density is a very important determiner of its ability to cope with private traffic levels: higher density means that more cars are using the same individual bits of road, and there is more competition for parking (higher parking prices make a big difference to people's propensity to use public rather than private transport to travel to a town).

The congestion can be adjusted, but not by adjusting "traffic density", which, as stated above, is designed to affect only the appearance of private car graphics, not the simulation engine itself (hence, if the value is set very low, the level of reported congestion might be at odds with the number of car graphics visible). There is a congestion density factor setting in the simuconf.tab file, the effect of which is explained in the comments in that file, which can be used to affect the amount of congestion that cities produce for any given level of private vehicular traffic. Indirectly, congestion can also be affected by the proportion of people with access to private cars (show in a graph in the city information windows), the propensity of people who use their private car rather than public transport when all other things are equal (which can be set in simuconf.tab), and the proportion of people who will always use their private car, no matter how bad the congestion or how good the player's transport (which can also be set in simuconf.tab).

In summary: an apparent disconnect between the reported congestion levels and visible traffic in the city is not an error: it is intended that the player can set the level of visible traffic independently from the simulation parameters governing congestion and traffic. Each can, however, be adjusted with some precision either in simuconf.tab, or the game's GUI. The congestion generation system has been thought out and tested quite thoroughly, and is coded the way that it is for a reason: depending on the congestion density factor, the amount of congestion produced by any town of any given size should conform to a player's expectations about how much congestion that a town of that size ought produce, given the size of that town relative to other towns in the game world.

***

To deal briefly with the point about power supply: putting power stations next to a city does not help in itself: what is important is that the substation(s) supplying the city are connected to a power network that has enough spare capacity to supply the city's entire power demand. In simple terms, if you see that the "power demanded" graph in the city's information window is consistently higher than the "power supplied" graph, connect another power station to the network that supplies the city until the two graphs show equal numbers.
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.

Colin

Hi James,

Thank's once again for your detailed explanation. I'm running currently running 3.4 and have three large city's (over 14000 population) and have yet to experience any difficulties. I have tram and rail services running in all three and I will expand further during today. Let you know if I get any problems.

Best Regards

Colin

PS: Just one point. In the Traffic Density setting is 1 the least and 7 the highest? I ask this because at one stage in Standard 1 was highest. I've got my set to 1 in 3.4 and my roads are awash with traffic. OK I fixed this by editing the Traffic Density in the Config. Now I've lost them all.  ;D I'll experiment with these settings as obviously, in OZ, the TD would not be the same as the UK.

edit 18:40 today. Have noticed that the game tends to crash for no apparent reason. IE: Using 'Shift R' in one location ok, in another location game crashes.

PPS: Terrific that the ability to put Tram tracks across road bridges actually works. There was only one time in Standard that it worked, can't remember the version number but ever since I couldn't get it to work. It may have been me but hey! I've no problems with your Experimental 3.4 in getting it to work.
I may not agree with what you say, but I will defend to the death your right to say it

Thought for the day

When you are up to your backside in alligators, it is difficult to remind yourself that your initial objective was to drain the swamp.

knightly

(1)
While your belief behind the congestion implemention :

Quote from: jamespetts on May 04, 2009, 09:42:28 PM
Congestion is instead intended to be a measure of how well that the town's infrastructure can cope with the level of private car usage generated by that town.

is understandable, I still fail to see why the formula for proportion should be as it is now. If a city has relatively few city car trips because comprehensive public transportation is already provided, I don't see why city growth should be penalized just because the city happens to have a higher population density. Besides, there is no necessary connection between high population density and insufficiency of parking spaces.

(2)
Quote from: jamespetts on May 04, 2009, 09:42:28 PM
Don't forget that, in reality, a city's population density is a very important determiner of its ability to cope with private traffic levels: higher density means that more cars are using the same individual bits of road, and there is more competition for parking (higher parking prices make a big difference to people's propensity to use public rather than private transport to travel to a town).

As I have said above : "Higher population density does contribute to congestion, but that is already reflected by the increased number of city cars." Increased number of city cars obviously lead to keener competition for parking spaces if there is a shortage. Actually your reasoning here also coincides with my logic, and sorry to say that your reasoning is no more than admitting that your are counting the same factor twice, something that you try to deny.

The chain of causation is : Higher population density -> More city cars -> Increased competition for parking spaces. But since city cars can be reduced by player efforts (by building public transport), the best candidate to determine congestion is obviously city cars, and IMHO only this single factor should be used in the calculation. Incorporating population density into the forumla not only constitutes double counting, but will also dilute the impact of public transport on congestion. When you multiply the expression by population density in the calculation of proportion, you are exaggerating the seriousness of congestion for densely populated cities, inhibiting their potential to grow.

Note : If you still cannot reproduce the kind of on-and-off pattern of city growth and over-100 congestion levels, try to find a city with population size > 15000.

(3)
Lastly, points 1, 3 & 4 on calculation of cars_per_tile in my previous post are still valid. I would suggest you to think over them.

jamespetts

Knightly,

as you will see, I have added a simpler version of the calculation for congestion as an alternative in version 3.5, which can be selected by setting the "congestion_density_factor" to 0 (previously, setting it to 0 caused it automatically to be re-set to 1). If you would like to suggest a better way of handling that alternative calculation, do let me know.

However, the reason that I developed the algorithm for proportion as it is was because, after quite a lot of testing, I found that the simpler one that you suggested (which is more or less what I had implemented in my early versions) did not scale well: in other words, if it was set correctly for small towns to be only slightly congested, big towns would be only slightly more congested, whereas if large towns were set to be substantially congested, small towns would also be substantially congested.

As to the original points 1, 3 and 4, I do not really understand no. 1: congestion is measured monthly, too, and the calculation of the total congestion made at the beginning of each month is used for the rest of that month. The difficulty with no. 3 is that there is no easy way of checking the number of road tiles in a city in the code, and, given that there is not a substantial variation in the road network density in Simutrans, an adequate approximation is to use overall size. As for no. 4, it would be extremely difficult to measure player convoys alongside traffic when calculating congestion, as there is no easy way to measure the number of trips that each convoy makes. Since the impact of player convoys is likely to be limited compared to that of private cars, and that the actual blocking of players' vehicles in the map will depend on players' convoys, this is an approximation that works well enough.

Thank you again for all your thoughts and feedback - even when I do not entirely agree, your effort is much appreciated :-)
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.

knightly

James,

Quote from: jamespetts on May 08, 2009, 04:49:43 PM
as you will see, I have added a simpler version of the calculation for congestion as an alternative in version 3.5, which can be selected by setting the "congestion_density_factor" to 0

Many thanks indeed for adding this special option. :) I will try it out later.

Quote from: jamespetts on May 08, 2009, 04:49:43 PM
However, the reason that I developed the algorithm for proportion as it is was because, after quite a lot of testing, I found that the simpler one that you suggested (which is more or less what I had implemented in my early versions) did not scale well: in other words, if it was set correctly for small towns to be only slightly congested, big towns would be only slightly more congested, whereas if large towns were set to be substantially congested, small towns would also be substantially congested.

Sorry but, I really fail to see why the formula needs to scale with city size. IMHO, if the ratio of generated private car trips to city size is the same for a small city and a big city, they should have the same congestion level. With big cities, due to its dense population, there will be more pax trips, and if the player fail to provide sufficient public transport, there will be more private car trips, and the ratio of private car trips to city size will rise, meaning that congestion level will also increase. I think this approach already reflects the status of congestion in a city sufficiently and truthfully.

With your approach, congestion level can be over 100 for large cities. Please open my save game again and go to Oxford's city hall and check out the congestion levels of recent months -- many months are above 100, and please also take a look at the city growth for recent months -- you will see the on-and-off pattern of city growth where many months have zero growth. The reason is simple -- if you try to manually calculate the population density for Oxford, it should be ~59. But for a small city like Bristol, the population density is ~11.7 only. Let's assume that both cities have the same value for cars_per_tile, Oxford's congestion level will be 5 times that of Bristol. Let's say Bristol's congestion level is 25, then Oxford's congestion level will be 125. IMHO, such difference is not meaningful or reasonable at all.

jamespetts

Knightly,

we may have to agree to disagree on this one - which is facilitated by the alternative option that I have put in. In other words, the system that you suggest is set if "congestion_density_factor" is at 0, and my original system otherwise. I am happy to alter the formula used if congestion_density_factor is set to zero to anything sensible that you suggest.

The reason that I wanted larger cities to be more congested is simply because, in reality, they are (without public transport) more congested (in the sense of congestion described above of the ability of the city to cope with a given level of car usage). The congestion density factor is designed so that the effect of population density can be fine-tuned and for it not necessarily to be as dramatic in your example. Having larger cities more congested than smaller cities is important later in the game, when players have to face the real challenge of adapting their passenger networks to unequally falling demand, especially in the smaller towns. Players will need to decide whether to emulate Beeching, or adopt a more radical (or more conservative) strategy to deal with altered capacity requirements over time.
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.

Isaac Eiland-Hall

I disagree about large/small cities differing in density. For example, I live in a city of 36,000; and the traffic is as bad at rush hour as the metroplex of 6 million I used to live in...

Just thought I'd weigh in with that - seems like it's not a huge deal, especially since the player can choose the factor of zero if they wish :)

jamespetts

Isaac,

ahh, but did the Metroplex have more public transport than your 36,000 population town? ;-)
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.

Isaac Eiland-Hall

I'd say that the amount of public transportation in Bay County, Florida, vs. the Dallas/ Ft. Worth Metroplex, are about the same per capita. Roughly. Close enough. And although the traffic problems in Dallas are worse, in the sense that there's a much larger area; I would estimate that the congestion is pretty analogous when looked at on the basis of population density and size of the metro areas...

I would contrast that with Seattle, Washington, which has excellent public trasportation, and significantly less congestion -- it's half the size of Dallas in population, so it's still a large metro area (3-4 million people)...

In fact, I would argue that, at least for these three cities, the major difference is the public transportation, not the size. Seattle is unusually keen on public transportation, and it sees a significant difference thereby. Dallas is not - it's very spread out and people drive long distances, and public transportation is seen as the option for those too poor to drive a car...

So in my mind, and in my experience, effective public transportation would effect congestion, but the size of the city would not.

However, I do not claim that my experience meshes with the reality; nor do I necessarily suggest that it's the best methodology for the game... so this discussion may or may not have anything to do with your implementation anyway ;-) (but since you asked.... :D )