1.0 heat dissipation?

[NecroBones]

I'm looking to see if anyone knows how the heat values interact in the new 1.0 CFGs. The end-goal I have is to make a heatsink that can be stuck right in between the LV-N engine and the tank above.

I tried playing around with heatConductivity, thermalMassModifier, and emissiveConstant, but couldn't get the behavior I wanted with any sort of obvious combination of values.

* "heatConductivity" seems straightforward. The comments in the part CFGs seem to indicate that the default is around 0.12, so a higher number here should allow it to absorb and transfer heat energy fast.

* "thermalMassModifier" appears to be a multiplier that can be thought of as an analog to "specific heat". Based on what I could see in the debug heat output, it looks like this multiplier allows the part to absorb more or less energy per degree of temperature change.

* "emissiveConstant" is the one I'm not so sure about. Again, I can infer from the configs that the default is probably 1.0, and lower numbers make it a better radiator.

But here's where I can't get things to work. I've tried emissiveConstant's as low as 0.01, and it doesn't really seem to dissipate any appreciable amount of energy in space, even with increased "heatConductivity" and "thermalMassModifier" values. High values for "thermalMassModifier" work great to make a sort of "heat battery" that isolates the heat energy from propagating quickly to the rest of the ship, but then it takes forever to cool off.

The opposite goal, of making an insulator, looks like it would be easy. Just make something with really poor heat conductivity.

I'm just wondering if anyone else is thinking along these lines and might have made more progress than I have?

[Randazzo]

I'm looking to see if anyone knows how the heat values interact in the new 1.0 CFGs. The end-goal I have is to make a heatsink that can be stuck right in between the LV-N engine and the tank above.

I tried playing around with heatConductivity, thermalMassModifier, and emissiveConstant, but couldn't get the behavior I wanted with any sort of obvious combination of values.

* "heatConductivity" seems straightforward. The comments in the part CFGs seem to indicate that the default is around 0.12, so a higher number here should allow it to absorb and transfer heat energy fast.

* "thermalMassModifier" appears to be a multiplier that can be thought of as an analog to "specific heat". Based on what I could see in the debug heat output, it looks like this multiplier allows the part to absorb more or less energy per degree of temperature change.

* "emissiveConstant" is the one I'm not so sure about. Again, I can infer from the configs that the default is probably 1.0, and lower numbers make it a better radiator.

But here's where I can't get things to work. I've tried emissiveConstant's as low as 0.01, and it doesn't really seem to dissipate any appreciable amount of energy in space, even with increased "heatConductivity" and "thermalMassModifier" values. High values for "thermalMassModifier" work great to make a sort of "heat battery" that isolates the heat energy from propagating quickly to the rest of the ship, but then it takes forever to cool off.

The opposite goal, of making an insulator, looks like it would be easy. Just make something with really poor heat conductivity.

I'm just wondering if anyone else is thinking along these lines and might have made more progress than I have?

The emissive constant is not capped at 1, and higher numbers produce larger amounts of radiation flux. The largest number I've used so far is 1.6. I tested this versus a value of 1 and 1.6 shows an improved effect, so it does work.

By lowering the number, less heat is lost due to radiation (might be putting that incorrectly) which is why your ships are retaining heat.

-I <3 MRS

Edited April 30, 2015 by Randazzo

[NecroBones]

The emissive constant is not capped at 1, and higher numbers produce larger amounts of radiation flux. The largest number I've used so far is 1.6. I tested this versus a value of 1 and 1.6 shows an improved effect, so it does work.

By lowering the number, less heat is lost due to radiation (might be putting that incorrectly) which is why your ships are retaining heat.

-I <3 MRS

Ah, so higher values are improved dissipation? OK that's good to know. When the stock configs showed a 0.8 as being "good" emitters for engines, I was interpreting that as a drop from 1.0, but it sounds like that's quite wrong. I'll play with numbers in the other direction and see what I get.

Thanks!

[NathanKell]

