[1.12.x] SystemHeat - a replacement for the CoreHeat system (November 20)

[Nertea]

19 hours ago, WarriorSabe said:

I was looking into it some more, and it looks like you probably don't have to worry about Kerbalism 4.0; it adds its own replacement to the core heat system, so it'd be redundant to use both.

Though, I guess users might want to disable Kerbalism's heat system in favor of SystemHeat, in which case it'll need to be able to run stably at high timewarps and in the background for Kerbalism to work with it (though that's not exactly the same as a compatibility patch since you probably don't need to interface with Kerbalism for that).

Yes, I typically operate independent of Kerbalism. 

[ShakeNBake]

Finally able to game again, had a look at your modules and tried to patch them into some new parts. Since these are their own Systemheat converters/generators, it doesn't seem likely that this will be able to mesh with USI or other mods, unless I'm wrong?

It does look really nice in the VAB, though it can get a bit crowded.

Spoiler

I would guess most of my problems are related to all the other mods. I'll have to make a vanilla copy and see if they're reproducible.

[Nertea]

1 hour ago, ShakeNBake said:

Finally able to game again, had a look at your modules and tried to patch them into some new parts. Since these are their own Systemheat converters/generators, it doesn't seem likely that this will be able to mesh with USI or other mods, unless I'm wrong?

It does look really nice in the VAB, though it can get a bit crowded.

  Reveal hidden contents

I would guess most of my problems are related to all the other mods. I'll have to make a vanilla copy and see if they're reproducible.

That looks really cool and makes me more excited to work on this! There's a fairly big update coming soon (tomorrow?) with a ton of fixes and improvements. Unfortunately other people's custom modules are probably not going to work. My mods will be fine, I'll work with anyone who want to in order to help them, but I really doubt USI or Kerbalism will be part of that bin. 

Edited August 4, 2020 by Nertea

[Nertea]

New update is available:

•  General
  •   Restructured patches into Extras and not-extras for better modularity
•  Parts/Patches
  •   Added a dummy coolant tank part
  •   Added a dummy Heat Sink part
  •   Added a dummy Compressor part
  •   Added patches for all NFE reactors
  •   Added patches for all Kerbal Atomics engines
  •   Tuned balance for some parts
•  Simulation
  •   Fixed a number of bugs surrounding simulations
  •   Various upgrades to the simulation system to handle new modules
  •   Added ModuleSystemHeatFissionEngine: replacement for NFE fission engine module
  •   Added ModuleSystemHeatFissionReactor: replacement for NFE fission reactor module
  •   Added ModuleSystemHeatSink: heat sink module that allows for storing and slow release of heat
  •   Added ModuleSystemHeatTemperatureAdjuster: module that allows the adjustment of a loop's nominal temperature for a power/heat cost
•  UI
  •   Added Volume information to loop overlay panels
  •   Bugfixes for overlay panels and overlay loops
  •   ModuleSystemHeat provides Volume information in the part info box plus a little display
  •   Additional localization additions

Note a few things...

• The NFE reactors and thermal engines work a bit differently than they used to, namely they auto-adjust their output and are overall less complex to use
• NFE reactor panel doesn't exist at the moment
• Nothing plugs into the NF system manager yet (power not tracked for reactors, for example)

[theonegalen]

It's fantastic to see this taking shape. I remember you talking idly about overhauling the heating system years ago.

[danfarnsy]

On 8/4/2020 at 11:15 PM, Nertea said:

Note a few things...

• The NFE reactors and thermal engines work a bit differently than they used to, namely they auto-adjust their output and are overall less complex to use
• NFE reactor panel doesn't exist at the moment
• Nothing plugs into the NF system manager yet (power not tracked for reactors, for example)

Will the auto-adjust look at other power sources like solar, and then adjust to make up the difference? If you have multiple reactors on a ship, can you prioritize using one before the others are throttled up? I'd like to set priority if one is more efficient or if they're using different fuels like fusion or fission.

[Nertea]

6 hours ago, danfarnsy said:

Will the auto-adjust look at other power sources like solar, and then adjust to make up the difference? If you have multiple reactors on a ship, can you prioritize using one before the others are throttled up? I'd like to set priority if one is more efficient or if they're using different fuels like fusion or fission.

