Thermal control

[ccaviness]

Currently, there aren't many uses for the radiators in the stock game, apart from drilling. In the real world, however, thermal management is much more important. ISS has several large thermal radiators for heat dissipation.

It would be very cool (hah!) if Kerbalism would start tracking heating effects while in space, requiring the use of radiator panels to dissipate.

[gotmachine]

See this (very old) PR : ShotgunNinja/Kerbalism#105
and the (very old) issue : ShotgunNinja/Kerbalism#83

The reason why this has not been added yet is because there is a blocking issue with incorrect evaluation of radiator output and habitat heat gains/losses at high timewarp speeds. The old PR was aiming for the following features :

1. modelling of thermal conditions based on sunlight/shadow status and solar, albedo, body and background radiation, as well as basic convection/conduction flux when in atmosphere.
2. modelling of habitat heat flux based on 1.
3. modelling of radiator cooling capacity based on 1.
4. use of a coolant resource generated by radiators and required by exothermic processes

The problem is that 1. can't be reliably evaluated at high timewarp rates, resulting in chaotic behavior and random kerbal death. This is related to a common issue that kerbalism has with environmental conditions evaluation at high timewarp rates. It can maybe be solved, but there is no plans for that currently.

A less realistic system can be done and should work reliably, by eliminating everything that is unreliable in 1. :

• when in space, work on a always in sunlight assumption
• when landed / flying in atmo, the sunlight/shadow could be used, as well as convection/conduction flux
• radiation flux : evaluating only direct solar flux : no albedo nor body flux

[dgfl-gh]

I was thinking about the thermal system recently. Read a bit on what was in the linked issue and PR, but my impression was that it's not terribly relevant anymore.

The problem is that 1. can't be reliably evaluated at high timewarp rates, resulting in chaotic behavior and random kerbal death. This is related to a common issue that kerbalism has with environmental conditions evaluation at high timewarp rates. It can maybe be solved, but there is no plans for that currently.

This especially. My thought is that substepping may be accurate enough to overcome this issue, leading us to ignore the subsequent workarounds. Of course, correct me if that's not the case - you know your system far better than me.

I was therefore thinking again on the principles of the implementation, with an eye (or two) pointed at RO. We should design a system that isn't meant strictly for high power engines, but also for kerbals and electronics.

• It should handle steady-state things that are well-insulated from the external environment, such as humans in a capsule or avionics in a satellite bus.
• Parts should be organized in loops, which share the same temperature (like SystemHeat). Loops are identified by category (=a string, eg life support, computer, engines, etc.) and a number, in case the player wants more than 1 loop for a category. I'm thinking the module should have a default category and a field that says whether the player should be able to change the category.
• The only interactions with the environment should be radiative flux and conduction/convection from atmospheres.
  The module should define a thermal mass, and coefficients determining how fast it exchanges heat through radiation and conduction. I really liked your idea of defining absorbivity/emissivity, I'm thinking we could define that per loop rather than per part. Not sure if we can take exposed surface area into account, but it would be nice.

Big picture view: We build a completely separate thermal simulation. It only ignores aerothermal heating, but considers almost everything else. The stock thermal system has no way to model something very fragile inside a robust and well-insulated part, so our new system handles the (very important) requirements of the fragile part by considering it completely separate from the external structure.

I don't love the idea of completely ignoring structural temperatures, but I don't see another way to make it work. This kind of steady-state simulation is better than nothing, after all.

---

I've referred to the holder of parameters for each part as "module", but what it should be is not yet clear to me. We should surely use virtual resources ("flux in" and "flux out"), so a process seems like a good fit, but I'll have to investigate.

[gotmachine]

Some ramblings about this...

Possible implementation :

• thermalEnergy is the total energy stored in a loop
• A loop has a targetTemperature, automatically set according to the loop processes targetTemperature, but user-overideable
• Loop temperature is derived from the loop volume and thermalEnergy
• Processes have an operatingTemp range. They only work while the loop temperature is in that range
• Processes have a custom thermalEnergy I/O. TheIOFactor is determined as such : given the current loop temperature and the temperature headroom as defined by the process operatingTemp, a thermalEnergy max amount available to be consumed or produced is computed
• Radiators are a special Recipe : on every iteration, the thermalEnergy they can dissipate is determined by the (iteration-current) loop temperature (black-body equation). The thermalEnergy consumed is clamped to what is necessary to bring back the loop to its targetTemperature.
• This is entirely dependent on thermal-enabled processes having a temperature threshold. How many iterations the resource solver will have to go through depend on how tight that threshold is. Testing is required to see if this is at all viable from a performance POV, and what the minimum threshold should be.

Questions :

• We probably want to allow inter-loop heat exchanges. Not sure how to implement that.
• Some processes generate thermalEnergy regardless of their operating level. Aside from Kerbals, main case would be nuclear reactors :
  • They have a "min operating level", causing them to generate a base amount of thermalEnergy as long as they are enabled
  • They still generate decay heat after being disabled
