Heat Omnibus

[PB666]

So at present we have several threads going.

1. Heat shield not needed

2. Too much heat and there's a memory leak

I think I solved the first issue

800km alt, 6.5g*M thrust -59' to 7800 m/s and pe 24.4 km - you can survive, but lower pe or higher velocity may not be survivable or in a single aerobraking manuever.

The bugs,

-Heat texture does not disappear as the part cools

-memory leak, not sure what this means but . . . . . .

-over heater parts may not reset I found on revert to launch pad, so something is corrupted

-parts may variably reset the texture on going to space center and reloading craft or exiting and reentering the game.

OK some theory and some solutions.

Here is the conversion of speed into temperature 1/2mv² = 1.5kT (T is in kevins k is Boltzmann's constant). Therefore the faster an object is traveling though a feild of particles, the more heat that will be generated.

The rate of heat addition will depend on the relative speed and the density.

To create a solution first we have to define a problem.

1. Problem. is some parts, certainly not all parts, but the science and electronics are prone to over heating during reentries and during orbital insertion from planets with atmospheres. I have seen problems with solar panels, batteries, and reaction wheels. Mysterious goo and material science are some of the easier parts to overheat; for these the parts may need not survive re-entry

Solutions. These parts can be hidden in a equipment bay, even mat sic can be compressed 3 into one large bay with proper securing. (though there are bugs with doing this. The fairings can also be used. Data can be removed from goo and mat sci. and stored in the pod. In addition the a little bit of retro thrust timed to correspond to the maximum g-forces of re-entry may suffice to prevent destructive over heating.

2. Engine overheating. Problem. Certain engines when operated close to their maximum fuel-flow will overheat and overheat their surrounding parts. This is the most common source of overheating during orbital insertion and during transfers. Specifically engines can dissipate heat more quickly than parts, they get hotter and radiate faster because they can tolerate the heat, the heat-labile parts cannot.

Solutions. Avoid maximum thrust for long periods. Use many stage engines instead of SSTO (stages take the engine heat within when decoupled). Go up to clear draggy atmosphere then turn (begin the gravity turn later).

3. Heat shielding craft parts. Suppose you have a ship designed with separable fuel tanks, or have a nuclear engine. jettisoning the engine can be problematic.

Solution. If the fuel tanks and engines are heat tolerant, put a heat-shield between the tanks and the payload, they will get hotter but the payload will not.

Solution. If the tanks are not heat tolerant put a heat-shield between the engine and the tank connect a surface mounting tank to the tanks and run a fuel line to the engines. Now all the heat will trap on the engine.

Recommendation. Water converts to steam absorbing alot of heat, the thermal energy per gram is higher than just about any other substance between 0'C and 200'C. Therefore resource 'water' can be added to the game. place a disk with 'water' infront of the heatshield but before the engine, as the heat comes off the engine, the water in the disk can be converted to steam and lost, therefore cooling waste heat off the engine.

Recommendation. The same as above but the water circulates to radiative panels and returns providing energy to pump the steam and excess electricity is generated. The panels should retract into the disk when not needed.

Recommendation. By using shielding much of the overheating problem can be avoided, since latent heat will not transfer past the shield, once the engines are killed only their part needs to be resent not 2 dozen electronic parts.

4. Strategic cooling, avoid the bug. Burns are often abbreviated periods with maximum thrust. Specifically the manuever planer gives DV needed.

Solution. The burn time is estimated at maximum thrust and many of this subtract half the burn time from time to manuever to plan the burn. An alternative is to subtract all of the burn time from time to node (IOW when T(node in time) + burn time = 0) apply half thrust.

Solution. The above may still not suffice, or burn windows may be inefficient. For transfers from low orbit to satellites the period of the orbit is small relative to that of the celestial satellite, hence a craft can return to a burn point through several orbits to add velocity and cool.

Problem. Orbital insertion from interplanetary travel. Craft traveling to bodies like Eeloo or Moho may have small burn windows to efficiently gain orbit. I have seen DV for moho at 3000 m/s, multiple passes to gain insertion are not feasible.

Solution. This works for ion drives as well as overheat prone engines. Anticipate the SOI for the planet, there is a several day window that retrograde thrust can be applied with minor adjustments to the radial velocity to slow the craft down in segments.

5. Not enough reality in re-entry.

The problem is that nominal re-entry speeds for Kerbin are 2350 m/s. For earth its more like 7800 m/s. The KE formula above shows that (7800/2350)^2 is going to reflect the actual destructive capacity of the heat.

Solution. Heat shields are valuble for sensitive parts and as above. As mentioned in the other thread 7800 m/s is survivable in KSP, being at the upper limit however of shield-less reentry speeds it is a bumpy ride and the craft almost reaches atmosphere limit before coming down. The re-entry heat probably does need to be increased in the game to make it more realistic.

6. Memory leaks.

Frequents saves. In career mode hard save the game directory with a new name in the Saves folder. After every cycle of overheating allow the overheat bars to disappear then exit the game and reload it.

[Hobbes Novakoff]

BTW, a memory leak is when an application or program stores a value in memory, typically as part of a loop, then does not delete the value from the system memory when it is not needed-say, at the end of said loop. What happens is that your memory fills up with useless values, and you "leak" memory capacity, which can cause a game crash when the system tries to allocate memory that isn't actually there, causing it to freak out and force close the app. This is a pretty big problem in any program, but especially in KSP because since it's a 32 bit application (if you run OSX or Windows), it can only allocate about 3.5 GB of RAM, and because of the rather unique data requirements of a game like KSP (in a nutshell: literally every single asset in the game could be called upon at any moment, so everything needs to be loaded into RAM at startup to prevent the game having to stop for several seconds whenever you get into physics range of another craft or flip a page in the VAB.) 2.2 GB (or so) is used by the stock textures, parts, sounds, and whatnot, which leaves only about 1.5 GB (on Windows) or 1.2 GB (on OSX) for mods and leakage, which is not much, especially on a heavily modded install.

- - - Updated - - -

Also, I am not a programmer, so if someone wants to offer a more in-depth explanation of a memory leak, go ahead.