Ooof no, that's too involved for me to want to deal with. Simplified yes, completely user-less, no!

[Shoujo Q]

This is a much needed overhaul of how KSP handles heat. Looking forward to how it progresses!

[Danielle]

Is the Extra folder just something for the Repo or they're add-ons?

[Nertea]

12 hours ago, Danielle said:

Is the Extra folder just something for the Repo or they're add-ons?

Last update I moved all the 'gameplay-changing' patches to the Extras folders. That way the mod can be installed to run things that require it (e.g., Far Future Tech) without affecting the base game. The only things that are patched by default are radiators, and this change is backwards compatible. 

• SystemHeatConverters: Changes resource converters to SystemHeat converters
• SystemHeatHarvesters: Changes resource harvesters to SystemHeat harvesters
• SystemHeatFissionReactors: Changes NFE reactors to SystemHeat reactors
• SystemHeatFissionEngines: Changes KA fission engines to SystemHeat nuclear engines. 

 

[toric5]

ufda, looking at your patches, making a univerasal MM patch is not going to be straightforward like it was for kerbal atomics, but it should be possible to make a somewhat crude patch so that a module integrates into the new system, even if not all the stats are perfectly balanced. (for 3rd party mods using the stock modules)

 

If the names of the config nodes and what they do are stable, though, Id be happy to take a stab at it.

[Not a Spy]

On 8/10/2020 at 12:20 PM, Nertea said:

Last update I moved all the 'gameplay-changing' patches to the Extras folders. That way the mod can be installed to run things that require it (e.g., Far Future Tech) without affecting the base game. The only things that are patched by default are radiators, and this change is backwards compatible. 

• SystemHeatConverters: Changes resource converters to SystemHeat converters
• SystemHeatHarvesters: Changes resource harvesters to SystemHeat harvesters
• SystemHeatFissionReactors: Changes NFE reactors to SystemHeat reactors
• SystemHeatFissionEngines: Changes KA fission engines to SystemHeat nuclear engines. 

 

i like that idea

now watch me get to work on a in game explanation

[Nertea]

4 hours ago, toric5 said:

ufda, looking at your patches, making a univerasal MM patch is not going to be straightforward like it was for kerbal atomics, but it should be possible to make a somewhat crude patch so that a module integrates into the new system, even if not all the stats are perfectly balanced. (for 3rd party mods using the stock modules)

 

If the names of the config nodes and what they do are stable, though, Id be happy to take a stab at it.

Indeed, fundamentally you have a new pair of balance values and you need to configure them, usually from things that aren't present in other configs. 

Config nodes... i mean, it's close, but I'm not getting much feedback at the moment, so I don't know if the concept needs work or if there are major bugs.

[Nertea]

New development version:

• Compatibility with DBS Electrical display (needs DBS 2.1.8+)
• Fix for Harvester NRE
• Temperature Adjuster can now be activated in the VAB and more or less works
• Added new Reactor rollout window (mirrors NF Electrical reactor window)

The only thing that remains for feature-complete-ness is actual models for the 3 new parts. Once that is done, I will start issuing packaged releases. 

 

[Zacho]

Im having some odd behavior with KA and SH with the patch. On ascent having the reactor cooling loop heat up to thousands of degrees and melt the core even with everything shut down and in a faring.

 

The other bug ive encounter is with the trimodal KA engines, if you shut down the reactor you can not restart the engine after and now that we cant control reactor power output the core life does not seem to change on power output auto lowering.

[danfarnsy]

I've been doing some testing. Here are some things I've noticed.
 