• How do we handle external conditions ?
  • Should they matter only for radiators ? As proven by previous experiments, accounting for every part thermal exchange with the environment is adding a lot of technical and player-facing complexity, both in vessel design (per-part thermal properties tweaking) and in-flight (attitude management). But totally eliminating that aspect mean that the whole thermal system only really apply to managing large heat-emitting processes, we can't really implement meaningful habitat temperature or fuel boiloff management without that.
  • Aside from radiators, the main "gameplay element" induced by having per part environement thermal exchange is having to manage vessel self-occlusion (ie, sun shields). This is also technically difficult to implement,
  • While we can potentially evaluate external conditions reliably at high timewarp speed, we will always face the issue that large step sizes will use averaged values, ending in huge inconsistencies between high timewarp vs real time behavior. We have 3 main factors : sun irradance, albedo and IR. IR is relatively stable, as it only varies with body distance. Direct irradiance is determined by the sun visibility, and albedo by the sun/body/vessel angle, so their are extremely variable. What about we always use whole orbit averages for those (even in real time) ? From the player POV, this would make thermal design much easier and understandable, and would avoid timewarp inconsistencies. But this basically remove the whole need to handle thermal extremes. This would likely also lead to some weirdness, like thermal conditions changing for the same position depending on the orbit parameters. Technically, this also isn't trivial, as this would require evaluating sunlight and thermal conditions for the whole orbit. This would most likely require a completely separate solver.

What to do ?

• Prototype thermal IO in recipes and integration in the resource solver
• Prototype a "whole orbit average" thermal conditions evaluation system
• Eventually prototype per-part thermal thermal environment interactions (habitat, fuel boiloff...), explore a technical solution for intra-vessel occlusion (custom camera to render texture ?).

[warriorsabe]

It should also make sure that the hull of the vessel still functions to radiate heat too; otherwise anything in space not equipped with radiators would heat up without bound even with only very small heat sources.

Also, convective fluxes through radiators are probably important too - deploying a radiator on Venus would be pretty counterproductive for most things after all. It would be cool to have special encased radiators insulated from convective heating, but that's probably out of scope - though the existence of a convective multiplier would be nice for anyone wanting to make one such radiator.

As for intra-vessel occlusion, is that not already done for solar storm shadow shielding? Could that not be reused here?

[gotmachine]

It should also make sure that the hull of the vessel still functions to radiate heat too; otherwise anything in space not equipped with radiators would heat up without bound even with only very small heat sources.

Well, that's the "should parts exchange heat with the environment ?" question.

A while ago, I did a prototype implementation that was doing it. This introduce a lot of complexity. First on a technical level this mean managing a separate surface temperature, per part thermal capacity and internal stored thermal energy, surface to internal flux ratios, surface emissivity/absorptivity values, etc...

Aside from the coding work needed to make all that work correctly, from the player POV, this mean a lot of tweaking around those values and careful planning for every thermal environment the vessel will have to go through. Achieving "passive equilibrium" is actually quite difficult. My feeling is that this would end up being a very frustrating gameplay element and that it would severely limit achievable mission profiles.

To illustrate the issue, take KSP stock thermal system (which is a rather decent implementation of all that), and think how difficult it would be to tweak each part stock thermal config so crewed parts internal temperature always stay in the 295±25 K survivable temperature range. It's nearly impossible. It's no coincidence that all KSP parts are configured with an absurdly high max internal temperature of 1200K, making the whole stock thermal simulation more or less pointless.

In the end the issue is that a "realistic" thermal simulation isn't something that translate well into a gameplay element. For this Kerbalism subsystem, I'm trying to thing the other way around : what gameplay elements do we want to introduce ? And only then, how to make them vaguely realistic ?

For now, the main thing I want to cover is thermal management for "extreme temperatures" processes : ISRU, drills, nuclear power/propulsion, cryo-cooled electromagnetic radiation shields. This is the main major feature currently missing from Kerbalism. For those gameplay elements, we don't really care about part vs environment thermal interactions, as it's a negligible factor compared to the energy magnitudes involved. It's all about heat production/rejection balance, or said otherwise, about how many radiators you need to slap onto the vessel.

I might look into extending the implementation to cryogenic fuels boiloff management and habitat / life support processes heat management, which will require some form part to environment thermal interaction to be meaningful. But for now, that will likely stay out of scope, and I don't plan to have any form of habitat heat management requirement for now.

Also, convective fluxes through radiators are probably important too

Radiators should definitely take convective fluxes into account, yup.

As for intra-vessel occlusion, is that not already done for solar storm shadow shielding? Could that not be reused here?

Kinda, but not really. First, the radiation raytracing code isn't really checking occlusion, it mainly compute the thickness of every occluder, their density, the secondary radiation emitted, etc. But more importantly, it doesn't actually evaluate the "visual" occlusion, which is what really matters in the thermal case. To do that reliably and efficiently, raytracing is likely not the right tool.