Burn Rate Ramping and PID Control Adjustments

[RaeveNoir]

Loving this project. Currently running a quad reactor setup in Enigmatica 8 SMP with variable burn limits of 50mb/t water cooled, 375mb/t sodium cooled, and two 195mb/t that must be limited to 187mb/t to ride the thermal limit of water cooling. I found that the charge keeping mode needed some fine tuning, especially for how it would power-cycle reactors at low load. This lead me down a bit of a rabbit hole as you might tell.

The first commit adds proportional ramping to the fission PLC. It currently retains the original 5mb/t/s as a maximum while doing a 1/10th step per second. I later changed this to a 1/5th step as it seemed safe for small reactors. Maximum ramp rate should be added as a configurable value for the user, as I found that my largest reactor would temperature trip if ramped faster than the original 5mb/t/s, but my other reactors could ramp faster. Adding this to the configurator or UI is slightly beyond me for now. Minimum ramp rate was hardcoded to 0.1mb/t/s and I also changed the 'clamp to target' window of 2.5mb/t to 0.5mb/t and later 0.1mb/t to match. This allows much deeper throttling of reactors, into the sub-millibucket regime. The ensuing taper of ramp rate at very high loads should be beneficial to reactors that run very near limits and should make them a bit safer, while also improving fine control and smoothing in automatic control. With configurable maximum ramp rate for edge cases, this should address #346.

The second commit is a little messier. I found that even with windup prevention at saturated output, outside of saturation the accumulator was too sensitive to continuous power drain to be very useful while trying to hand-tune the PID to incorporate it. I added a 10% per second decay to the accumulator and it settled down nicely, and now the PID values look very sensible. This accumulator decay results in a slight droop of the charge level with load, but this also avoids overshoot on load reduction or other transients and zeroing the burn rate which then requires a full re-ramp, resulting in much better transient load response. The droop amount appears to be roughly one second of the current load but I work in big numbers (toggling 0.5-10 MRF heaters while tuning this) so I've not teased out charge keeping performance on minimal setups. I believe this addresses the intent of #366 when combined with the burn rate ramping changes.

[RaeveNoir]

Reverted generation control changes and retargeted devel branch by discord request.

[MikaylaFischler]

In working on the 0.01mB/t idling change discussed on discord, I've changed the reactor-plc to only ramp up.

Reiterating myself just for documentation purposes here: I don't really want ramping to be involved in PID control as it adds an extra layer of interference between the control output and the power generation. It was only done in charge level mode due to the controller wanting to jump very high very fast due to the error starting out large. Ramping mitigated this, but I hadn't thought to change it to be asymmetric.

I'm more comfortable with this asymmetric ramping with the 2.5mB/t minimum ramp. I'm curious to hear how this behaves for you once I address the issue of the Steam Feed Mismatch tripping at idle (due to the low rotation rate of the turbine resulted in an extended stabilization period).

I also modified the PD controller gains, as this all combined to make a much more stable controller, but I stopped short of adding a kI. Once I get this change merged into devel we'll see where that leaves us. It'll still have a sag depending on power draw due to having no integral term, but so far it has behaved a lot better for me.

[MikaylaFischler]

Again for documentation reasons and to make sure everything has so far been addressed in your first message:

I agree the charge control needs tuning 😅! As mentioned on Discord, I had settled with a "good enough" (barely) tuning for charge control pending updates before a full release out of beta. Given that people found and enjoy this project, it definitely needs some revisiting. (and of course I'm happy to hear you've been loving it!)

Maximum ramp rate should be added as a configurable value for the user, as I found that my largest reactor would temperature trip if ramped faster than the original 5mb/t/s, but my other reactors could ramp faster.

Can you clarify if this was a High Delta T alarm or an over-temperature alarm? If it was the latter (or both) than that was likely due to the turbine being slow to spin up and therefore having a water return rate deficit. That's what I'm thinking the most common limiting factor will be now that I've moved past my initial concern of disconnected or insufficient pipes.

This allows much deeper throttling of reactors, into the sub-millibucket regime.

Sub-millibucket control/throttling of reactors is already in place, it just bypasses ramping in favor of giving direct control to the control loop within the 2.5 mB/t band around the setpoint.

The ensuing taper of ramp rate at very high loads should be beneficial to reactors that run very near limits and should make them a bit safer, while also improving fine control and smoothing in automatic control.

Maybe I am misunderstanding, but the tapered ramping isn't a safety improvement for reactors running near limits since the existing system should never overshoot or undershoot the setpoint.

That 2.5 mB/t band was intended to provide finer control to the controller, your change just makes that a smoothed control within that band. Smoothing in charge level control makes sense due to the instability in electrical load, so I want to note charge level control already operates based on a 3 sample moving average (1500ms ideal) rather than the current level. I want to be careful impacting the plant with additional smoothing, filtering, or averaging. I am curious to see how this will behave in my testing as it sounds like it improved performance for you.

I'm planning to overhaul reactor PLC ramping in the future for #346, but for the time being we may go with your change as-is depending on what I observe when testing a few scenarios.

I agree the decay on the accumulator is a solid approach to improve the performance of the charge level controller.

We'll want to revisit performance/behavior with the idling changes I'll be merging to devel soon from 366-charge-control-mode-idling.

Apologies for the slow back and forth! Once I've reworked the RCS stability period at least in regards to the steam feed mismatch, we should be able to move forward with testing and any tweaks.