1. Craft with fission reactor load on the pad with varying degrees of core health. E.g. I have a mining/refining platform test on the runway, with a Garnet reactor, which loads with varying amounts of core health each time I revert to hangar and then launch again. The amount on load is anywhere between 100% health and core destroyed.
2. The UI overlay gets really cluttered, such that it quickly goes from being informative to being overwhelming and unhelpful, depending on how you're clustering radiators, compressors, etc.
3. I don't exactly know what the compressors, coolants, and heat sinks do. I know what those things do in real life, just not how you're implementing them here.
   • If a compressor is set to heat the temperature of a loop, everything in the loop heats up together, so I can't make my radiators more effective by pumping them up to a higher temperature than my core. If a core is at 800 K, then I need more/bigger radiators because they can only reject so much at a lower temp.
   • If I don't have enough radiators for the max heat output of a reactor, but my system isn't drawing much, the temperature remains fine. I can adjust it downward or upward with a compressor. But if I try to adjust the temperature too far downward, the compressor draws more power and the loop overheats. This is awesome. I don't know how much of the heat of the system is changing because the reactor is generating more heat to supply the additional power, or how much is because the compressor part is adding its own heat to the loop.
   • Is loop volume just the total thermal mass of the loop, i.e. everything has a same specific heat capacity and you're just changing how fast or slow it changes?
   • What's the difference between a heat sink and a radiator? Sink seems almost limitless.
   • Heat sink storage temperature rate of change doesn't change with time warp.
   • Heat sink storage temperature doesn't appear to have anything to do with loop temperature, just rate of heat input from generators?
   • Heat sink percentage stored seems to plateau around 85-86%, even though its temperature keeps climbing.
   • With two heat sinks, only one is filling and the other remains empty. Does it fill one first and then the other, and I just haven't reached max capacity on the first? Now one is at 87% filled, 3800 K, while second heat sink is empty.
4. In flight, if I change the Loop ID of any particular part, all of the parts change what Loop ID they display, and none of them seem to match reality anymore. Are those supposed to be fixed in the VAB and no longer changeable in flight?
5. Edit to add: Radiator efficiency changes with temperature in the simulator in VAB, does not seem to change with loop temperature in flight scene. Loop with Garnet powering a Charon MHD and eight GR-150 radiators will overheat well past 1000 K, even though GR-150 says it radiates 100 kW at 1000 K. Exactly 10 GR-150s will keep up with 800 kW heat output, regardless of loop temperature between 800 K to 1050 K. Radiator efficiency is listed as "-80%" on part info panel at all temperatures.

Notes: System Heat Development version as of 12 Aug, NFE 1.1.2, KSP 1.9.1.

Edited August 14, 2020 by danfarnsy
Added more comments, fixed numerical typo

[Nertea]

Thanks for testing! 

8 hours ago, Zacho said:

Im having some odd behavior with KA and SH with the patch. On ascent having the reactor cooling loop heat up to thousands of degrees and melt the core even with everything shut down and in a faring.

 

This is a fun one, the KSP data field I was using seems to look at vessel surface external temperature. So as you're rising through the atmosphere, this value goes to thousands of degrees, and its used to factor in to loop temperatures. 

3 hours ago, danfarnsy said:

• Craft with fission reactor load on the pad with varying degrees of core health. E.g. I have a mining/refining platform test on the runway, with a Garnet reactor, which loads with varying amounts of core health each time I revert to hangar and then launch again. The amount on load is anywhere between 100% health and core destroyed.
•  

Looks like some simulation values were persisting through vessel rollout, so if your reactor invisibly melted down in the VAB, that was getting persisted to the pad.

3 hours ago, danfarnsy said:

• The UI overlay gets really cluttered, such that it quickly goes from being informative to being overwhelming and unhelpful, depending on how you're clustering radiators, compressors, etc.

I'm open to suggestions to make it clearer. Options might include the ability to turn on and off loops, or something?

3 hours ago, danfarnsy said:

I don't exactly know what the compressors, coolants, and heat sinks do. I know what those things do in real life, just not how you're implementing them here.

I don't know if those parts are useful, which is why i haven't done a lot of work on the models. 

The heat sink vs radiator is easy, beyond some bugs. Sinks have max capacity, radiators do not. I see the timewarp bug, but I don't think I've ever tried to fill one up to 100% so I need to see what's up there. The storage temperature is only relevant when discharging the sink, it controls how hot the output is. I could hide it, not really important to the player. 

Coolant tanks increase the volume. With more volume, it takes longer for a loop to heat up so if you only need bursts of utilization followed by cooling periods, you could use this option with less radiators. 

The use case for the compressor is ill defined. The original intent was to provide a way to make the loop temp *lower* than nominal, for life support purposes generally. The system has no concept of ordering and I don't want to add one, so you can't increase the temperature of radiators without increasing the temperature of everything. Can't say I have a great solution here. 

 

3 hours ago, danfarnsy said:

