Add Support for System Heat #7

Lisias · 2023-08-16T13:14:30Z

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

arbsoup · 2024-08-23T00:49:12Z

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 · 2024-10-10T07:17:10Z

@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 · 2024-10-11T01:11:24Z

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 · 2024-10-11T01:48:55Z

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

I will surely work on it on the weekend.

Lisias · 2024-10-11T02:25:48Z

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 · 2024-10-11T02:58:56Z

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

Lisias · 2024-10-11T03:13:47Z

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 · 2024-10-11T04:11:19Z

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 · 2024-10-11T04:15:51Z

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
    }
}

For #7

Lisias · 2024-10-11T04:31:31Z

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 · 2024-10-11T13:15:52Z

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 · 2024-10-12T11:26:29Z

@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 · 2024-10-12T14:41:38Z

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?

Lisias · 2024-10-12T15:01:07Z

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 fuel to generate 2^3 times as much power. Are we on the same page there?

Humm... A missed that code, sorry. I was thinking this thing would behave more or less as a resource converter. You appears to be right.

On the other hand, the code you pinpointed on MemberUpdate is really only related to PartModule as it uses a helper class called ModuleResourceHandler to handle the resources. That code is a short circuit to create an Updater to that class (as it is the one having the target members) instead of using the current PartModule (that doesn't have them).

That class is the one having:

	public List<ModuleResource> inputResources = new List<ModuleResource> ();
	public List<ModuleResource> outputResources = new List<ModuleResource> ();

If we go to the ModuleSystemHeatFissionReactor code, you will find:

	protected List<ResourceRatio> inputs;
	protected List<ResourceRatio> outputs;

That's essentially the same thing - other than being protected instead of public - what should not be a problem, as the MemberUpdate looks for atributes public and nonpublic. And since these members are on the ModuleSystemHeatFissionReactor no further action is needed.

I will debug this thing after lunch. The problem is something else, perhaps something related to life cycle - TweakScale may be trying to scale tha member before it was initialized. I will need to debug the ModuleSystemHeatFissionReactor itself to see if I'm right on this one.

Lisias · 2024-10-13T17:55:43Z

@arbsoup

And... You were right! The MemberUpdate for the ModuleSystemHeatFissionReactor's inputs and outpus is being created as expected, but never being called!!!

[LOG 14:44:47.400] [TweakScale] TRACE: Created MemberUpdate(SystemHeat.ModuleSystemHeatFissionReactor, inputs)
[LOG 14:44:47.400] [TweakScale] TRACE: Created MemberUpdate(SystemHeat.ModuleSystemHeatFissionReactor, inputs)
[LOG 14:44:47.400] [TweakScale] TRACE: Created MemberUpdate(SystemHeat.ModuleSystemHeatFissionReactor, outputs)
[LOG 14:44:47.400] [TweakScale] TRACE: Created MemberUpdate(SystemHeat.ModuleSystemHeatFissionReactor, outputs)

Well... Trying to figure out why.

Lisias · 2024-10-13T20:07:10Z

Ow, Krap...

I exhausted my hypothesis for bugs on TweakScale.

[LOG 17:01:13.566] [TweakScale] TRACE: Created MemberUpdate(SystemHeat.ModuleSystemHeatFissionReactor, outputs) with type System.Collections.Generic.List`1[[Resource
Ratio, Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]]
[LOG 17:01:13.567] [TweakScale] TRACE: And yes, it's a (List<ResourceRatio>)!!
[LOG 17:01:13.567] [TweakScale] TRACE: Created MemberUpdate(SystemHeat.ModuleSystemHeatFissionReactor, outputs) with type System.Collections.Generic.List`1[[Resource
Ratio, Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]]
[LOG 17:01:13.567] [TweakScale] TRACE: And yes, it's a (List<ResourceRatio>)!!

Everything is being created as expected. All types are being recognized as expected (I wondered if by some reason List<ResourceRatio> woud not being recognized, as it happens with older versions of Java). It's really the MemberUpdated not being called by some reason (perhaps due the target being null).

I will take a break and come back later. I'm afraid I'm going to debug SystemHeat.ModuleSystemHeatFissionReactor) to understand why this is happening.

Lisias · 2024-10-14T12:32:32Z

I just ruled out MemberUpdater from the list of suspects. This is the log for scaling the FuelCell that uses the same code ModuleSystemHeatFissionReactor should be using:

[LOG 09:11:08.638] [TweakScale] TRACE: Created MemberUpdate(ModuleResourceConverter, reqList) with type System.Collections.Generic.List`1[[ResourceRatio, Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]]
[LOG 09:11:08.638] [TweakScale] TRACE: And yes, it's a (List<ResourceRatio>)!!
[LOG 09:11:08.638] [TweakScale] TRACE: ScaleExponents.Rescale(MemberUpdate(ModuleResourceConverter, reqList), MemberUpdate(ModuleResourceConverter, reqList), reqList, TweakScale.ScaleExponents+ScalingMode, TweakScale.ScalingFactor)
[LOG 09:11:08.638] [TweakScale] TRACE: MemberUpdate.Scale(8, MemberUpdate(ModuleResourceConverter, reqList))
[LOG 09:11:08.638] [TweakScale] TRACE: MemberUpdate.Scale::List<ResourceRatio>(8,MemberUpdate(ModuleResourceConverter, reqList)) from System.Collections.Generic.List`1[ResourceRatio]
[LOG 09:11:08.638] [TweakScale] TRACE: MemberUpdate.ScaleResourceList(ModuleResourceConverter, reqList) to
[LOG 09:11:08.639] [TweakScale] TRACE: MemberUpdate.Scale::List<ResourceRatio>(8, MemberUpdate(ModuleResourceConverter, reqList)) to System.Collections.Generic.List`1[ResourceRatio]

Note the [TweakScale] TRACE: MemberUpdate.Scale::List<ResourceRatio> entry. Something similar should be happening on ModuleSystemHeatFissionReactor.

TestBed: Issue_7-3.zip

My next step is to determine why the MemberUpdaters for the ModuleSystemHeatFissionReactor inputs and outputs are not being called after creation. , as we can notice below:

[LOG 09:11:08.609] [TweakScale] TRACE: Created MemberUpdate(SystemHeat.ModuleSystemHeatFissionReactor, outputs) with type System.Collections.Generic.List`1[[ResourceRatio, Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]]
[LOG 09:11:08.609] [TweakScale] TRACE: And yes, it's a (List<ResourceRatio>)!!
[LOG 09:11:08.609] [TweakScale] DETAIL: modExP: ModuleSystemHeatFissionFuelContainer SystemHeat.Modules.ModuleSystemHeatFissionFuelContainer
[LOG 09:11:08.609] [TweakScale] DETAIL: modExP: TweakScale TweakScale.TweakScale
[LOG 09:11:08.609] [TweakScale] TRACE: Created MemberUpdate(TweakScale.TweakScale, DryCost) with type System.Single

Lisias · 2024-10-20T12:49:35Z

Given recent happenings involving Forum as well some Day Job© ones (man, Forum is not alone on the mess...), I didn't managed to find time to come back to this issue this week.

Lisias self-assigned this Oct 10, 2024

Lisias added a commit that referenced this issue Oct 11, 2024

First attempt to scale ModuleSystemHeatFissionReactor.

7a43a6d

For #7

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Support for System Heat #7

Add Support for System Heat #7

Lisias commented Aug 16, 2023

arbsoup commented Aug 23, 2024 •

edited

Loading

Lisias commented Oct 10, 2024

arbsoup commented Oct 11, 2024 •

edited

Loading

Lisias commented Oct 11, 2024

Lisias commented Oct 11, 2024

arbsoup commented Oct 11, 2024 •

edited

Loading

Lisias commented Oct 11, 2024 •

edited

Loading

Lisias commented Oct 11, 2024 •

edited

Loading

Lisias commented Oct 11, 2024

Lisias commented Oct 11, 2024

arbsoup commented Oct 11, 2024 •

edited

Loading

Lisias commented Oct 12, 2024 •

edited

Loading

arbsoup commented Oct 12, 2024 •

edited

Loading

Lisias commented Oct 12, 2024 •

edited

Loading

Lisias commented Oct 13, 2024

Lisias commented Oct 13, 2024

Lisias commented Oct 14, 2024

Lisias commented Oct 20, 2024

Add Support for System Heat #7

Add Support for System Heat #7

Comments

Lisias commented Aug 16, 2023

arbsoup commented Aug 23, 2024 • edited Loading

Lisias commented Oct 10, 2024

arbsoup commented Oct 11, 2024 • edited Loading

Lisias commented Oct 11, 2024

Lisias commented Oct 11, 2024

arbsoup commented Oct 11, 2024 • edited Loading

Lisias commented Oct 11, 2024 • edited Loading

Lisias commented Oct 11, 2024 • edited Loading

Lisias commented Oct 11, 2024

Lisias commented Oct 11, 2024

arbsoup commented Oct 11, 2024 • edited Loading

Lisias commented Oct 12, 2024 • edited Loading

arbsoup commented Oct 12, 2024 • edited Loading

Lisias commented Oct 12, 2024 • edited Loading

Lisias commented Oct 13, 2024

Lisias commented Oct 13, 2024

Lisias commented Oct 14, 2024

Lisias commented Oct 20, 2024

arbsoup commented Aug 23, 2024 •

edited

Loading

arbsoup commented Oct 11, 2024 •

edited

Loading

arbsoup commented Oct 11, 2024 •

edited

Loading

Lisias commented Oct 11, 2024 •

edited

Loading

Lisias commented Oct 11, 2024 •

edited

Loading

arbsoup commented Oct 11, 2024 •

edited

Loading

Lisias commented Oct 12, 2024 •

edited

Loading

arbsoup commented Oct 12, 2024 •

edited

Loading

Lisias commented Oct 12, 2024 •

edited

Loading