[1.0] Cooldown: A Community Discussion of Heat Management

[Angelo Kerman]

Hi folks,

I just released DSEV 0.3.17, and I've been getting some inquiries about how I did the heat radiators. Since radiators are a hot topic, I thought I'd start a thread where we can share what we've learned about heat management. At the very least, this information exchange will help people create their own heat management system. Ideally though, we'd create a community-driven heat management mod.

To start off, I'll share all the notes I took over the past week. Many many thanks to Red Iron Crown and NathanKell for their insights!

From KSP 1.0 Readme:

Heat Simulation:

- Completely revised part heating model, energy flux is considered, not merely temperature.

- All game temperatures changed from ‘Kervin’ to proper Kelvin.

- Radiative, conductive, and convective heating and cooling are simulated.

- Parts can have individual radiative, conductive, and convective properties.

- All parts now emit a blackbody radiation glow if they get hot enough.

- Conduction between attached parts is more accurately modelled.

- Parts can occlude other parts from being exposed to sunlight, celestial body albedo/radiation and supersonic flow.

- Reentry/hypersonic flight heating is now simulated.

- Added difficulty Setting to scale aerodynamic heating.

- Atmospheric temperature, and thus density, takes latitude and sun position into account.

- Celestial bodies accurately emit thermal radiation making nearby craft warmer.

- Service modules, fairings and cargo bays can be used to protect parts inside from heat.

- Heat shields provide (finite) ablation-based protection for parts behind them.

From Part object:

//This is how you add or remove heat from the part. + value adds heat, - value removes heat.

public void AddThermalFlux(double kilowatts);

These are in kJ/sec

//negative values indicate heat is going out of the part and into the environment. Positive values mean heat is coming into the part.

public double thermalConductionFlux;

public double thermalConvectionFlux;

public double thermalRadiationFlux;

public double thermalInternalFlux;

public double thermalInternalFluxPrevious;

public double thermalMass; //Kj/K

public double thermalMassModifier;

public double thermalMassReciprocal;

From Red Iron Crown:

Red Iron Crown

Thermal mass is the capacity of the part to absorb heat, i.e. the specific heat of the material times the mass of the part. It takes more heat to raise the temperature of a part by a given amount if it has a higher thermal mass. So parts with higher thermal mass change temperature more slowly than those with a lower thermal mass, both upwards and downwards.

Radiative area is the theoretical area that emits or absorbs radiated heat. Parts emit heat when in shadow and absorb it when in sunlight (at least I think this is modelled). Parts with a larger radiative area gain or lose heat faster than those with smaller radiative areas.

As I understand it:

- All parts has a default specific heat of 800 kJ/tonne-Kelvin defined in Physics.cfg in the root folder (standardSpecificHeatCapacity)

- Parts can have that modified in their cfgs by a multiplier (thermalMassModifier, setting this to 2 would double specific heat)

- Resources also have their own specific heats defined in ResourcesGeneric.cfg in Gamedata/Squad/Resources (hsp)

- Part thermal mass thus should be (dryMass * standardSpecificHeatCapacity *thermalMassModifier) + (resourceMass * hsp) <- Repeat last section for each resource within the part. Units are kJ/K.

****

Some math I did:

thermal energy = thermalMass (KJ/K) * temperature (K)

If my radiator is at 1000 K, then my thermal energy = 1790 * 1000 = 1,790,000 KJ

If my radiator's maximum temperature is 2400K, and we have a "working temperature" of 0.85 of that, then the maximum thermal energy that the radiator can take on is:

2400 * 0.85 * 1790 = 3,651,600 KJ

Remember that you need to conserve heat. If you add it from one part, remove it from another.

Transferring heat: Heat goes from hot part to cool part until equilibrium is reached.

KSP game itself handles heat radiation and will calculate its radiative area automatically.

I'll break the heat management out of DSEV later this evening to serve as a reference.

Edited May 1, 2015 by Angel-125

[Nansuchao]

One thing that's completely wrong with KSP 1.0 is the atmosferic drag during re entry. The atmosfere doesn't slot you down as it should and that's will add a great difficulty in heat management, cause actually is totally unrealistic. Now can you simulate a real heat effect while you accellerate falling from 15 km to a speed of more than 500 m/s?

Also parachutes are unrealistic, but that's the only way to make it work, unless you can just make rocket powered re entry.

Is it possible to change this situation?

[Errol]