• In flight, if I change the Loop ID of any particular part, all of the parts change what Loop ID they display, and none of them seem to match reality anymore. Are those supposed to be fixed in the VAB and no longer changeable in flight?

The intention is that this only changes the ID # and nothing else. When ships dock, their loops merge if they have the same ID, this allows you to ensure that doesn't happen (or does, depending on goal).

3 hours ago, danfarnsy said:

1. Edit to add: Radiator efficiency changes with temperature in the simulator in VAB, does not seem to change with loop temperature in flight scene. Loop with Garnet powering a Charon MHD and eight GR-150 radiators will overheat well past 1000 K, even though GR-150 says it radiates 100 kW at 1000 K. Exactly 10 GR-150s will keep up with 400 kW heat output, regardless of loop temperature between 800 K to 1050 K. Radiator efficiency is listed as "-80%" on part info panel at all temperatures.

I found a bug with the display, but this is intentional to make design a little easier. Radiator output is keyed to loop nominal temperature, not current temperature. I could go the other way around - i haven't tested the stability of the simulation like this, but the problem with that is that it's quite difficult to know what your temperatures will stabilize at beforehand. 

I will get through these bugs tomorrow and get some updates out. Thanks again!

[Nertea]

Update with fixes for the bugs reported above

• Fix simulated reactor throttle and damage being propagated to flight from editor
• Fix reactor throttle for engines keying off requested rather than actual throttle
• Fix heat simulation using wrong external temperature
• Fix radiator display 
• Fix fission engine mode switching for multimode engines

[danfarnsy]

10 hours ago, Nertea said:

I'm open to suggestions to make it clearer. Options might include the ability to turn on and off loops, or something?

Turning on individual loops, or lighting up individual parts with a highlight? Visualizing the idea that they're call connected in a loop is cool, but the lines with their right angles take up a lot of real estate.
 

10 hours ago, Nertea said:

The use case for the compressor is ill defined. The original intent was to provide a way to make the loop temp *lower* than nominal, for life support purposes generally. The system has no concept of ordering and I don't want to add one, so you can't increase the temperature of radiators without increasing the temperature of everything. Can't say I have a great solution here. 

So, what if a compressor is a way for two loops to send heat to each other? Use cases there are great. You'd have to figure out whether the compressor's own temperature and heat output belong to the sending or receiving loop, and probably have its efficiency and effectiveness decrease if it gets too hot.
 

10 hours ago, Nertea said:

The intention is that this only changes the ID # and nothing else. When ships dock, their loops merge if they have the same ID, this allows you to ensure that doesn't happen (or does, depending on goal).

That makes sense. In my test, I had Loop 0 and Loop 1. During flight, I changed one part in Loop 0 to Loop 1, and then all System Heat parts on the ship displayed Loop 2. If I tried to change a Loop ID on a part again, it incremented all of them to 3, 4, etc. It was definitely buggy.
 

10 hours ago, Nertea said:

Radiator output is keyed to loop nominal temperature, not current temperature. I could go the other way around - i haven't tested the stability of the simulation like this, but the problem with that is that it's quite difficult to know what your temperatures will stabilize at beforehand. 

Maybe it should go the other way around. Right now, your radiators have linear response to nominal loop temperature. E.g. the GR-150 on a nominal loop at 1000 K radiates 100 kW, and 80 kW for an 800 K loop. As long as your heat sources have predictable maximums, and the actual temp of the loop is below the radiator max, then it should be easy to know at what temperature radiator output matches heat sources. E.g. Eight GR-150s on an 800 kW reactor will only radiate 640 kW at 800 K, so the temperature will continue to rise until the radiator max temp of 1000 K, at which point radiation = sources. Seven radiators will peak at 700 kW, which isn't enough, so the temperature will continue rising until core failure. Nine of those radiators will peak at 888 K and then hold steady, etc.

And... I just saw your update! I will try it later today.

[Nertea]

4 minutes ago, danfarnsy said:

That makes sense. In my test, I had Loop 0 and Loop 1. During flight, I changed one part in Loop 0 to Loop 1, and then all System Heat parts on the ship displayed Loop 2. If I tried to change a Loop ID on a part again, it incremented all of them to 3, 4, etc. It was definitely buggy.

