Add Support for System Heat

[Lisias]

https://forum.kerbalspaceprogram.com/topic/193909-112x-systemheat-a-replacement-for-the-coreheat-system-october-9/

[arbsoup]

I've been customizing my own install and found that System Heat seems to have an unusual resource input/output scheme that I haven't been able to write exponents for.

The general form in the case of the reactor module is:

{
	name = ModuleSystemHeatFissionReactor
	[...]
	INPUT_RESOURCE
	{
		ResourceName = EnrichedUranium
		Ratio = 0.000016736
		FlowMode = NO_FLOW
	}
	OUTPUT_RESOURCE
	{
		ResourceName = DepletedFuel
		Ratio = 0.000016736
		DumpExcess = false
		FlowMode = NO_FLOW
	}
}

with Ratio being some number that determines fuel consumption:

https://github.com/post-kerbin-mining-corporation/SystemHeat/blob/d2ee2872720bae7469261d67445649795baf7119/SystemHeat/SystemHeat/Modules/ModuleSystemHeatFissionReactor.cs#L835-L837

The trouble is that I can't seem to select Ratio inside the INPUT_RESOURCE and OUTPUT_RESOURCE blocks. Using the normal selection method for INPUT_RESOURCE/OUTPUT_RESOURCE, but selecting Ratio instead of "rate", should require something like this:

TWEAKSCALEEXPONENTS:NEEDS[SystemHeat,TweakScale]
{
	name = ModuleSystemHeatFissionReactor
	inputResources
	{
		Ratio = 3
	}
}

But this does not affect fuel consumption and does not even produce any note in the log. Using INPUT_RESOURCE and such directly throws this in the log when rescaling:

[TweakScale] WARNING: No valid member found for INPUT_RESOURCE in ModuleSystemHeatFissionReactor for reactor-375-2

I've been able to modify other variables in that module, like the ElectricalGeneration curve, but not these. Is this an actual issue with TweakScale or am I just missing something obvious?

UPDATE: SystemHeat is now necessary for all Near Future reactors after the recent NFE overhaul, so this issue may be a little more likely to crop up when people try scaling them now. Still haven't figured out a good answer on my side, though I haven't had much time. I'll keep poking around and thinking.

[Lisias]

@arbsoup

But this does not affect fuel consumption and does not even produce any note in the log. Using INPUT_RESOURCE and such directly throws this in the log when rescaling:

[TweakScale] WARNING: No valid member found for INPUT_RESOURCE in ModuleSystemHeatFissionReactor for reactor-375-2

Try using input and output instead of inputResources and outputResources in the patch.

TWEAKSCALEEXPONENTS:NEEDS[SystemHeat,TweakScale]
{
	name = ModuleSystemHeatFissionReactor
	input
	{
		Ratio = 3
	}
}

[arbsoup]

Try using input and output instead of inputResources and outputResources in the patch.

TWEAKSCALEEXPONENTS:NEEDS[SystemHeat,TweakScale]
{
	name = ModuleSystemHeatFissionReactor
	input
	{
		Ratio = 3
	}
}

No luck.
[TweakScale] WARNING: No valid member found for input in ModuleSystemHeatFissionReactor for nfe-reactor-125-1

This is on my main install; I'll see if I can get around to assembling a minimal test install for it at some point, but I wouldn't have thought this matters outside SystemHeat and its funky custom resource-handling code. Did it work for you?

[Lisias]

I didn't managed to get the time to test it yet.

I will surely work on it on the weekend.

[Lisias]

I'm an idiot.

The names of the variables are inputs and outputs (plural).

TWEAKSCALEEXPONENTS:NEEDS[SystemHeat,TweakScale]
{
	name = ModuleSystemHeatFissionReactor
	inputs
	{
		Ratio = 3
	}
}

I'm trying to check if this will at least work during the patching phase.

[arbsoup]

On my end this fixes the log warnings when resizing things, but has no effect on actual fuel consumption rates in flight.

[Lisias]

Well... Bed time is already screwed. So...

I'm trying to see what happens with the following hacked part:

// Near Future Electrical 2.0.0
// Fission Reactor - SNAP-10A

