News:

SimuTranslator
Make Simutrans speak your language.

[patch] Powerline network stabilization

Started by TurfIt, February 14, 2010, 05:43:28 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

TurfIt

Every wondered why the power to your factories keeps flickering even though you've fully supplied your power plant? Well so did I. What began as a simple investigation into the cause snowballed into this...

Four patches are supplied in order of increasing invasiveness into the bowels of Simutrans. The 3rd patch represents an almost entire rewrite of the power code but finally fixes the root cause. I've done this in case a more invasive patch is rejected as being to much, a less invasive one might be considered instead. Hopefully patch 4 passes muster as I do believe it represents a genuine improvement to powerlines in Simutrans.

No changes are made to savegames.
Existing games should proceed the same as pre patch; Except a slight increase in production at power supplied factories due to the now steady power supply.

NOTE: Patches are standalone, not cumulative. i.e. Remove one before another.
Windows binaries (SDL and GDI) are provided for patch 4. Please test... No warranty, own risk, etc, etc, yada, yada...



Patch 1: http://simutrans-germany.com/~patches/download.php?file=powernet1_r3082.zip [1k] .diff
   Changes the powernet sync_step to operate on the same relative interval as the fabrik step. PRODUCTION_DELTA_T.
   
Provides stable power upon loading a game. Any powerline construction or extended periods of high CPU usage knock the powerlines out of sync with the factories. Power then resumes flickering. Note: this desync is not because of this patch but existing game behaviour.
   


Patch 2: http://simutrans-germany.com/~patches/download.php?file=powernet2_r3082.zip [3k] .diff
Same as patch 1 plus:   
   Changes the powernet and leitung from using sync_step to step.

Provides greater resilience to high CPU usage. As factories only produce/use power every step, there's no need for the overhead of powerlines running every sync_step. Testing shows that it now takes extended 100% CPU usage to cause an issue. As with patch 1, stability is restored upon loading. Powerline construction still results in flicker. In cases of grossly overloaded powernets, less even sharing of the available power will occur.



Patch 3: http://simutrans-germany.com/~patches/download.php?file=powernet3_r3107.zip [7k] .diff
Same as patch 2 plus:
   Usage of power instead of energy in calculations in powernet, leitung, and fabrik classes.
   Change fabrik step to produce every step except smoke which remains every PRODUCTION_DELTA_T along with verteile waren.
   
Eliminates flicker in all tested cases. Provides consistency in results between ongoing games and save/loaded games.

The root cause of the flickering was simply the powerlines expiring (zeroing) the energy on them asynchronous from the powerplants placing their generated energy onto them. Changing to use power instead of energy (power*time) as the quantity kept track of, and ensuring all network elements (senke, pumpe, powernet, fabrik) step together in fixed sequence provide steady power.

Changing fabrik produktion to produce quantities based upon the actual time between steps rather than produce in fixed PRODUCTION_DELTA_T units is the most invasive change. This has the potential to result in a cumulative production quantity error if delta_t drops low enough. The frame timing routines do a reasonable job of maintaining adequate step intervals such that this change appears ok. Any extra CPU usage from this is more than offset by the reduced usage from changing the powernet, senke, and pumpe classes to step from sync_step. Time consuming tasks such as veteile waren are maintained on the old PRODUCTION_DELTA_T interval.   



Patch 4: http://simutrans-germany.com/~patches/download.php?file=powernet4_tabbed_r3107.zip [8k] .diff
           http://simutrans-germany.com/~patches/download.php?file=SimutransPowernetTestingWindowsBinaries.7z [1.6M]
Same as patch 3 plus:
   UI info window changes.
   
The info windows are IMHO rather confusing. Various forum threads from the past seem to support this thought. Hence, I submit these changes. I've tried to keep it simple, providing useful gameplay information in layman terms. However, actual layman may have different thoughts... Suggestions more than welcome.



New translation entries would be required for:
"Net ID: ", "\nCapacity: ", " MW", "\nDemand: ", "\nGeneration: ", "\nAct. Load: ", "\nGen. Usage %: ", "\n% Supplied: ", "Aufspanntransformator", "Abspanntransformator"

Translation entries can be removed for:
"Available"



Known issues:

Multiple transformer stations from different power networks attached to the same factory can produce some strange results. This occurs in non patched version too. I see no reason for allowing more than one transformer per factory, and certainly not when fed from separate networks. The network max capacity should be enough to connect all your generators on a continent together for even the largest maps. If not, raising the max by using 64 bit numbers would be preferable to implementing the logic required to handle this case.

Should factories be limited to one transformer? Or extend the calculations to handle multiple? Remember though, this is Simutrans not Simupowersystem.



Gameplay changing extensions:

Should a powerplants fuel consumption be based upon its energy output?
Easy to add, but is it desired gameplay...