So something I've been wondering (haven't really bothered getting into space much yet, still waiting for all my mods before starting a career, so I've been having fun in atmospheric flight) will there be heating from being inside the atmosphere of another planetary body? Like if I drop a probe on the surface of eve with no radiators or anything, will it get cooked and start exploding?

[Angelo Kerman]

One thing that's completely wrong with KSP 1.0 is the atmosferic drag during re entry. The atmosfere doesn't slot you down as it should and that's will add a great difficulty in heat management, cause actually is totally unrealistic. Now can you simulate a real heat effect while you accellerate falling from 15 km to a speed of more than 500 m/s?

Also parachutes are unrealistic, but that's the only way to make it work, unless you can just make rocket powered re entry.

Is it possible to change this situation?

Not sure, but one solution is open-cycle cooling. With radiators you have closed-cycle and open-cycle cooling. closed-cycle keeps the coolant within the craft and it takes awhile to cool off. Open-cycle dumps coolant overboard, and in return you get rapid cooling. The radiator code is designed to support both types and it's been proven to work nicely. Here is a sample config file. It's a WIP but it gives you an idea where I'm going with the radiator code in DSEV/Cooldown heat reference mod. I'm using this in 0.3.17

MODULE

{

name = ModuleRadiator

animationName = Deploy

pivotName = sunPivot

IsBreakable = true

raycastTransformName = suncatcher

chargeRate = 0

//A value between 0 and 1, specifies how much of the part's

//maximum temperature may be used by the radiator.

//Radiator max temp should be below the resource's critical point.

//Assuming the radiator itself is pretty sturdy and won't melt.

workingTempFactor = 0.85

//INPUT_RESOURCE specifies the coolant needed for heat transfer. It is required for active cooling.

//Active cooling circulates coolant to other parts in the vessel to cool them down.

//Without active cooling, parts must rely on the parts they're attached to,

//their own mass, and the environment to cool down.

//You can use whatever resource you want for coolant. Some resources are better than others.

//If you specify multipult INPUT_RESOURCE nodes, be sure that their combined ratios add up to 1.

INPUT_RESOURCE

{

name = Coolant

flowMode = FLOW_NONE

ratio = 1.0

}

//TODO: Get rid of this and use INPUT_RESOURCE nodes instead.

coolantResource = Coolant

//Radiators support two types of cooling: closed-cycle, and open-cycle.

//Closed-cycle keeps circulating coolant within the vessel, and it may take awhile

//for the vessel to cool down. Open-cycle cooling sheds heat more quickly,

//but at the expense of coolant (the resources specified by INPUT_RESOURCE).

//This value specifies the number of units per second to dump overboard.

//Each INPUT_RESOURCE above will be dumped according to their ratio.

//If you don't want open-cycle cooling, then don't include this field or set it to 0.

coolantDumpRate = 66.67

//Specifies the coolant loss rate.

//The first number represents the number of units per second that is lost

//in general. The second number is the number of units lost per g of acceleration.

//That second number is particularly useful for liquid droplet radiators.

//Uncomment this line if you want coolant loss.

//coolantLossRate = 0,1.0

}

[Nertea]

I am very much in favor of a kind of heat management mod. I think the primary challenge is data driven - how, as a player, do you know whether you have enough cooling capacity to cool your heat generating parts, given a variety of cooling parts available and a variety of cooling parameters in various situations.

[sharpspoonful]

I would be in favor of two types of cooling, based on atmospheric and non atmospheric conditions. Things like heats sinks and open/closed cycle radiators. Smaller parts sinks for drills and large heat output type parts and larger panel style radiators for converters, habitations, and powerplants. I'm also curious how the game handles heat transfer to the radiator. Is there an internal piping system to draw heatfrom a further away part? Or will the sinks and radiators have to be placed in the immediate vicinity of the heat products in part?

[Angelo Kerman]

I would be in favor of two types of cooling, based on atmospheric and non atmospheric conditions. Things like heats sinks and open/closed cycle radiators. Smaller parts sinks for drills and large heat output type parts and larger panel style radiators for converters, habitations, and powerplants. I'm also curious how the game handles heat transfer to the radiator. Is there an internal piping system to draw heatfrom a further away part? Or will the sinks and radiators have to be placed in the immediate vicinity of the heat products in part?

