Description of Heat Bug, Exploding Parts, and two Proposed Solutions

[danfarnsy]

From my understanding of the heat system, during a physics update, adjacent parts check each other for their relative temperatures, and based on their mutual heat conductivity values, shared surface area, and the magnitude of their temperature difference, the hotter part will "give" a portion of its heat to the cooler part. But because heat isn't the same thing as temperature, larger mass parts store a lot more heat than smaller ones for a given change in temperature, just like it takes more energy to raise a large block of copper 1 K than it takes to raise a small block of copper by 1 K. Unlike real blocks of copper (or some special material which Kerbals make all of their parts from, since most of them have the same heat capacity per unit mass), heat in a part is distributed evenly throughout the part, instantly. So if a small part is next to a large one, and they aren't at the same temperature, the heat system gets confused, and here's how:

When the system is deciding how much heat to transfer during a step, like I mentioned above, it calculates a certain amount of heat to transfer. If the parts are similar in thermal mass, this usually isn't an issue, as they'll transfer a certain amount, and then a little less, and a little less, until they come into equilibrium. If the parts are different enough in thermal mass, the system can overshoot in how much heat it transfers during the update. For example, if you have an FLT-800 fuel tank connected to an octagonal strut, and the fuel tank is a few K warmer than the strut, the fuel tank will try to transfer a small portion of the heat that makes up the difference in their temperature. The strut doesn't have much heat capacity because it is so small, so while the FLT-800 cools slightly, the strut's temperature increases a lot more. If the new temperature difference between the parts is smaller than the first difference, it may continue to oscillate back and forth, but it will get smaller and they'll eventually reach an equilibrium. But it is possible for the new difference in temperatures, if the difference in heat capacities is large enough, to be larger than the first one, and then the next update transfers even more heat to correct the first one, and then it transfers even more, with the small part fluctuating wildly at ever increasing amounts, until on the low end it is at 0 K and on the high end it is nuclear fusion. Add multiple parts interacting at the same time, like engines generating heat, solar irradiance, special parts like service and cargo bays which protect their contents from the heat system until they're opened (then the temperature difference can be significant enough to make this runaway oscillation happen very quickly and reproducibly), and Roverdude's radiator module in the stock radiators which conceivably adds to the instability once the high end of the temperature is hot enough (25% of the part's max temperature).

The active heat management module from the stock radiators (the deployable ones, not the static radiators) checks all parts in the ship to see if they are above a certain temperature (unless otherwise specified in the part config file, it's 25% of the maximum temperature). If the part is above this temperature, the radiator pulls heat from the hot part and then gets hotter itself, eventually radiating the heat away. But the way the update works, and Roverdude or somebody with enough familiarity with the system can correct me if I'm wrong, the heat system updates the temperatures during a step. Then the radiator checks the parts to see if their temperatures are above a certain value. If so, it actively pulls heat from the too-hot part, but if the part was also giving too much of its heat away to neighboring parts through conductivity, because it didn't have much capacity to begin with, it will cool off too much. During the next update, the radiator sees that the part is no longer too hot, and it doesn't do anything, but the now-cold part will absorb a large amount of heat from its neighbors, becoming even hotter. This oscillation will, again, grow larger until the part exceeds its max temperature and explodes.

This is numerical instability. The time step in the game has to be larger than a certain size, because the system gets bogged down with high part counts. Our CPUs, even the high-end ones, already are crying for mercy without making it work even harder to have a better fidelity with what heat transport should do in real life by having a smaller step size.

So here's what I propose: create a slight change to the way heat is conducted to adjacent parts. Before the amount of heat to transfer between parts is calculated, have a parameter composed of some tunable factor 's' and the ratio 'R' of the parts' heat capacities 'c1' and 'c2', where c1 > c2 and R = c1/c2. Take your current system that calculates the amount of heat to transfer and simply multiply it by s/R. This effectively reduces the mutual conductivity between large and small parts, allowing what would have previously been oscillating overshoots that grow larger with time (like a resonant driven oscillator) to damp out toward equilibrium instead. It is an added unrealism, but because it is necessary to treat parts as single items with single temperatures (well, two, skin and internal, but you get the idea) to avoid serious computational complexity, we have the unrealism of entire Rockomax Jumbo-64s comparing their temperature differences with attached octagonal struts and alternately dumping and retrieving too much heat in successive physics updates, with small computational errors that quickly become large ones because of the limitations of Euler's method.

Another solution is to reduce the stepsize, though this will hurt CPUs which are frequently tapped out as it is. The error in the Euler method is proportional to the square of the step size, implying that if the step size was reduced by about 30%, we could cut the magnitude of errors in half, which could conceivably reduce the number of anomalously exploding parts by much more than 50%, if many of the circumstances which lead to growing oscillating errors were fairly close to borderline and instead are brought far below the threshold for runaway instability.

[gilflo]

It would be great to update the system that manage heat ! There's a lot of situations that are not playable, du to this heat bug.

For example, a big spaceplane on the runway, carrying a smaller one on its back or on its belly is "heat unstable" and the whole thing will finally exploses, before you have begun to use it.

Even with Alt F12, dealing with thermal conductivity slide, does not allow to make the thing stable.....

On the contrary, each plane alone on the runway would not deal with that heating bug.....