I'll look further into this but in your example, if you change a loop 0 part to loop 1, it should bump ALL your loop 0 parts to the next available loop (Loop 2). Loop 1 parts should stay unchanged. 

4 minutes ago, danfarnsy said:

Maybe it should go the other way around. Right now, your radiators have linear response to nominal loop temperature. E.g. the GR-150 on a nominal loop at 1000 K radiates 100 kW, and 80 kW for an 800 K loop. As long as your heat sources have predictable maximums, and the actual temp of the loop is below the radiator max, then it should be easy to know at what temperature radiator output matches heat sources. E.g. Eight GR-150s on an 800 kW reactor will only radiate 640 kW at 800 K, so the temperature will continue to rise until the radiator max temp of 1000 K, at which point radiation = sources. Seven radiators will peak at 700 kW, which isn't enough, so the temperature will continue rising until core failure. Nine of those radiators will peak at 888 K and then hold steady, etc.

I have not designed the heat simulation to be numerically stable like that. I have concerns that would need a lot of testing.

5 minutes ago, danfarnsy said:

So, what if a compressor is a way for two loops to send heat to each other? Use cases there are great. You'd have to figure out whether the compressor's own temperature and heat output belong to the sending or receiving loop, and probably have its efficiency and effectiveness decrease if it gets too hot.

I spent many hours trying to logic out how to send heat from one loop to another and it was not fun at all. It is on the roadmap, but nontrivial. 

 

Edited August 14, 2020 by Nertea

[Incarnation of Chaos]

5 hours ago, Nertea said:

I spent many hours trying to logic out how to send heat from one loop to another and it was not fun at all. It is on the roadmap, but nontrivial. 

 

Unless I'm misunderstanding that's basically how IRL refrigeration works (you have a hot and a cold side, and a working fluid with a low boiling point but easily liquified under pressure). Are you saying that it's that difficult to code that type of behavior in KSP? If so, then are all the Kerbals on the equator because of the lack of AC units xD

[Nertea]

14 minutes ago, Incarnation of Chaos said:

Unless I'm misunderstanding that's basically how IRL refrigeration works (you have a hot and a cold side, and a working fluid with a low boiling point but easily liquified under pressure). Are you saying that it's that difficult to code that type of behavior in KSP? If so, then are all the Kerbals on the equator because of the lack of AC units xD

It's not really hard to write a thermal simulation thing, but it is hard to try to write one that is robust and comprehensible. 

Edited August 14, 2020 by Nertea

[Incarnation of Chaos]

31 minutes ago, Nertea said:

It's not really hard to write a thermal simulation thing, but it is hard to try to write one that is robust and comprehensible. 

Ah, so it's a usability thing. Got ya.

[WarriorSabe]

19 hours ago, Nertea said:

The system has no concept of ordering and I don't want to add one, so you can't increase the temperature of radiators without increasing the temperature of everything. Can't say I have a great solution here

How about if your loop has two temperatures, nominal and effective? Nominal temperature matters for things putting heat in, effective matters for things taking heat out. They'd normally be equal but compressors can use power to increase effective (with the side effect of also slightly increasing nominal due to inefficiency; I think around 10% of what goes into effective might be realistic)

[danfarnsy]

11 hours ago, Nertea said:

I'll look further into this but in your example, if you change a loop 0 part to loop 1, it should bump ALL your loop 0 parts to the next available loop (Loop 2). Loop 1 parts should stay unchanged. 

Looking again, they do indeed bump loop ID for all parts in the loop. I may have reported this wrong before, as it is working correctly.

Loop IDs bumped enough times get to Loop ID **Not Found**, after which it won't increment to 0 again.

Other bugs with loading, etc. seem fixed. Nice.

I don't intend to be argumentative about the sources and radiators balance, since you explained your concern about simulation, but I just wanted to still give the feedback that it feels weird to have a system that is perfectly balanced at 805 K, deactivate a radiator for a moment while the system climbs to 1005 K, then turn that radiator back on, and have the system be in perfect equilibrium at 1005 K as well, even though the radiators are hotter. Should radiators balanced with sources ought to be able to bring temperature back to equilibrium at Loop nominal temp?

I won't beat that horse any more. Just wanted my feedback to be clearly explained.