Improved fluid simulation threading. Decreases CPU usage. Threading available on all operating systems. Simulation performance should remain unchanged.
Bugfixes
Fixed a crash when importing blueprint strings with power switch wires.
Fixed fluid mixing for fixed recipe assemblers. (69676)
Fixed "Not enough rails" message after successful track placement. (69930)
Fixed a crash when destroying entities during the on_pre_ghost_deconstructed event. (69965)
Fixed that trains with "logistics while moving" disabled would not deploy robots when switched into automatic mode while waiting at a station (69914)
[*] Improved fluid simulation threading. Decreases CPU usage. Threading available on all operating systems. Simulation performance should remain unchanged.
I don't understand this one. Fluid simulation is better threaded and decreases CPU usage... but performance should remain unchanged? Will it get me more UPS or not?
Re: Version 0.17.34
Posted: Sat Apr 27, 2019 11:24 am
by Koub
If I understood correctly, they added some more calculations to make the fluid simulation more realistic, but improved the multithreading in calculations so this didn't degrade performance.
Re: Version 0.17.34
Posted: Sat Apr 27, 2019 11:39 am
by Bilka
Here is a summary from Twinsen after someone else asked about it:
Twinsen wrote:So:
- fluid multithreaded update was windows only because it used some weird multithreading code
- fluid multithreaded update was also uing spinlocks, so it was causing unnecessary cpu usage on all cores.
- i changed that in this version. It will no longer use extra cpu. also it will be multithreaded on all OSes. the mentioned change should not affect the UPS performance of pipes on windows
Here is a summary from Twinsen after someone else asked about it:
Twinsen wrote:So:
- fluid multithreaded update was windows only because it used some weird multithreading code
- fluid multithreaded update was also uing spinlocks, so it was causing unnecessary cpu usage on all cores.
- i changed that in this version. It will no longer use extra cpu. also it will be multithreaded on all OSes. the mentioned change should not affect the UPS performance of pipes on windows
One interesting datapoint here is that if you use standard C++11 threads and mutexes, all locks will be adaptive spin-locks on Linux. I discovered this via testing awhile back, though I suspected it was true (which is why I tested).
Re: Version 0.17.34
Posted: Wed May 01, 2019 1:07 pm
by KostarSF
Perhaps this has already been reported earlier, and maybe it's not a bug, but still.
If two steam turbines powered by the same heat exchanger are running at full capacity, the electricity meters in the "electric network info" are flickering when steam in steam turbines is not enough: https://youtu.be/495JF8jupQU
Remove one of the steam turbines on each heat exchanger so there's only one turbine per exchanger. Does the flickering go away?
Energy production/usage figures are a median of the actual energy consumption/production at a given tick. Due to poor fluid simulation with large fluid boxes and small amounts of liquid you can get what is essentially fluid teleportation.
The steam in the two turbines can jump back and forth between the two turbines per tick leaving one completely empty and the other with just enough to operate on that one given tick.
Hence, without the median values, you would actually be seeing a per-tick on/off cycle of half your production capacity.
To resolve the issue (if you perceive it as such) you can put a pump between the turbines so fluid can only flow one direction. But better yet would of course be to ensure you have enough steam to operate all turbines.
EDIT: I am sure this will resolve itself with the fluid mechanics update whenever that's ready.
are flickering when steam in steam turbines is not enough
The meters flicker because the production is different on different ticks. The production is different because the ratio is not perfect. The heat exchanger consumes heat at the constant rate of 10 MW. The turbine consumes steam at 1 unit per tick. But the heat exchanger produces 10MJ / 0.097MJ ≈ 103.09278350515464... units of steam per second. Your turbines have no way to consume this odd amount of steam at a constant rate every tick. Some tiny steam leftovers displayed as 0.0 are carried into the next tick. This is enough for the meters to display less than 10MW on some ticks.
You may argue in favour of enhanced rounding for the meters to display 9.99999MW as 10MW not 9.9MW.
It has nothing to do with any kind of teleportation or fluid mechanics. It's about ratios and rounding.
Ah yes, cut out the bit you clearly misunderstood about my post and respond incorrectly to that.
Can you disprove my statement with experiments?
Because i've actually experimented with large fluid boxes and they do cause what can only be described as teleportation with small amounts of liquids being split over several fluid boxes.
Sure, you somewhat are right in that under the hood this is due to "rounding" (floating point numbers) but due to how the game handles fluids, any leftovers (I.E, not actually consumed by exchanger 1) will move over to the other exchanger and since that amount is tiny it will move back and forth rapidly in "pipes" until there's enough inflow to stop it.
It IS essentially fluid teleportation because at those low amounts, fluids WILL move across the entire pipe network in a single tick and it depends on build order where the fluid moves to.
It has nothing to do with any kind of teleportation or fluid mechanics. It's about ratios and rounding.
Ah yes, cut out the bit you clearly misunderstood about my post and respond incorrectly to that.
...
It IS essentially fluid teleportation because at those low amounts, fluids WILL move across the entire pipe network in a single tick and it depends on build order where the fluid moves to.
You are right, there IS teleportation. I have been seeing it in the game for years. I did not need you to explain it to me. So I guess I did not misunderstand the most important part of your message.
Details and screenshots
Once again. Fluid teleportation does not cause meter flickering.
You can meter the turbines separately.
Turbines were built right-to-left. So steam teleports to the left one. This turbine consumes exactly 60 units of steam per second and it produces exactly 5.82MW of energy which is rounded down to 5.8MW on the meter.
The right turbine can only consume the leftovers on the next tick. And that is where the fluctuations happen. The meter is not flickering though. It displays 4.1MW which is 10 - 5.82 = 4.18 rounded down. There is no flickering because the fluctuations are less than 0.02MW and they can not jump above 4.2MW. Try building 5 of these to see them flicker. Wait a minute, I have built them for you:
It flickers 20.8MW to 20.9MW.
When you meter both turbines the meter adds perfect 5.82 to the fluctuating 4.18 with the resulting 10MW fluctuating from 9.999999 to 10.000(idonotknowhowmanyzeros)001. The meter round them to 9.9 and 10.0.
Why are there fluctuations in the first place? The heat exchanger produces a weird amount of steam. You cannot really express 10 / 0.097 as a floating point number because you would need an infinite number of digits. Like this:
103.092783505154639175257731958762886597938144329896907216494845360824742268041237113402061855670103...
and then it repeats (092783505154639175257731958762886597938144329896907216494845360824742268041237113402061855670103) all the way to the infinity.
Meanwhile the heat exchanger needs some way to consume/produce perfect 10MW of energy. This is done by producing slightly less on one tick and slightly more on the other tick. This results in flickering of the meter down the line. The other option would be to round the weird number down to the precision of the hardware floating point operations which would make you unable to see 10MW on the meter.
Whatever fluid mechanics you choose, teleport or not, the meter flickering will be there as long as the heat exchanger production fluctuates every tick.
Great job guys (y).