emissiveConstant is the emissivity factor in the black-body radiation equation (flux in W = Stefan-Boltzmann constant * emissivity * area * temperatureK^4). It most certainly cannot be >1 (1 is a perfect black body).

thermalMassModifier is a modifier applied to the standard specific heat capacity (as defined in Physics.cfg, default = 800kJ/tonne-K). Part thermal mass = part.mass * standardSpecHeat * thermalMassModifier * sum[for each resource](resource amount * resource density * resource hsp).

heatConductivity is per unit area of connection, and does indeed default to 0.12.

If you want to make a radiatior, you want high emissivity (although be warned, absorption = emissivity, so it will also be very good at absorbing solar radiation etc), high(ish) conductivity, probably higher than normal, and perhaps a higher than normal thermal mass (or perhaps not, because as you can see by the T^4 above, it's good to keep your radiator at high temperature to maximize outflux).

[NecroBones]

Awesome, thanks!

[Randazzo]

emissiveConstant is the emissivity factor in the black-body radiation equation (flux in W = Stefan-Boltzmann constant * emissivity * area * temperatureK^4). It most certainly cannot be >1 (1 is a perfect black body).

thermalMassModifier is a modifier applied to the standard specific heat capacity (as defined in Physics.cfg, default = 800kJ/tonne-K). Part thermal mass = part.mass * standardSpecHeat * thermalMassModifier * sum[for each resource](resource amount * resource density * resource hsp).

heatConductivity is per unit area of connection, and does indeed default to 0.12.

If you want to make a radiatior, you want high emissivity (although be warned, absorption = emissivity, so it will also be very good at absorbing solar radiation etc), high(ish) conductivity, probably higher than normal, and perhaps a higher than normal thermal mass (or perhaps not, because as you can see by the T^4 above, it's good to keep your radiator at high temperature to maximize outflux).

If it cannot be greater than 1, what accounts for the difference I see in higher numbers? Naturally I'm at work and can't go pull them.

[NecroBones]

If it cannot be greater than 1, what accounts for the difference I see in higher numbers? Naturally I'm at work and can't go pull them.

I'm only guessing here, but my suspicion is that the math works to make it an even better emitter, but it goes beyond what could realistically happen with an actual black-body, or any sort of passive radiator. So you're creating an impossibly-good radiator.

[Randazzo]

I'm only guessing here, but my suspicion is that the math works to make it an even better emitter, but it goes beyond what could realistically happen with an actual black-body, or any sort of passive radiator. So you're creating an impossibly-good radiator.

I can live with that, I'm an "the ends justifiy the means" sorta guy anyway

I'm still going to make some comparisons again when I get home to ensure I'm not delusional.

[Angelo Kerman]

emissiveConstant is the emissivity factor in the black-body radiation equation (flux in W = Stefan-Boltzmann constant * emissivity * area * temperatureK^4). It most certainly cannot be >1 (1 is a perfect black body).

thermalMassModifier is a modifier applied to the standard specific heat capacity (as defined in Physics.cfg, default = 800kJ/tonne-K). Part thermal mass = part.mass * standardSpecHeat * thermalMassModifier * sum[for each resource](resource amount * resource density * resource hsp).

heatConductivity is per unit area of connection, and does indeed default to 0.12.

If you want to make a radiatior, you want high emissivity (although be warned, absorption = emissivity, so it will also be very good at absorbing solar radiation etc), high(ish) conductivity, probably higher than normal, and perhaps a higher than normal thermal mass (or perhaps not, because as you can see by the T^4 above, it's good to keep your radiator at high temperature to maximize outflux).

If I have a high heat conductivity of > 1, will the radiator transfer heat to parts that it is attached to?

[NathanKell]

Uh, all parts transfer heat with what they're connected to / are connected to them. Conductivity just changes the rate.

And, btw, Randazo, it's a really, really bad idea to go breaking the laws of physics. All sorts of bad things happen.

[Randazzo]

Uh, all parts transfer heat with what they're connected to / are connected to them. Conductivity just changes the rate.

And, btw, Randazo, it's a really, really bad idea to go breaking the laws of physics. All sorts of bad things happen.

It's worked so far

There may be unintended consquences when the universe explodes later on.

In all seriousness I intend to have another look as soon as I'm able to get to. I was under the impression the emissiveconstant was a just a number dictating how much heat an object could lose, I didn't know it was tied to any laws (until Regex pointed it out a couple of days ago). With the corrected LV-N heat output I can probably stay within reality or at least close to it.

[rkman]

Which parameter affects convection (conduction to atmosphere)?

It seems there is to little of it, seeing how parts that got hot take forever to cool down while in the atmosphere (standing still, no heat producing parts active).

Edited May 7, 2015 by rkman

[NecroBones]

Which parameter affects convection (conduction to atmosphere)?

It seems there is to little of it, seeing how parts that got hot take forever to cool down while in the atmosphere (standing still, no heat producing parts active).

I think that's going to be "heatConductivity". The emissive value is for "black body radiation" (that is, heat dissipation through radiation, such as infrared). Heat conducts to the air right at the surface of an object, and than a convection effect can keep a flow of fresh air that continues to aid in cooling. At least in the real world, anyway. I don't know to what level of detail they simulated that here. But of course we're used to things happening on a compressed time scale in games, and in reality an object can retain a lot of heat for a long time, for several reasons. One can be a large volume to surface area ratio, and another is that the surface can cool down a lot faster than the interior, which will impede further cooling. Plus, a certain amount of air "sticks" to the surface region and further insulates it.

So I think even if they simulate a lot of these factors, things won't cool off as quickly as we might like from a gameplay perspective.

[NathanKell]

nope, conduction is for part-part conduction. The part's convectivity constant (see the shock cone intake's part cfg for an example) is a multiplier to convective flux.

[rhoark]

Speaking of which, does anyone know if heatshields properly reduce convective flux, or do they just subtract heat while ablative material lasts?

[NathanKell]

I wasn't aware that heatshields actually reduced the density or velocity of air hitting them...I thought they just radiated heat well, and further cooled from ablation.

[Randazzo]

I haven't fiddled with the heatshields in an atmosphere, but in my reality-butchering mod (check out the AHMS units from the link in my sig if you want to see this in action), while the ablator resource is active, it creates a negative internal flux which seems to suck the heat away into nowhere. It appears to be dictated by (or at the very least significantly affected by) pyrolysisLossFactor in combination with the resource hsp, and it appears to function like an inverse heatProduction.

Like all heat loss variables, it gets more effective the more heat you dump on it, and the heatshields don't get anywhere close to the levels of heat I've subjected these things to.

I had assumed the reentryConductivity variable affected how much heat the shield would pick up from re-entry effects, but I removed that line from the AHMS units since they aren't intended for that. If it actually reduces part-to-part heat transfer, that would be counter productive to my purposes anyway.

Edited May 8, 2015 by Randazzo

[NecroBones]

nope, conduction is for part-part conduction. The part's convectivity constant (see the shock cone intake's part cfg for an example) is a multiplier to convective flux.

Good to know, thanks.

At first I didn't see the "heatConvectiveConstant" in the shock cone's cfg, though now I see it was added after 1.0 in one of the patches. (one of my dev copies is still sitting at 1.0).

[rhoark]

I wasn't aware that heatshields actually reduced the density or velocity of air hitting them...I thought they just radiated heat well, and further cooled from ablation.

Pyrolysis gases carry some heat with them as they go, but the pressure they generate also increases the shock standoff distance.

Edit: according to this paper the standoff is less important than how the ejected gas chemically reacts with the dissociated gas in the shock. If I'm understanding correctly, nitrogen and oxygen radicals would otherwise react exothermically with the heat shield.

Edited May 8, 2015 by rhoark

[NathanKell]

Thanks, rhoark!

[kerbinspacecommand]

Hey folks, I could use some help here. I'm trying to develop a massive "Sunshield" for low-Kerbol orbit space stations and spacecraft (exactly like in the movie Sunshine). Due to the inherent issues of keeping said craft pointed at the sun at all times to protect the pieces behind it, I was thinking I could work around the issue by instead having the sunshield act as a massive hyper efficient radiator. I've fiddled around with some values and read through this thread but am still having issues getting the piece to work. Could anyone please provide some direction on this issue? It would be very much appreciated.

Edit: To be as specific as possible, I'm looking for the ability to have a station operate at around roughly 25,000 km above the surface of the sun.

Edited September 18, 2015 by kerbinspacecommand

[NathanKell]

KSP models emissivity as the same as absorption. So your massive radiator will also suck in solar flux like nobody's business.

[kerbinspacecommand]

KSP models emissivity as the same as absorption. So your massive radiator will also suck in solar flux like nobody's business.

Yeah, that's been my experience so far. Any insight as to how such a feat might be accomplished? Or is it generally impossible to operate that close to the sun indefinitely.

[rhoark]

You'd want a low absorption shield connected to a radiator in its shadow.

[Cunjo Carl]

On 9/18/2015 at 8:21 AM, kerbinspacecommand said:

Hey folks, I could use some help here. I'm trying to develop a massive "Sunshield" for low-Kerbol orbit space stations and spacecraft (exactly like in the movie Sunshine). Due to the inherent issues of keeping said craft pointed at the sun at all times to protect the pieces behind it, I was thinking I could work around the issue by instead having the sunshield act as a massive hyper efficient radiator. I've fiddled around with some values and read through this thread but am still having issues getting the piece to work. Could anyone please provide some direction on this issue? It would be very much appreciated.

Edit: To be as specific as possible, I'm looking for the ability to have a station operate at around roughly 25,000 km above the surface of the sun.

I'm sorry to bring back such an old post, but I hate to see a question left dangling when there's useful info to give! Folk come back and look at these well after the fact, so even if @kerbinspacecommand isn't working on their solar baking box anymore, perhaps someone else will find this helpful. I also recognize it's not really in the appropriate forum, but still, question!

There's an interesting interaction caused by the boundsmultiplier field on the inflatable heat shield, which allows for sun stations to not absorb thermal radiation. Given this immunity, they can orbit the sun as close as you please and can even slightly enter the chromosphere so you can pick up an EVA from 'flying high at the sun'. Anything put within ~7 meters of cage end (for preference) of the shield will not absorb thermal radiation, but the object will still block thermal radiation from passing through, so it protects the heatshield and whatever's behind it. As long as you're willing to keep the setup pointed at the sun within about 5-10 degrees, it'll protect you indefinitely. In any case, there's plenty of room to put in a little sun station, complete with a Cupola and command chairs from which you can view the beautifully hilled and valleyed surface of the sun, or the nostalgic v.1 sun within the sun in map mode. Solar panels have the solid angle of continents, and the Oberth effect is at its boggling extreme. It's great fun! A highly recommended trip.

As I understand it, this is actually an unintended effect of the boundsmultiplier field. The inflatable heat shield apparently made mischief when trying to calculate its bounds through the renderer, so the boundsmultiplier field was introduced to provide a fudge factor. As NathanKell explained in an earlier post that I had a hard time quoting properly: " The bounds reported by the bounding method, prior to PartSizeModifier, are based on the renderer bounds of the given renderer. There used to be multiple calls because there are multiple renderers for some parts. I'd like to say the renderer bounds are correct, but the inflatable heat shield has proved that that is not always the case with skinned meshrenderers. For this reason we support the new field Part.boundsMultiplier to correct for such problems. "

I understand this use of the boundsmultiplier is a glitch, but it's a very charming one which lends itself well to our ambitions. I hope it serves others well in the future.

Edited June 17, 2016 by Cunjo Carl