PART
{
  // --- general parameters ---
  name = nfe-reactor-tiny-1
  module = Part
  author = Chris Adderley (Nertea)

  // --- asset parameters ---
  MODEL
  {
    model = Squad/Parts/Electrical/RTG/model
    position = 0.0, 0.0, 0.0
    scale = 2,1,1
    rotation = 0, 0, 0
  }
  rescaleFactor = 1

  TechRequired = experimentalElectrics
  entryCost = 35500

  // --- node definitions ---
  // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z
  node_stack_bottom = 0.0, -0.233, 0, 0.0, -1.0, 0.0, 0
  node_attach = 0.0, -0.233, 0, 0.0, -1.0, 0.0, 0

  // --- editor parameters ---
  cost = 10880
  category = Electrical
  subcategory = 0
  title = #LOC_NFElectrical_nfe-reactor-tiny-1_title
  manufacturer = #LOC_NFElectrical_manufacturer_kerbkastria_title
  description = #LOC_NFElectrical_nfe-reactor-tiny-1_description
  // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
  attachRules = 1,1,1,1,1

  // --- standard part parameters ---
  mass = 0.014

  dragModelType = default
  maximum_drag = 0.2
  minimum_drag = 0.2
  angularDrag = 1
  crashTolerance = 10
  bulkheadProfiles = size0

  // heat parameters
  emissiveConstant = 0.15
  heatConductivity = 0.005
  maxTemp = 1600
  thermalMassModifier = 2.0

  breakingForce = 200
  breakingTorque = 200

  tags = #LOC_NFElectrical_nfe-reactor-tiny-1_tags
  
  MODULE
  {
    name = ModuleSystemHeat
    volume = 0.1
    moduleID = reactor
    iconName = Icon_Nuclear
  }

  MODULE
  {
    name = ModuleSystemHeatFissionReactor
    moduleID = reactor

    // -- Heat stuff
    // ModuleSystemHeat instance to link to
    systemHeatModuleID = reactor
    // Heat kW

    HeatGeneration
    {
      key = 0 0 0 0 
      key = 100 30 0 0 
    } 
    // Above this temp, risky
    NominalTemperature = 750
    // Above this temp, reactor takes damage
    CriticalTemperature = 1300
    // Amount of damage taken by core when over critical temp
    // %/s/K, so with value 0.001, at 200 K over CriticalTemp, reactor takes 0.2% damage/s
    CoreDamageRate = 0.008

    // When repairing, amount of core damage to heal (%)
    RepairAmountPerKit  = 25

    CurrentPowerPercent = 100
    ThrottleIncreaseRate = 5
    MinimumThrottle = 25

    // -- Electrical stuff
    // Power generated
    ElectricalGeneration
    {
      key = 0 0
      key = 100 5
    }

    // --- Fuel stuff
    // Base lifetime calculations off this resource
    FuelName = LiquidFuel

    INPUT_RESOURCE
    {
      ResourceName = LiquidFuel
      Ratio = 0.0000000065206
    }
    OUTPUT_RESOURCE
    {
      ResourceName = Oxidizer
      Ratio = 0.0000000065206
      DumpExcess = false
    }
  }

  RESOURCE
  {
     name = ElectricCharge
     amount = 5
     maxAmount = 5
  }
  RESOURCE
  {
     name = LiquidFuel
     amount = 0
     maxAmount = 1.5

  }
  RESOURCE
  {
     name = Oxidizer
     amount = 1.5
     maxAmount = 1.5

  }


  MODULE
  {
    name = ModuleSystemHeatFissionFuelContainer
    EngineerLevelForTransfer = 3
    ResourceNames = LiquidFuel, Oxidizer
  }

  MODULE
  {
    name = ModuleCargoPart
    packedVolume = 450
  }

  MODULE
  {
    name = TweakScale
    type = stack
    defaultScale = 0.625
  }
}

I removed the b9ps from the circuit. I will go back to you as soon as I manage to check this stunt.

[Lisias]

Better. This is the whole setup for this test bed: Issue_7.zip

The savegame is called test-ts-waterfall (I was testing the Waterfall problem recently and reused the testbed).

There're two half-baked EC generators, reusing a Reactor CFG from NFE (but hacking it to use Stock model) and using LiquidFuel insted of EnrichedUranium and Oxidizer instead of DepletedFuel. One of them is scaled.

There's a Radiator to get rid of hear and a Serenity Rotor to bleed EC.

This test bed will allows us to focus only on the ModuleSystemHeatFissionReactor exponent - no B9PS, no CRP - only SystemHeat, TweakScale and the respective Companion.

I will work further on this problem tomorrow night.

[Lisias]

In time, I'm using the following Exponent:

TWEAKSCALEEXPONENTS:NEEDS[SystemHeat,TweakScale]
{
    name = ModuleSystemHeatFissionReactor
    // TODO:
    ElectricalGeneration = 3
    HeatGeneration = 2.5
    InternalCoreTemperatureResponseScale = 0.75 // TODO: balance this
    RepairAmountPerKit = 2

    inputs
    {
        Ratio = 3
    }
    outputs
    {
        Ratio = 3
    }
}

[Lisias]

Yep, I think the last patch is working. The commit 7a43a6d gave me the following results:

The fuel conversion is too small to be easily perceptible. We will probably need to further hack the __LOCAL/nfe-reactor-tiny-1.cfg thingy.

[arbsoup]

It's working for electrical generation, but not for fuel consumption. That was why I brought this up; I got everything else working fine, but the only unusual part of ModuleSystemHeatFissionReactor is that it doesn't use the normal stock method of converter inputs and outputs, and TweakScale handles those in a special way, so I wouldn't expect the same thing to work here.

Notice that the reactor on the right is running at about half power*, since it should be giving 5 x 2^3 = 40 EC/s and is outputting about 20 instead. Its stated core life, calculated from fuel consumption and storage, is about 16x that of the left reactor.

Bringing it up to full power would make that 8x (200y instead of 25y). But it also stores eight times as much fuel, so it must be burning the fuel at the same rate. (My own results when timewarping, using the outputs and inputs formatting you suggested, are that the two rescaled reactors take the same amount of time to go through 1 unit of EnrichedUranium.)

* You can force a reactor to output at 100% by clicking "Enable Manual Control" and dragging the Power Output slider to the right. That way the reactors don't autothrottle down to provide only as much as the rotor needs (5 + 20.4 + 1 from the clamp = 25.9 that the rotor draws + 0.5 for the TCS) and you can get rid of the rotor entirely since it won't matter, which is how I timewarped with these.

[Lisias]

@arbsoup

It's working for electrical generation, but not for fuel consumption.

I kinda forced the fuel consumption to work, but with weird results. My initial thought what the Ratios being calculated on floats, and since the test subject had extremely low ratios, they would be squashed into 0.

So I did the following test bed: Issue_7-2.zip

Hit 1 to start both generators.

The fuel converting is happening differently, as expected. However not exactly as I was expecting. Since the new ratios are 1 to 1, I would expect the bigger Hacked RTG to convert 3 times more resources.

But this wasn't what happened. And eyeballing the scaling code I noticed that they are being done on doubles, so - yeah, this hypothesis is kaput now.

Bringing it up to full power would make that 8x (200y instead of 25y). But it also stores eight times as much fuel, so it must be burning the fuel at the same rate.

Ideally nope, because the Ratios are scaled as well on the test subject - on "real life", the depletion of the uranium doesn't scales anyway, the Uranium conversion into depleted is directly proportional to the consumption, so for this specific use case the Ratios should be 1 (not scalable). If you are dealing with a Uranium generator, your are already set because this specific bug doesn't affects you (set both ratios to 1).

and TweakScale handles those in a special way, so I wouldn't expect the same thing to work here.

Nice catch. I had completely forgot about this exception. I working on this.

[arbsoup]

Since the new Ratios are 1 to 1,

They are in the original, too. The reactor produces the same amount of waste as the amount of fuel it takes in.

Ideally nope, because the Ratios are scaled as well on the test subject - on "real life", the depletion of the uranium doesn't scales anyway, the Uranium conversion into depleted is directly proportional to the consumption, so for this specific use case the Ratios should be 1 (not scalable). If you are dealing with a Uranium generator, your are already set because this specific bug doesn't affects you (set both ratios to 1).

I'm not sure what this is referring to. On the SystemHeat code I linked earlier, we can see that the Ratio is multiplied by fuelThrottle (0-1) and timeStep to give a number of resources that is requested directly. That is, the Ratio is really more of a rate; it describes the reactor's maximum fuel intake and waste output in units per second.

And that's independent of ElectricalGeneration. Removing the Ratio scaling completely from my TweakScale config file still doesn't change fuel consumption with size: the Ratio variable in that code would be the same, so its fuel consumption is unchanged (which is not "realistic" at all, surely).

And we can see in that screenshot that even though the two reactors are producing different amounts of electricity (after all, you have ElectricalGeneration = 3), they've consumed about the same amount of fuel in the same time. (I think the difference is that the reactor on the right was still not running at full power; see footnote on my last post.)

I would not think this is "realistic" in the slightest, hence why I am trying to scale Ratio = 3 in the first place; a reactor scaled up by 2x should probably consume 2^3 times as much uranium to generate 2^3 times as much power. Are we on the same page there?