Add maximum atmos temperature limit

[Partmedia]

About the PR

Adds Atmospherics.Tmax, a maximum absolute temperature temperature limit for gas mixtures.

Why / Balance

Safe numeric code enforce numeric ranges to be within a certain well-defined range. For example in a temperature simulation, it is safe to constrain temperature in a "reasonable" range where we know that the physical laws stop applying. There is already such a limit for the minimum temperature; this adds one for the maximum temperature.

This should never happen:

And of course while it is better to fix the problem at the root, bugs happen and code should still be robust.

Balance

Anything that scales with temperature, e.g. damage and reaction rates, can still go through a very big range with this temperature cap.

Physical Justification

These sorts of temperatures would never exist in real life for a variety of reasons:

• At some pressure the container would just explode, venting it
• At some temperature the container would just melt, also venting it
• At some temperature any gas would instantly converted to plasma, causing it to violently destroy the container

While it is true that temperatures exceeding this can exist on stars, that sort of defies the simple $PV=nRT$ physics we have. In numerics speak, we'd say that this is out of the domain of our model.

[Ilya246]

1. i'm pretty sure this makes maxcaps impossible even if we fix the other changes
2. 20000C is very little, unless we revert this once we get pipe bursting
3. i believe this kills a lot of TEG setups
   setting it to around 200000C or 140000C should work better

note that before burn changes i was able to reach about 1.1GK of temperature, it's likely only much lesser values are now reachable, i would doubt even 1MK is reachable
also, absurd temperatures make it easier to spot if it's bugged

[EmoGarbage404]

@comasqw if you're gonna shit up github with childish finger pointing at volunteers then you're just going to get banned.

You're not going to get many warnings.

[TemporalOroboros]

I strongly dislike the idea adding an upper temperature limit to atmos on principle. If we absolutely must, I request it be set to the Hagedorn or Planck Temperature as those are actual physical limits instead of some arbitrary cutoff.

[Holinka4ever]

In my honest opinion, early or later, they should be limit, due of humanity progress, cause its kinda funny and unlogical that atmos are able to syntez an entire sun in burn chamber that made from steel and glass.

But due of recently bug that allows to do it... Thats pr is looks like a bandaid of that mistake, rather than balance fix, and of corse, people will be on emotions, cause atmos the most intriguing and interesting mechanic in ss14, and it got limited due of bug.

So anyway, idea of giving limit is okay, someone told that instead if limiting, heat could be on fast cool itself due of some laws that i dont know, but making this due of "plasma flood" situation, is kinda harsh path to walk in.

[Emisse]

agree with temporal, seeing atmos hit exceptionally high numbers is also helpful for indicating a bug is present

[Partmedia]

I strongly dislike the idea adding an upper temperature limit to atmos on principle. If we absolutely must, I request it be set to the Hagedorn or Planck Temperature as those are actual physical limits instead of some arbitrary cutoff.

I gave a few physical justifications for why a limit should exist in the PR description. The ideal gas law, and indeed the physical state of gas breaks down at high enough temperatures. What principle do you feel like is being broken?

Perhaps the limit set here is too low. Some here have suggested a few higher limits. I'm okay with a higher limit, we should decide what it should be.

There would still be ways to catch bugs, namely:

1. Hitting the debug exception that this adds.
2. Seeing the temperature limit be reached. Maybe the current limit is too small. But surely there is some limit that we can agree on should never be reached.

It feels like there is no limit now because you can represent infinity as a floating point. But due to floating point precision issues there already is a limit beyond which things just stop behaving correctly (see why we have to have space friction to limit the distance something flies from the station).

I'd liken this to a numeric seat belt that reduces damage when something goes wrong. A seat belt is not a band-aid.

So anyway, idea of giving limit is okay, someone told that instead if limiting, heat could be on fast cool itself due of some laws that i dont know, but making this due of "plasma flood" situation, is kinda harsh path to walk in.

All gases cool to tiles, then to space, when superconduction is enabled. Superconduction is not enabled by default for a variety of reasons. In practice that would also limit temperatures because it's hard to fight $T^4$ scaling.

[Ilya246]

Seeing the temperature limit be reached. Maybe the current limit is too small. But surely there is some limit that we can agree on should never be reached.

once again, i propose 200kK, i believe that temperature is not reachable naturally unless you're deliberately trying to optimise a burn for extremely high temperatures and nothing else
but i still suggest either not having a limit or reverting this once we get pipe bursting

[deltanedas]

20kC is nowhere near physics breaking and the starting point for a lot of burns
this will completely gimp teg

[LordCarve]

• At some pressure the container would just explode, venting it
• At some temperature the container would just melt, also venting it
• At some temperature any gas would instantly converted to plasma, causing it to violently destroy the container

1. We don't actually know that. But I'd rather not take this discussion off topic so this is just a minor observation.
2. All of the above are cases where forces exerted on the container result in its destruction. That is a missing feature at the moment. Add the feature = all the above are solved.