Are different levels of transformer station desired?
Currently it would be uneconomic to connect a transformer station onto pak128s wind turbine. It simply doesn't produce enough power to pay the maintenance on the transformer, even allowing for the increased downstream factory production. Different levels of transformers could have different power handling capacities and the extra maintenance to go along with it. New graphics would be required which makes this unlikely...  Alternatively, the base cost could be lowered, power limit added, and multiple transformers (connected to the same network for simplicity) required for large power plants/factories...



Please test and give your thoughts...

vilvoh

I didn't have a look at the patches, but imho the way these patches show powerlines info is really helpfull and much more clear than the current one. I'm looking forward to see them included in the stable branch.

Escala Real...a blog about Simutrans in Spanish...

jonasbb

QuoteShould factories be limited to one transformer? Or extend the calculations to handle multiple? Remember though, this is Simutrans not Simupowersystem.
I think it is enough if every factory only has one transformer.
The porwer stations also have only one transformer.

wlindley

Would there be a way to define the wind turbines as a generator with built-in transformer?

And with the recent river upgrades, could we define a hydroelectric dam?

VS


My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

IgorEliezer

#5
I liked it. A lot.

Let me say a thing: I don't know why we should worry too much about "this is a transport simulator" thing and focus exclusively on transportation as if nothing else exists. Once powerlines are there, I think it deserves a bit of attention too and could receive some improvements. Until now, the information provided by powerlines has been unreadable. So, this patch is more than welcome.

Sorry for being a tad nitpicking, but, I'd like to suggest that units should be placed after the numerals, for consistency:

% Supplied: 100 => Supplied: 100%
Gen. Usage %: 49 => Gen. Usage: 49%

;D

prissi

#6
I think the power system was in for an overhaul anyway. Though I am a little confused if patch 1 is still need, when factories produce every step. But I will test it and see how well it works with the killer games.

I would also make the iterator static functions of their classes. This is imho the nicer way compared to bloating up karte_t further.

And what is the relation of MW to money? This should be defined then in the money_frame.cc dialoge.

I would really like to include it, with this issue discussed. And there is another technical showstopper for applying your patch: please, use *tabs* not spaces. Your patch break the formating completely.

TurfIt

Quote from: prissi on February 14, 2010, 07:16:57 PM
And there is another technical showstopper for applying your patch: please, use *tabs* not spaces. Your patch break the formating completely.

@#$(#, !@$*#%@, and then $%&^*$&!. Was using tabs, then changed development machines, and the use tab option turned off. Why is using spaces even an option let alone the default. $%^#%$#. [/rant]

Patch 4 despaced: http://simutrans-germany.com/~patches/download.php?file=powernet4_tabbed_r3107.zip [8k] .diff
Note: a couple areas in the files I modified unrelated to my powerline patch are also despaced in this diff.


Quote from: prissi on February 14, 2010, 07:16:57 PM
I think the power system was in for an overhaul anyway. Though I am a little confused if patch 1 is still need, when factories produce every step. But I will test it and see how well it works with the killer games.

Patch 1 is not needed if patch 2, 3,or 4 is used. Patch 2 not needed if 3 or 4 used, 3 not needed if 4 used. They are standalone.


Quote from: prissi on February 14, 2010, 07:16:57 PM
I would also make the iterator static functions of their classes. This is imho the nicer way compared to bloating up karte_t further.

I'll look into this. My C++ is rather rusty being ~15 years out of date... Any examples in the Simutrans code? I just followed what was being done with the other stepped classes.


Quote from: prissi on February 14, 2010, 07:16:57 PM
And what is the relation of MW to money? This should be defined then in the money_frame.cc dialoge.

I didn't touch the money code. Same revenue earned in trunk should be earned with this patch.


Quote from: wlindley on February 14, 2010, 01:30:28 PM
Would there be a way to define the wind turbines as a generator with built-in transformer?

I don't see any obvious clean way to implement such functionality. Is there a reason why this is desired?


Quote from: wlindley on February 14, 2010, 01:30:28 PM
And with the recent river upgrades, could we define a hydroelectric dam?

This is more a limitation of the factory placer/climate routines. Beyond the scope of this patch I'm afraid...

jamespetts

This looks very promising indeed. I had made some GUI-based changes to power in Experimental, but this looks to be a more thorough and useful overhaul. Excellent!
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.

prissi

Another remark:
power_load * PRODUCTION_DELTA_T / last_power_demand
should use brackets, otherwise the result may be implementation dependend. (Or maybe not, I learned C at K&R times.)

And with static I mean:

class powernet_t
{
private:
  static slist_tpl<powernet_t *> all_nets;
...
public:
  static void init() { all_nets.clear(); }
  // this will iterate over all nets and step them
  static void step( long delta_t );
...
};

all adding and removing will be handled then by the pwoernet_t class itself. To me, this is much more OOP, but we can discuss.

TurfIt