Currently from what I've seen, KSP uses thermodynamics to transfer heat around a vessel: a hotter part transfers heat to the cooler part until the two reach thermal equilibrium. For DSEV, I actively pull heat out of a part and put it into the radiator. I made the assumption that a vessel has a circulatory system built-in, and the radiator circulates coolant through the vessel. That way you don't need dedicated heat pipes and you keep your part count low.

Some of the feedback I got tonight was that radiators might benefit from a heat transfer rate. Right now I assume that the coolant heats up quickly, gets circulated to the radiator where it "drops off" the heat, cools down, and is ready for the next part. I could account for heat difference between a part and the coolant but I decided that would take a lot of calculations and slow the game down. So that's something to think about too: reality vs gameplay.

[sharpspoonful]

I'm on my phone, so sorry for the poor grammar. Does KSP's code have an integrated pipe system, like crossfeeding for heat? This is something the Star Citizen has, where all resources have paths in the shop to their respective targets. For example, heat from weapons engines and shields all get dumped into a cooling system. If the heat output is higher than the cooling system can handle, the parts start failing or being destroyed. Now as system like that maybe out of the scope of complexity for a mod, bit I'd rather see something similar to it than spamming radiators everywhere.

[basic.syntax]

You may already be aware, or if not... perhaps wish to follow - these other threads I've seen about heat management:

[Guide] New temperature rules for parts in 1.0

1.0 heat dissipation?

PSA: Nuclear engine overheating

[1.0] HeatWarning - technicalfool mod work-in-progress to give audio & visual warning of overheat condition

Edited May 1, 2015 by basic.syntax

[lajoswinkler]

I'm all in favor of closed cycle radiator heat management. Especially with the LV-N engine. If you can make a decent nice radiator that would allow nuclear thermal propulsion, that would be great.

Open cycle is great for rapid heating, but it's kind of an overkill in complexity, IMHO.

[Angelo Kerman]

You may already be aware, or if not... perhaps wish to follow - these other threads I've seen about heat management:

[Guide] New temperature rules for parts in 1.0

1.0 heat dissipation?

PSA: Nuclear engine overheating

[1.0] HeatWarning - technicalfool mod work-in-progress to give audio & visual warning of overheat condition

Ah, didn't see those. Looks like several people are talking about it, heh.

[Nertea]

Indeed, but I think this thread serves more of a different purpose: the development of a unified framework.

[Angelo Kerman]

Well, I am continuing regardless. I just uploaded the latest WildBlueTools, where ModuleRadiator and HeatManager currently reside. When I get home I'll break them out and put them into Cooldown.

Changes from last night:

- INPUT_RESOURCE is now supported. You can specify multiple coolants.

- coolantResource removed

- radiator manager will not cool a part below room temperature (293K). It was cooling to ambient, which in space is 4K.

- performance enhancements

- radiator parts are excluded from the HeatManager's parts list that it cycles through

- if a radiator isn't extended then it only accepts 1/100th the requested input heat. This is an initial pass at tuning radiators that are stowed.

Todo:

- find ways to improve the heat management code- do I have to re-calculate a radiator 's current thermal energy for each part, or can I do it once per time-tick, and all parts work against that once per tick calculation?

- fix a bug where if a radiator explodes it causes nullRefs. Just need to tell the HeatManager that the radiator is about to explode.

- find out if physics-less parts take on heat. If not then exclude them from the parts list.

- account for radiators that don't extend in the heat transfer calculations.

- implement optional coolant loss over time, probably per INPUT_RESOURCE

- implement optional ElectricCharge requirement.

- implement optional module to specify the lowest temperature that the part may be cooled to. Without the module, default is 293K, settable in a config file for the mod.

Other:

What benefits, if any, do Engineers give?

How can I use the built-in shader that makes parts glow as they get hot? When I increase the part temperature, I don't see any texture changes unless I do the change myself.

Edited May 1, 2015 by Angel-125

[Nertea]

Sounds great! I might suggest that there be a way to configure the target temperature on a per-part basis (maybe an optional module you could tuck in), so that it could be customized to allow certain parts to "run hot"

Not sure about the shader - I might just suggest doing it via animation, not too hard.

[Angelo Kerman]

Sounds great! I might suggest that there be a way to configure the target temperature on a per-part basis (maybe an optional module you could tuck in), so that it could be customized to allow certain parts to "run hot"

Not sure about the shader - I might just suggest doing it via animation, not too hard.

Great idea Nert, I've updated my Todo list.

[Nertea]