"Physical Justification" doesn't convince me.

Safe numeric code enforce numeric ranges to be within a certain well-defined range.

Yes, but... that is a loaded statement. Programmers can make "safe numeric code" in range of -∞ to +∞ with whatever decimal precision they desire. Limiting the range is very handy for optimization and lowering problem complexity, but by no means necessary to achieve "safety". All that statement does is confuses people who aren't sure what you are talking about into thinking it's an argument in favor of introducing a max temperature. It isn't.

Back to topic:
Consider that you need to make the following operation (i.e. in order to maintain formula invariance): Atmospherics.Tmax + Atmospherics.Tmax. What is the result of this addition? Well, it has to be Atmospherics.Tmax surely?

Such an arbitrary maximum introduces new edge-cases (possibly bugs), above being just one example, because now we are violating laws of not just physics, but mathematics as well. ∃x ∈ ℝ / { 0 } (x + x = x). That is going to bite us in the ass sooner than you think.

If (and this is a very big if) we wanted to limit temperatures, in my opinion the best way to tackle this problem is by introducing some form of "temperature entropy" which would soft cap temperatures in a sane range, rather than hard capping it, like this:

• Any temperature decays over time
• Decay scales with temperature
• Effects are negligible (rounding to zero) for all temperature ranges we don't want to touch
• Effects are increasingly severe the more above that range we go, so in time any temperature eventually goes down to "soft max"

We can call it quantum thermal conductivity, whatever.

That being said - the question we should be asking is: are we sure we want a limit?

[Partmedia]

That being said - the question we should be asking is: are we sure we want a limit?

Absolutely. In fact there's already a limit, it's called float.MaxValue. But limits of floating point precision mean that some operations don't behave as you would expect at much lower values.

Such an arbitrary maximum introduces new edge-cases (possibly bugs), above being just one example, because now we are violating laws of not just physics, but mathematics as well. ∃x ∈ ℝ / { 0 } (x + x = x). That is going to bite us in the ass sooner than you think.

We're programming with real computers with real limits on the number of bits in the mantissa. The objective of this is to limit values in a range where floats behave relatively sanely. If you want to see on your own computer:

Python 3.9.18 (main, Sep 12 2023, 01:16:40)
>>> 3e305 + 1.1e305 - 1.1e305 - 3e305
-3.89812560456e+289

That number is not zero.

If (and this is a very big if) we wanted to limit temperatures, in my opinion the best way to tackle this problem is by introducing some form of "temperature entropy" which would soft cap temperatures in a sane range, rather than hard capping it, like this:

I welcome a patch. Even then, a limit is prudent to make sure big numbers can actually return to zero. As I showed above, $x + y - y - x$ is not equal to zero when $x$ and $y$ are very large.

Tmax bumped to 200e3 K.

[deltanedas]

before burn energies were nerfed, 200kK was very much a reasonable temperature you could get in normal gameplay. after the nerfs i doubt its possible to get without a dedicated max temp setup.

[LordEclipse]

before burn energies were nerfed, 200kK was very much a reasonable temperature you could get in normal gameplay. after the nerfs i doubt its possible to get without a dedicated max temp setup.

did the nerf break atmos? Because atmos has been acting very funky for the past few days or so

[deltanedas]

burn nerf was just changing energy values so thats not related

[Partmedia]

before burn energies were nerfed, 200kK was very much a reasonable temperature you could get in normal gameplay. after the nerfs i doubt its possible to get without a dedicated max temp setup.

That's because the energies from before were unreasonable. The "hard" limit should not be reachable through normal gameplay.

did the nerf break atmos? Because atmos has been acting very funky for the past few days or so

No. This is better addressed in a separate thread, but the breakage is likely from #22803 which was partially addressed in #22876. I am aware of another issue but am waiting for an okay to adjust the clamping behavior of AdjustMoles().

[deltanedas]

energy from before was not unreasonable compared to how it is now

ring.of.fire.mp4

this fire from ~30m ago is now at about 1200K, which is extremely slow burning and cold when it should be fast and hot

[Ilya246]

before burn energies were nerfed, 200kK was very much a reasonable temperature you could get in normal gameplay. after the nerfs i doubt its possible to get without a dedicated max temp setup.

actually no, before burn changes, even the hottest TEGs only got to around 90kK, and you couldn't reach anywhere above 140kK without deliberately building a temperature-burn setup due to how burns work

note that i believe that 200kK is still reachable even after burn changes, but you'll need a special temperature-burn setup to achieve it

[LordCarve]

Absolutely. In fact there's already a limit, it's called float.MaxValue. But limits of floating point precision mean that some operations don't behave as you would expect at much lower values.

