Experts, I Need Help with Understanding Thermal Conductivity

[goatt]

I'm reading about Thermal Conductivity and floating number ignorable Temperature. I found fomula here in wiki.

I tried the Math, I cannot reproduce the 715.6kg Magma result.

 

Then I went into the game and created some Igneous Insulated Tiles (0 C) next to Magma (1409.85 C), the mass of Magma at which temperature exchange stopped was 568.4kg, which means, 715.6kg result in wiki is wrong?

 

I've spent too much time on this. I hope someone can help me. Thanks!

[Tigin]

Probably worth consulting @blakemw as he was the one who put it there

[Gurgel]

The floating point limit is a hard limit, in the sense that you cannot, under any circumstances get heat exchange when you exceed it. But it is not a sharp limit. You lose precision before you reach it and you can lose heat exchange before that limit due to these errors. It is just not assured that you lose the heat transfer. In that case, it just depends on the actual calculations done, including the exact numbers and usually even depends on the order the calculations are done in.

Floating point stuff is freaky. For good calculations, you want a lot more bits than you need. Short floats have 23 significant bits. For relatively precise calculations, you want to not user more than about half of them. And in some cases even that will give you significant errors. 

My guess would be that if IEEE 754 double would be used (53 significant bits), you would probably struggle to demonstrate the limit and the loss of precision when you approach it, but it may be possible. Well, maybe not due to the other ONI heat transfer limits. But to be really sure, you might have to go to long double (113 significant bits). Note that long double has no hardware support on the typical PC platforms and becomes pretty slow. Some compilers (gcc, for example) do support it via software though. 

If you want to know more, the wikipedia pager for IEEE 754 is a good starting point: https://en.wikipedia.org/wiki/IEEE_754

[goatt]

2 hours ago, Gurgel said:

If you want to know more, the wikipedia pager for IEEE 754 is a good starting point: https://en.wikipedia.org/wiki/IEEE_754

I kinda know how it works. And I understand the meaning of the formula listed in wiki.

The problem is that it's not consistent with in-game testing, and the formula cannot reproduce the result in the same wiki.

 

Floating point implementation is relavent when it comes to the ignorable temperature based on original temperature. And I understand it, and I think that part of the fomular listed in wiki makes sense. However, I still can't reproduce the result.

[asurendra]

It depends on your own PC too. When lags starting, in order to reduce them, game start to skip some ticks. It mostly noticeable in automation timers inconsistency, but heat calculations works a bit differently too

[Gurgel]

On 1/30/2025 at 2:52 AM, goatt said:

I kinda know how it works.

I think you just missed the most important thing I wrote: Float limits are hard but not sharp. 

The experiment you ran might already be subject to a total loss of effect due to that.

[goatt]

On 2/1/2025 at 1:25 PM, Gurgel said:

I think you just missed the most important thing I wrote: Float limits are hard but not sharp. 

The experiment you ran might already be subject to a total loss of effect due to that.

The experiment I did was to tune temperature in 1C interval until I find the temperature that won’t change.

 

I set Magma’s tempura to very high, then lower it 1 C at a time and monitoring total energy in unit Mega Joules. I tune the temp until the total energy stopped changing despite huge temp difference between magma and neighbors. The number I got was consistent across my several runs. Game speed was at x1.

(technically I used binary search for the temp, and final precision was at 0.1C interval)

 

So as far as I can tell, it doesn’t contradict to what you are saying, that it is a hard limit.

 

what exactly did you mean by “loss of effect”? I assume you meant that as a source of error?

[Gurgel]

On 2/5/2025 at 7:27 AM, goatt said:

what exactly did you mean by “loss of effect”? I assume you meant that as a source of error?

Ah, sorry. This is when the adding of heat has no or reduced effect. As I do not know what exact calculations they do, I called it "loss of effect". Example: When a + b = a, then the addition of b has a total loss of effect. When a + b < exact_add(a, b) then that is a partial loss of effect of the addition.

Because this is binary, you can often get a total loss of effect half a bit before the hard limit, meaning around a factor 1.4 removed from the hard limit. But it depends on the concrete numbers. In your experiment, you might see this from around 1000C difference. And when you go from 1000C to 1400C difference, the effect may cycle between totally lost, partially lost and exact. Same for mass, as you found. When you increase the 568kg part, you may well find that heat exchange starts again. Or not. It really depends on the exact details of the calculations done. But 715kg / 1.4 = 510kg, so you are in the area where this can happen, but is not assured to. 