#10
Quote from: IgorTekton on February 14, 2010, 06:54:33 PM
I'd like to suggest that units should be placed after the numerals, for consistency:

Done.


Quote from: prissi on February 14, 2010, 09:48:47 PM
power_load * PRODUCTION_DELTA_T / last_power_demand
should use brackets, otherwise the result may be implementation dependend. (Or maybe not, I learned C at K&R times.)

Should be ok as is. *, / have the same precedence and l-to-r evalulation.


Quote from: prissi on February 14, 2010, 09:48:47 PM
all adding and removing will be handled then by the pwoernet_t class itself. To me, this is much more OOP, but we can discuss.

Done. Looks much cleaner.

Patch 5: attached
 powernet_t, pumpe_t, senke_t  OOPed; karte_t shriveled.
 % display after numerals.
 Minimap display changed to show generator loading.

Patch 6: attached
  Factories limited to one transformer.

neroden

#11
Awesome patch.  Hope this goes in soon.

(Edit: my thoughts on some of the design questions, FWIW)

Quote from: TurfIt on February 14, 2010, 05:43:28 AM
Known issues:

Multiple transformer stations from different power networks attached to the same factory can produce some strange results. This occurs in non patched version too. I see no reason for allowing more than one transformer per factory, and certainly not when fed from separate networks. The network max capacity should be enough to connect all your generators on a continent together for even the largest maps. If not, raising the max by using 64 bit numbers would be preferable to implementing the logic required to handle this case.

Should factories be limited to one transformer? Or extend the calculations to handle multiple? Remember though, this is Simutrans not Simupowersystem.
While multiple transformers are reasonably realistic, multiple transformers from different networks begins to get into "power grid management" territory.  While one could make a game about managing the flow of power on the grid, I think Simutrans should be a game where the grid simply "works", with all the people in the grid interconnect offices assumed to be working behind the scenes.  In the real world grids are all interconnected whenever possible, even though the interconnects are managed and turned on and off by humans as needed.

Currently multiple transformers allow for boosting factory production rates to very high levels (four times the base level with three transformers); this can create rather unplayable situations already, so there's good reason to restrict a factory to a doubling of its production rate, which means one transformer.

So yeah, one transformer per factory sounds good.

Quote
Gameplay changing extensions:

Should a powerplants fuel consumption be based upon its energy output?
Easy to add, but is it desired gameplay...
Well, fuel consumption should definitely be proportional to (max) generation at least, but I think it already is.  Should it be proportional to actual load?  I'm actually not sure what's more realistic: in the real world, coal plants tend to burn whether or not anyone's using them, oil plants tend to turn on and off!

QuoteAre different levels of transformer station desired?
Currently it would be uneconomic to connect a transformer station onto pak128s wind turbine. It simply doesn't produce enough power to pay the maintenance on the transformer, even allowing for the increased downstream factory production. Different levels of transformers could have different power handling capacities and the extra maintenance to go along with it. New graphics would be required which makes this unlikely...  Alternatively, the base cost could be lowered, power limit added, and multiple transformers (connected to the same network for simplicity) required for large power plants/factories...

Different levels of transformer is a good idea, but actually I think it's OK to have one level of transformer with full capacity, and transformer maintenance costs should simply be very low.    The upfront cost of building the transformer should be very large, though.  This would solve the gameplay issues; the cost of maintaining the transformer would be covered by the wind turbine electricity and the only question would be how many years it would take to pay back the capital costs (which would depend on how much profit you could make from the enhanced production, etc.)

In reality they will last for decades with fairly little maintenance (http://www.electricity-today.com/et/Aug99/transfor.html) ; huge transformers from the 1920s were only replaced when it was decided that the toxic chemicals in them should be cleaned up.  More modern transformers last even *longer*.  So "realism" says to set the maintenance costs low.  But they cost a lot to build and install, realistically.

neroden

-poke-

This patch seems to represent a major improvement.  Is there any chance of it going in?  Or should I roll my own variant of simutrans with it?

jamespetts

Neroden,

if you'd like to merge this into Experimental and maintain it, that'd be a possibility, too. But this seems like it would be a good patch for Standard.
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.

neroden

Quote from: jamespetts on May 11, 2010, 04:56:19 PM
Neroden,

if you'd like to merge this into Experimental and maintain it, that'd be a possibility, too. But this seems like it would be a good patch for Standard.

Given my current repo setup, I could attempt to maintain it in git as a patch to standard *and* merge it in experimental (oh the joys of distributed version control!)

Dwachs

Quote from: neroden on May 12, 2010, 03:40:47 AM
Given my current repo setup, I could attempt to maintain it in git as a patch to standard *and* merge it in experimental (oh the joys of distributed version control!)
This would be very nice!
Parsley, sage, rosemary, and maggikraut.

neroden


prissi

incorporated with 3274 into standard in version 6