That is not a design choice. It's a programmer choice to use an existing data structure (float) to store the data here. From design perspective this is just an implementation detail. What we are doing in this PR is making an implementation detail affect design decision, like this:
"Float has limitations when dealing with large numbers, therefore we should disallow very high temperatures"

Implementation => Design. That's a backward approach. The correct approach is Design => Implementation:
"We don't need to support very high temperatures, therefore float is a good data structure to use for temperature calculations"
or
"We need to support very high temperatures, therefore float is not a good data structure to use for temperature calculations"

This is why the most important question we should be asking here is the question concerning design:
Are we sure we want a limit?

There are some implementation concerns which I mentioned before that do affect the design choice:

• float algebra with all common operations is already implemented (we are saving developer time),
• floats are well known (makes the code much more maintainable over a custom-made data structure - this is a huge deal for an open source project),
• FP32 operations are natively supported by CPUs making complex calculations fast (optimization)

And all these are good arguments for using floats. But floats come with some limitations (the object of this PR - very high values). So a design decision needs to be made.

We're programming with real computers with real limits on the number of bits in the mantissa.

Computers have no issues with custom data structures - even data strutures of potentially unlimited size. Floating point representation is just one of the possible number representations. In fact, I'd argue that is not the perfect fit for values such as temperatures, because floating point numbers operate on one core assumption: X-th significant digit is just as important as X-th decimal digit. I honestly don't think we care about 1 × 10⁻¹⁰ (that is one ten-billionth of a single degree) as much as we care about 1 × 10¹⁰ (ten billions degrees). So the problem is naturally skewed towards higher values over more precise values.

---

The PR is a stopgap solution, and it's OK at that:
Solves some problems, probably introduces new problems, but it does no drastic changes* and requires minimal effort.
* - let's make sure it doesn't by setting the limit appropriately high.

I'm not against merging it, but it touches on a very important design decision of temperature limit. If we just skip over it and merge the PR without having a discussion, this code (the temperature limit) kinda becomes "the base truth" for future contributors.

So I want a design decision be made here. Do we want a temperature limit or not?
To make things extra clear - this PR is fine in either scenario:

• If we don't want to support obscenely high temperatures, then this PR is a stepping stone towards that;
• If we do want to support obscenely high temperatures, then this PR is a temporary fix until we can build a proper solution

Probably needs some tweaking to what the limit should be (already happening in this discussion thread) but other than that it's fine.

I want to avoid a situation where this gets merged without proper design process, one half of contributors think this is a temporary stopgap and avoid building on top of it, while the other half of contributors assume this is the hard design limit for temperature and do build on top of it, further entrenching it as the hard limit.
And then, someone gets the idea that we want to simulate nuclear fusion or something, which requires temperatures above the Atmospherics.Tmax. But we have an entrenched hard limit on temperature that needs so much effort to change, that nobody wants to do it. So we can't. And we end up missing out on cool features such as nuclear fusion.

[EmoGarbage404]

200,000K is literally hotter than a fucking star. this is just to make sure floating point math doesn't shit itself and die at unreasonable values (a perfectly valid concern and something to account for). There's no reason why a realistic atmos sim would reach those temperatures nor would even the ability to occasionally reach those temperatures justify the additional performance cost of migrating the entire system to use high precision.

[Ilya246]

200,000K is literally hotter than a fucking star. this is just to make sure floating point math doesn't shit itself and die at unreasonable values (a perfectly valid concern and something to account for). There's no reason why a realistic atmos sim would reach those temperatures nor would even the ability to occasionally reach those temperatures justify the additional performance cost of migrating the entire system to use high precision.

actually no, there are no such issues, floating point math is unrelated
i don't think there was any real reason to merge this

[Partmedia]

Thanks for writing in with your comments.

So I want a design decision be made here. Do we want a temperature limit or not?

The design decision was to limit pressure and temperature in most atmos devices. In practice pressure limits are set by bursting and temperature limits (through what you call "quantum thermal conductivity") are set by the (currently-disabled) "superconduction" code. This is partially implemented e.g. in #20931 but not quite ready for show time just yet.

Perhaps that is where our fundamental miscommunication was. I do appreciate your thoughtful comments here.

[LordCarve]

200,000K is literally hotter than a fucking star.

200kK is not hotter than the sun. The helium fusion that happens inside the sun is estimated to require catalysis temperature of 14mK which is 7 times that.

this is just to make sure floating point math doesn't shit itself

Agreed. This is always a concern with floating points.

Perhaps that is where our fundamental miscommunication was.

Yup. This is what was missing in this PR. A link to atmos roadmap. Thanks for clearing it up.
Next time please link such docs in potentially controversial PRs like this. The design process behind decisions is always important to consider.

This is doubly important since this is an open source project and anyone can create a PR. Without such docs it's often difficult to distinguish some random person electively proposing a questionable change, from an established contributor making a PR of a planned and well-considered change. I've only been here for a week and I've seen both - nearly indistinguishable.