Anyways, this effect is not well studied because there is really no good way to compensate. The usual advice is to just use more bits. The only thing you can really depend on is the hard limit. 

[KittenIsAGeek]

Yeah, thermal can be kinda tricky with edge cases.  I've seen a dupe carrying a large mass of slightly-warmer material flash a 32g puddle of water into 400c steam.  The material the dupe was carrying is often only a couple of degrees warmer than the water, but the thermal energy that got transferred was enough to take that water up to 400c due to the difference in mass.  This should NOT have happened, but something about how thermal transfers get estimated while trying to reduce calculations is what causes it.

The reason I say this is because the problem never happens at normal speed while I'm focused on the area.   It is also rare enough that I can not cause it to happen reliably enough to even fill out a bug report.

[goatt]

On 2/7/2025 at 4:33 PM, Gurgel said:

Ah, sorry. This is when the adding of heat has no or reduced effect. As I do not know what exact calculations they do, I called it "loss of effect". Example: When a + b = a, then the addition of b has a total loss of effect. When a + b < exact_add(a, b) then that is a partial loss of effect of the addition.

I think, according to wiki, when a+b=a, the game checks this and will prevent the calculation entirely. Some extremely hot tiles won't exchange extremely cold tiles, because "loss of effect" is not allowed. So I think it doesn't happen in game, I guess?

(quoting sources: "The game has a rule that if either tile fails to change temperature, then no heat exchange is allowed to take place.")

And that's the point of my question: What is the largest temperature difference (delta T), that can cause a+b<exact_add(a,b), therefore, triggering no temperature exchange.

 

On 2/24/2025 at 1:17 PM, KittenIsAGeek said:

I've seen a dupe carrying a large mass of slightly-warmer material flash a 32g puddle of water into 400c steam... The reason I say this is because the problem never happens at normal speed while I'm focused on the area.   It is also rare enough that I can not cause it to happen reliably enough to even fill out a bug report.

This actually happened in my game quite often, and I think is designed on purpose.

I have all my designs with open doors, including the one housing 1000+C hydrogen rockets, with liquid doors that can easily evaporated when dupes carry 1000+C random debris from under the rocket.

The solution I'm using for 1000+C super hot room is to use a liquid of low TC and high SHC (e.g. Naptha), plus running cool radiant pipe through them.

The heat transfer rate (of inside tiles) is decided by the least TC of the two touching materials, so the total energy transferred is actually tiny. However, the packet of liquid is usually also too tiny to stay in liquid form..

[Gurgel]

3 hours ago, goatt said:

I think, according to wiki, when a+b=a, the game checks this and will prevent the calculation entirely. Some extremely hot tiles won't exchange extremely cold tiles, because "loss of effect" is not allowed. So I think it doesn't happen in game, I guess?

(quoting sources: "The game has a rule that if either tile fails to change temperature, then no heat exchange is allowed to take place.")

And that's the point of my question: What is the largest temperature difference (delta T), that can cause a+b<exact_add(a,b), therefore, triggering no temperature exchange.

You read that wrong. It just applies if there is total loss of effect on at least one tile. Partial loss of effect is not covered. 

[goatt]

On 3/4/2025 at 12:43 PM, Gurgel said:

You read that wrong. It just applies if there is total loss of effect on at least one tile. Partial loss of effect is not covered. 

I dont understand what you mean. Can you explain a bit more?

[Gurgel]

16 minutes ago, goatt said:

I dont understand what you mean. Can you explain a bit more?

If you go over the limit, a + b = a, no exceptions. That is a total loss of effect. If you stay below the limit, a + b < exact(a + b) is possible, but you may still get a + b > a even then. That is a partial loss of effect. 

[goatt]

On 3/13/2025 at 8:50 AM, Gurgel said:

If you go over the limit, a + b = a, no exceptions. That is a total loss of effect. If you stay below the limit, a + b < exact(a + b) is possible, but you may still get a + b > a even then. That is a partial loss of effect. 

In my understanding, the code double check after calculation whether there is a loss. If there is, then the calculation will not go through, or will be reverted.

For example X is big number and x is small number. If X + x = X, which means there is loss of x, then "X+x=X" will not happen. The right-hand-side X must be different from X.

If the calculated result of X+x is X+1, or anything that's different from both X and X+x, the calculation will still take place. But if the calculation's result is the same as X, then it will be not go through so that the loss doesn't happen in some extent.