Re: Engineers - I suppose IRL their related abilities would be to optimize the transfer systems (clean the pumps etc) and potentially to plan radiator orientations. Here's some possibilities, with justifications:

- Slightly increase radiative capacities of radiators (optimization of radiator orientation and stuff)

- Improve the ability of radiators to accept heat (optimization of coolant transfer systems)

- Reduce losses in open cycle cooling (optimization and maintenance of dump valves and systems)

[lajoswinkler]

Be sure to make your radiators behave the opposite of solar panels, i.e. to avoid exposing their flat side to Kerbol.

[Angelo Kerman]

Be sure to make your radiators behave the opposite of solar panels, i.e. to avoid exposing their flat side to Kerbol.

Yup, the ones in DSEV already do that. I will include them in the Cooldown reference mod.

[NathanKell]

A few corrections to the info in the OP.

Radiative area is used for three things:

1. black body radiative emission and reception

2. solar flux

3. body flux (if your current SoI is not the sun, you get reflected solar flux based on body albedo, and emissive flux based on body temperature).

All three occur all the time. 1 is proportional to part temperature^4 - background temp^4. 2 is proportional to distance to the sun and to unoccluded part area facing the sun. 3 is proportional to distance to the body and to unoccluded part area facing the body. The density of the atmosphere (if you're in an atmosphere) will also lower the solar and body flux incoming, but raise the background radiation temperature above 4 K. Background temperature is interpolated by density, though not at all linearly, between 4 K and the current external temperature, i.e. shockwave heating is included.

[johnsonwax]

I just did a little experiment with ModuleAblator for sumghai.

lossConst seems to dictate the temperature at which the ablator begins to boil off. Increasing the value lowers the temperature (stock 20 boils around 850, 50 boils closer to 770). That has the effect of removing heat faster from the part, keeping the parts max temperature lower, but slightly increasing the amount of ablator consumed.

pyrolysisLossFactor seems to dictate the amount of heat energy that a given amount of ablator uses. It boils off at the same temperature, but higher values remove heat more efficiently. Doubling the value from stock 10000 to 20000 cut the ablator consumption nearly in half and lowered the max heat value the part was exposed to. Cutting the value in half to 5000 increased consumption by 80% and increased the max heat value the part was exposed to.

[NathanKell]

Uh, not really, no. Works like this:

if part.temperature >= ablationTempThresh then

loss = lossConst * e^(lossExp / part.temperature)

the calculated loss is then multiplied by the remaining units of Ablator to find out how much to remove. Then, the dissipation energy = units_lost * resource.density * resource.hsp * pyrolysisLossFactor

[Enceos]

Uh, not really, no. Works like this:

if part.temperature >= ablationTempThresh then

loss = lossConst * e^(lossExp / part.temperature)

the calculated loss is then multiplied by the remaining units of Ablator to find out how much to remove. Then, the dissipation energy = units_lost * resource.density * resource.hsp * pyrolysisLossFactor

@NathanKell, I've got some questions bugging my mind. What is the boiling point and the critical temperature of Ablator in KSP? Why heating of the shield never stops at a certain temperature until Ablator runs out?

Also I don't understand why Squad gave to heatshields 3400 maxTemp. I've not been able to burn them off under any dire circumstances (like 10km/s Jool reentry). And even if we don't burn them off, the ModuleAblator gotta increase conductivity of heat shields when they run out of the resource. There's currently no punishment for having a shield with zero Ablator.

Edited May 5, 2015 by Enceos

[Angelo Kerman]

I updated WildBlueTools this morning in preparation to my next release of DSEV, and made some changes to the heat management. You can find the GitHub repro here.

- Radiators can now use multiple coolants, specified by INPUT_RESOURCE nodes.

- Radiators can now suffer coolant loss over time if desired.

- Radiators can now suffer coolant loss while the vessel is under acceleration if desired.

- Radiators can consume ElectricCharge if desired.

- Physics-less parts are now ignored.

- Parts with crew capacity have a target temperature of 293K (room temperature).

- Default target temperature is 49% of the part's maximum temperature (configurable through the config file), which is just under the stock heat warning indicator's threshold.

- Radiators now correctly cap their heat transfer once they reach their maximum working temperature.

- Game performance improvements and bug fixes.

TODO:

- Add ModuleTargetTemp to specify a part's target temperature. This will override the default target of 49% of the part's max temp.

Once I get the next updates done I'll break out the code into a separate dll.