XyFreak

@XyFreak I've gone ahead and updated the issue with the new information.

So today I put together a small ManagedPeripheral that use the same stings lookup that DE use with just a couple of methods and the delay did not go away. Implementing ManagedEnvironment and NamedBlock too changed nothing. I've also switched to the SidedEnvironment capability from the Environment one because the former is queried first by the OC cable than the latter but no luck.
I've also traced how callbacks are executed by OC / Lua and the code path is identical for my owns and the DE ones. 
The only big differences between ER and DE at this point is that I use capabilities to interact directly with the OC cables while DE need the adapter block but I'm not sure this is significant
The VM JIT could also have a play at this (maybe DE use the same method used by it's callback while drawing the big energy orb on the screen and so that method is called so much that the JIT optimized the hell of out it) and so I've let the other reactor-controller program I've used so far run for an hour or so but again, no differences
Not sure what else is there to try at the moment...

Hi there!
So, I've run the "test" program in my 1.10.2 devenv and got the same bunch of 1s. I then changed getEnergyStored() to always return a fixed values without querying the reactor and tested again: same result. This is good, as it's not the reactor code that it's slowing thigs down
What I basically have, code wise, is an OC'Enviroment with a bunch of @Callbacks (getEnergyStored, getFuelAmount, etc). DE also implement an Enviroment but it use a string lookup (from ManagedPeripheral) to call the methods. If OC is using reflection to find the correct method on every method invocation we could have and explanation of the delay. I'll have to look around a bit more in OC code
Z

Unfortunately, this is not correct. Running the controller in larger intervals would devastate its ability to keep the reactor output leveled. For smaller to medium sized passive reactors this wouldn't really be an issue. Active reactors however would constantly overproduce steam - then get their output cut and underproduce steam. Something similar would happen to larger passive reactors. My point was that in the past you could run BRGC litterally every tick with no additional lag introduced by outside factors whatsoever
I've run my test program (last post) against turbines and they have the same issue, unfortunately. They require a lot less API calls to control though (BRGC sets each fuel rod individually to achieve finer grained control over the output capabilities).
 
Recap:
Reactors + Turbines are affected. ER is not the only mod with this behavior (-> computronics) There are mods without this behavior (-> draconic evolution, mekanism) We have a very small program to check on ... lets call it: API call latency The issue has been observed on 1.10.2 at least (I've not yet tested 1.12) This is pretty much everything we can do without diving into the mods code and comparing how the OC API is implemented here vs DE or mekanism to figure out what's going on. If this goes on for a bit longer I might end up doing that this weekend.

I suspect your turbine is built incorrectly in that case. It sounds like you have too many turbine blades to support the coils you're using. IIRC, the program will basically push the turbine to the floor and run it as fast as it can during the calibration. It only will decrease the steam flow rate once it has calibrated against the maximum energy production possible. If the calibration causes it to go overspeed, then the program stops and errors out, as you see. So you should either reduce the number of turbine blades to bring it more in line with the coil(s) you're using, or add more coils to slow down the rotation.

So I feel like the algorithm doesn't do well when you have draconic crafting going on. Example is when I hook up my draconic crafting using the energy crystals and pull power from a mid-tier draconic orb or similar storage connected to the grid algorithm. Crafting awakened draconium will pull 2 million RF/t for a few seconds, then drop back to the previous passive drain from my power network. The algorithm responds to this by spinning everything up to 100% for a very short time, then dropping back down as the energy drain quickly slows back to normal.
This isn't directly a problem with draconic itself, but it's a good example of a very brief but huge power spike. The way that the algorithm will let power storage drop to very low levels means that unless I manually hit the Charge option, I'll probably run out of power when trying to do a few awakened draconium craft operations. I haven't tested around too extensively, but it appears that the algorithm doesn't track usage history for long enough to calculate the weighted power usage rate.
I'd have to sit down and play with some numbers a bit, but maybe some suggestion could go like this (and forgive me if something like this is already going on and I'm missing something):
1. We can measure the power usage in just straight RF over a given time period (say 5 minutes for example)
2. We know the maximum input rate that can be generated by the brgc network, and therefore can calculate the amount of RF that can be produced in the same time period as in #1.
3a. If the difference in the above numbers is large (amount used over 5 minutes is way more than can be generated in 5 minutes), then the algorithm should make larger adjustments to power generation. (How much? No clue. Needs testing.)
3b. The algorithm could probably easily keep track of a "maximum" of the #1 value. In other words - it keeps a number containing the maximum amount of RF ever used in a 5 minute period. Then, it will always keep that amount of power + x% in the grid, rather than working purely off of the % of total storage available in the grid. Could maybe subtract #2 from this value.
 
To me, 3a seems like much more of a "I'm going to invent numbers out of thin air" kind of system than 3b does. However in either case, I think various time periods should be tested. Maybe 5, 15, 30 minutes or something like that. In the case of 3b, the maximum should probably be tracked over the life of the program in a persistent way, though there is the potential for outliers. Maybe compare this maximum to the total power storage of the grid? If the entire grid was drained very quickly for some intense operation like an expensive RFTools dimension, maybe it doesn't help to track that value. Maybe just throw out values that are > 80% of total grid storage?
 
Just some random thoughts. Let me know what you think.

Hi everyone.     A while back I promised more releases, so here you go: Big Reactors Grid Control is a multi reactor/turbine controller for Big Reactors and Extreme Reactors. Mission goal: Be the best big reactors controller there is. Nothing more, nothing less.
First things first - here's the website: https://tenyx.de/brgc/
NOTE: Due to a bug with OpenOS 1.7.4, BRGC will not work with that version. Please update to 1.7.5.
Main features Active and passive reactor support Support for multiple reactors and turbines at the same time (n:m) Control active and passive reactors with the same controller Automatic configuration of everything (EVERYTHING!) Setup instructions
wget the installer from here: http://xypm.tenyx.de/standalone/brgc_installer.lua Run it Done Big Reactors Grid Control comes with three rc.d files:
/etc/rc.d/brgc_reactor.lua /etc/rc.d/brgc_turbine.lua /etc/rc.d/brgc_grid.lua If you want the controller to run at boot time, you can just use OpenOS' rc.d schema.
  There's a GUI as well as a command line utility for advanced users.
To start the gui, simply run "brgc_gui" and watch the magic happen.
The gui scales the screen resolution to match the screens ratio and should scale with basically all screen setups.
I recommend 3x2 or 4x3 screens.
 
As of now the command line utility allows you to do (almost) everything you can do with the GUI and also allows you to change the controllers configuration at runtime (if you so desire).
Check out "brgcctrl help" for further information.
 
How to set up the grid
In a basic setup you just interconnect everything:
All active reactors can output steam to all turbines. All passive reactors and turbines output energy to the same grid.
You CAN have passive reactors and turbines output energy to different energy grids.
While this poses absolutely NO problem for passive reactors, you will have to set some turbines to "independent"-mode (more on that below).
If you want your reactors and turbines to properly cooperate, you'll also need to connect at least one energy storage block to your energy grid.
Currently supported storage "blocks" are:
EnderIO Capacitors (requires the mod "Computronics") Draconic Evolution Energy Storage multiblocks. RFTools Energy Cells Thermal Expansion Energy Cells Mekanism Induction Matrices You can connect them using OpenComputers Adapters.
 
Discovering new components As mentioned before the controller tries to autoconfigure everything:
 
Passive Reactors When a new passive reactor is connected to the controller, the controller will first try to measure its maximum energy output. The reactor will have its output increased step by step and the average (interpolated) maximum will be used for that value (CALIBRATING).
After calibration has been completed, the controller calculates the most efficient energy output of the reactor.
 
Active Reactors
When a new active reactor is connected to the controller, the controller will first try to measure its maximum steam output (CALIBRATING). For this to work correctly the reactor must be able to output at least SOME steam (read: you need a consumer) and you will need to provide sufficient ammounts of water. The controller will detect reactors with a potential steam output greater than 50 B/t and limit its energy accordingly.
 
Turbines
When a new turbine is connected to the controller, the controller will first try to measure its maximum energy output (CALIBRATING). For this to work, make sure your turbine is built correctly. This means your turbine can be run at maximum supported steam (25mb/t per blade) without exceeding 1950 RPM. Should your turbine exceed 1950 RPM at any stage, the controller will shut down the turbine and flag it as failed.
Note: Your turbine is NOT required to be able to process 2000 mB/t. Smaller turbines work perfectly fine.
 
Screenshots
After this wall of text, here're some screenshots (pre 4.2).
 
Setup:  
Main view:
 
Passive reactor details:
 
Active reactor details:

 
Turbine details:
 
Let's go in order:
When you start up the GUI you will be presented with the main view.
Here a combined overview of passive reactors, active reactors and turbines will be presented.
You can click (or touch) on any of these items to open up a detailed view of the component.
Here you can enable/disable the component or change its behaviour.
 
What behaviour? This is where it gets interesting.
 
Passive Reactors You will notice that passive reactors have two modes and an "auto" mode.
 
PWM This is the behaviour everyone knows: The reactor gets turned on when its internal energy storage drops below 10% and gets turned off when the energy storage exceeds 90% of it's maximum capacity.
In PWM mode the reactor will generate energy at its most efficient rod level.
Overall this mode allows the reactor to generate energy as efficiently as possible as long as your actual energy consumption is below or equal to its optimal energy output.
But sometimes you need just a bit more energy and you don't want to upgrade your reactor or build a new one. "Classic" controllers will fail to produce sufficient ammounts of energy here.
 
This leads me to the second behaviour: Load
In "Load"-mode the reactor will always aim to produce energy at the same rate as it's consumed. Maybe some people already suspect what that mode is all about: It's a PD-like regulator.
While "Load"-mode is not as efficient as PWM-mode in situations where the energy consumption is below the optimal energy output, it will guarantee you're never running into energy shortages - provided you're not exceeding the reactors maximal capacity.  
Auto "Auto"-mode aims to eliminate the disadvantages of both modes by combining them:
If the energy consumption can be satisfied with PWM-mode, PWM will be used. If the energy consumption is above optimal levels, "Load"-mode will be used instead.
As a result, "auto"-mode generates energy as efficient as possible while always saturating your energy demands.
 
Active Reactors As of now, active reactors only operate in "load" mode. Steam is consumed and produced way too fast and the reactors internal steam storage does not allow for anything else.
 
Turbines
Turbines controlled similar to reactors in "load" mode: The controller will always try to balance the turbines internal energy storage out to 50% by using a PD-like regulator.
Turbines can be operated in "ganged"-mode or in "independent"-mode, with "ganged"-mode being the default.
The only difference between these two modes is that turbines in "ganged"-mode can be shut down by the controller, while "independent" turbines will always be active, even if they overproduce energy at the lowest RPM allowed.
This is handy if one (or more) of your turbines produces energy for a seperate (dedicated) energy grid but has to be controlled by the same controller. If such a turbine is not in "independent"-mode it may be shut down which will lead to energy failure in that grid.
 
That's it for now. If you have any questions, want to report bugs, etc., feel free to drop a message here.
Also: Do you want an indepth tutorial on how to use the command line utility? Need a description on what the GUI is actually showing?  
Have fun XyFreak  

Ok - again for everyone here.
BRGC does NOT work with your CPU set to Lua 5.3 right now. I have to at least change all my string.format uses throught the entire code for that to work.
So unless I release an update: Do not attempt to use Lua 5.3 if you want to use the GUI. The controller itself works perfectly fine on 5.3 though.

This normally happens when the file thats trying to be run is empty, happened to me a couple of times earlier with a different program as the files weren't downloading from pastebin. Try redownloading the installer as @XyFreak said.

@mcshadowdrag I've never seen this kind of issue before. Maybe try to reinstall OpenOS? You can redownload the installer by doing
rm /home/brgc_installer.lua and then wget it again.

Uh...yeah - ups. You changed it to exactly the right thing 

@DemolitionDerby You can have the GUI run at startup by editing the /etc/profile file on the computer.
This is the bottom of the default file:
cd $HOME clear /etc/motd source $HOME/.shrc -q And here's how I've changed that to be now:
cd $HOME brgc_gui clear source $HOME/.shrc -q (A clear comes after the brgc_gui because the GUI doesn't seem to perform its own clearing when it exits)

@daraku_dakara You need to connect the adapter to an energy pylon.

The controller is working as intended for you. On default settings the containment field stabilizes around 20%. I WILL make a youtube video because many ppl have trouble setting it up correctly it seems. Anyways - your setup seems to work fine.
Do NOT worry about the temperature as long as it is not above 9000. The default settings are going to throttle the reactors output between 8000 -> 9000 C (= it's adjusting the target saturation from 50% to 90%) between 9000 and 9900 the output rate will be reduced from 100% to 0%. Anything above 9900 will trigger an immediate shutdown (although it should do so before that point is reached).
Do NOT worry about the containment field unless it either starts dropping rapidly when it's well below 20% on default settings or it gets lower than 8% (which should NEVER EVER happen on default). Anything above 0 is perfectly fine.
Why is the controller keeping the containment field low?
To keep the containment field at higher levels, you're required to pump in more RF per tick. But since anything above 0% is fine, we can save a lot of energy by having the containment field low. How much energy you ask? Keeping the containment field at 50% cost 50% more energy than keeping it at 25%. 25% costs 16% more energy than 12.5%. You might've guessed it: The formular is: <somevalue> / (1 - field_percent).
If you go to the preset page and use my special settings, the containment will go to roughly 9.09%, dropping somewhere to 8.xx% if you cut the load and suddenly put load on it again. I'm running these settings on a server on...like...11 (?) reactors now.
Do not worry!
If your reactor is setup correctly, it is extremely hard to make it explode by accident. I blew up 4 reactors on my server:
3 blew up simultaineously because of dimension loading issues (do not put your reactor in a different dimension than your energy storage. Do NOT do it!) 1 blew up because I accidentally put a flux point directly on a stabilizer - with unlimited throughput. INSTA FIREWORKS! I've really tried everything (= could occur during normal operation) to blow them up - including cutting the load and reapplying it when the reactors were nearing their shutdown sequence (which is the most dangerous stage). Everything is still running.
 
Last but not least some explaination:
The jump in the containment field you see is because the controller did not yet run again and reset the feedback gate yet. It's still running at 1M rf/t for a few ticks, thus the surge in containment field strength you saw.
Actually "running" the reactor at 2000 is propably impossible. I acidentally cut the load to one of the reactors entirely so it went to 100%ish saturation with 0rf/t output - and temps did not go below 2150 C (at ~11% fuel conversion).
 
EDIT: Fixed my math (facepalm)

Just press the INSERT button on your keyboard

Yep my SSL certificate expired last night and I only got around installing a new one just now.
There are two (and a half) presets on the website. If you like to experiment yourself, there's also a simulation program that runs an entire reactor cycle in a few seconds. If you blow your reactor with the default presets, something about your setup is wrong.

Greetings fellow Draconic engineers, not too long ago I made a post here inquiring if it was possible to edit the program so it would remove the controlling the reactor part of it and leaving only the informative gui.
Say that you just want to have the nice gui telling you the status of the reactor and do the controlling on your own, or just have a screen elsewhere in the base showing said information.
 
After being suggested to talk directly with XyFreak by another member of the forums, I did just that, and within a few hours and messages we (read XyFreak) got this running and working, so im going to share here the same info and help he game me, just in case someone else wishes to do the same.
 
Before anything else, backup your saves, because if the fireworks starts…. Well they look quite nice but are very harsh on the surrounding area,  or in other words, say goodbye to your base and surrounding area  
First of you need to find a file called draconic_control.lua, located on .minecraft\saves\world_name\opencomputers
There you will find possible quite a few folders with a long string of numbers as a name. You need to find one that has this path /usr/lib
Inside of /lib is the file you are looking for (backup that as well, just in case)
Now you need to edit that file, and quoting XyFreak himself “comment out everything from line 173 to 222 (included)”or in my case up to line 224 for some reason. In other words find line 173 (the line below)
local output_base = math.floor(reactorInfo.maxEnergySaturation / 2222)              comment out everything from there (including the mentioned lines), to do so just place -- on the start of every line up to line 222 or 224 (line below) this one is the last line to comment out.
self.fluxGateOutput.setFlowOverride(output)            lastly you will need to find
self.outputLast = output           and change it to:
self.outputLast = 0 Save the file and you are almost done, the rest is done ingame
You run the program as you usually do "draconic_control start" then "dc_gui"
All this changes on the program wile it deactivates the control aspect of it, it still needs to be connected to two fluxgates, and you may say "hey i need those on the reactor to do my own thing! i cant have them locked by the computer." and that is easily solved, those pesky fluxgates don't need to be connected to the reactor, just place them out of sight, connect them with adapter and cable to the computer, find their address (just use components on the computer) edit the draconic_control.cfg (edit /etc/draconic_control.cfg) to match the new addresses and its done.  your program and gui should now run and show all the info on screen without controlling anything on the reactor.

Also when doing this on my own, i managed to fire up the "fireworks" and i had multiple folders in .minecraft\saves\world_name\opencomputers and somehow happen to edit the wrong one, just backup the saves before turning everything on.
 
Now to finish, a great thanks to XyFreak for helping and the patience to do so, also please forgive my bad english (feel free to correct me) as is mostly self-taught
Thank you and most of all, have fun
PS: Dont forget about chunks, use chunk loaders if necessary

@NamesReed is it keeping your storage full? Also try using the command line to set the steam target to 2000.

Extra cells worked like a charm: use storage busses on turbines, use interfaces on reactors -> DONE (other way around for water)

Hi guys,
 
Draconic Control will be the first program I'll be releasing (more to come).
The important stuff first: By now there are quite a few programs out there to control draconic reactors. However most of these don't even get close to about 1 MR/t. With this program 1.9 MRF/t (on average) is very well possible.
Of course if you're not interested in RF/t but only total RF generated, this program is for you as well.
Also, this one has a nice gui.
 
Go check it out here: https://tenyx.de/draconic_control/
 
Yes, it comes with yet another (unreleased) GUI library *cough*.
And yes it uses some kind of self built installer *doublecough*.
 
This program has a CC and OC version. If you want to skip to the OC setup instructions, click here: https://tenyx.de/draconic_control/#setup_oc
 
I'm open for suggestions and so forth.
 
 
This is the first of quite a few things I'm about to release so stay tuned if you like this one
You can follow me on twitter @XyFreak1 to stay up-to-date - I promise I won't spam your tweetdeck or something - mostly release related stuff
 
Have Fun
- XyFreak
 
WARNING
DO NOT USE THIS WITH OC 1.7.4! Timers are broken in that versions OpenOS and upgrading to this version will cause big holes in your world sooner or later!

Hi @MaSch
An OpenComputers program should never be able to crash your server.
Lets do a quick breakdown.
Here's your stacktrace:
Description: Exception in server tick loop java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(Unknown Source) at java.util.HashMap$KeyIterator.next(Unknown Source) at java.util.AbstractCollection.toArray(Unknown Source) at com.google.common.collect.ImmutableSet.copyOf(ImmutableSet.java:374) at elec332.core.grid.internal.GridEventInputHandler.tickEnd(GridEventInputHandler.java:91) at elec332.core.grid.internal.GridEventHandler.serverTick(GridEventHandler.java:49) at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_304_GridEventHandler_serverTick_ServerTickEvent.invoke(.dynamic) at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90) at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:185) at net.minecraftforge.fml.common.FMLCommonHandler.onPostServerTick(FMLCommonHandler.java:261) at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:657) at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:471) at java.lang.Thread.run(Unknown Source) You can see there're two lines that don't look like they're not vanilla minecraft or forge related:
at elec332.core.grid.internal.GridEventInputHandler.tickEnd(GridEventInputHandler.java:91) at elec332.core.grid.internal.GridEventHandler.serverTick(GridEventHandler.java:49) A quick google reveals that the mod those methods belong to is (suprise suprise) eleccore.
I suggest you go to the github issue tracker and report your findings because this looks pretty much like the exact same thing that's happening to you.
 
Next up... what is eleccore used for and can we temporarily remove it? Well it looks like eleccore is used by Deep Resonance and that mod has worldgen. So removing it is a no-no. Duh....
So...what can we do?
Since we know that Deep Resonance is using eleccore, you can try to remove all your Deep Resonance machines and see if you're still able to reproduce the isse. Is it gone? Well... this means that you're no longer able to use DeepResonance without crashing your server... but at least you're no longer crashing the server so that's a start. Additionally go and look for the Deep Resonance issue tracker as well and tell them that using that there're some serious issues with the library they're using.
 
I hope this somehow helps you. Unfortunately there's nothing more I can do. Those are the joys of modded Minecraft
 
-XyFreak

You can use braille Unicode characters to give the bars more resolution as with OC font they are exactly 1/4 vert and 1/2 horiz of a full character block(the characters are "⣀", "⣤", "⣶", "⣿", "⡇")

It's better to use block symbols:
▁▂▃▄▅▆▇█ ▏ ▎ ▍ ▌ ▋ ▊ ▉ █ http://www.unicode.org/charts/PDF/U2580.pdf

WARNING! This post is long and contains math! Continue at your own risk!
There's also a TL;DR!
Once upon a time, XyFreak tried to came up with ideas how to predict the energy/steam output of a Big Reactor.
His test reactor was a small 7x7x2 reactor.
He played around with some settings and thought "cool! If I pull out the rods by 10, the output goes up by roughly 10%. There HAS to be a linear correlation!". Not knowing what he's doing, he just went on and wrote some code for his Big Reactors Grid Control program.
In his attempts to make BRGC work out of the box, he came up with a way to figure out the sweet spot of passive reactors. He knew that with really unbalanced reactors the algorithm may have some issues but...who uses unbalanced reactors anyways, right?
His ideas seemed to work perfectly. He and his friends used his program with many different actively cooled generators and everything worked as intended.
Time passed, Minecraft 1.7.10 was nearing the end of its lifespan. Minecraft 1.10.2 emerged!
Suddenly, "Gelid Cryotheum" was gone! Reactors have become a lot less balanced and many people emerged that found actively cooled reactors to be a hassle.
But there was a problem: For some reason, less balanced reactors didn't quite work as intended.
"Yeah right... I'm an idiot.", XyFreak thought. His past lazyness came to bite him in the a**. He opened up his Visual Studio Code (Use it! It's great!) and started reworking his algorithm. But something was not right. For some reason, all his attempts to improve the algorithm failed! Either the controller undershoots the power target or overshoots it by... a lot.
He looked at the calibration data of his (now bigger) test reactor and saw a value twice as large as it should've been (again, http://br.sidoh.org is your friend).
And this is where the tale of advanced mathematics begins for real.
And this is also where I stop writing in story telling mode
So, I told you above that I assumed the reactors output (be it energy or steam) to be linear in regards to the rod level.
Well... for actively cooled reactors this is true (or at least a near perfect approximation). And since I mostly used actively cooled reactors (both in my real playthroughs and my test worlds) everything worked fine.
And since my passive test reactor was so small and well balanced, it worked there as well.
Now.... look at this image here:

This graph shows the energy output plotted against the (inverse) rod level. Doesn't look linear, does it? It's not linear at all!
I assumed the energy production to be linear, but the fuel consumption would go up dramaticaly as heat increases. Turns out it is the other way around! (Stupid me!)
Fuel consumption is linear with rod level but energy production decreases greatly as heat increases.
So... if it's not linear, what is it? Well... a polynomial 3rd degree seems to fit extremely well.

But how do you get such a polynomial? "Heh! Easy! We did this at high school!" you may think and that's what I thought as well.
<MATH WARNING!>
If you have N samples for x and f(x) you can easily create a polynomial of degree N-1. There're a couple of different methods to do it.
Now.. I don't have 4 samples, I have 17! "Easy! Just leave out some!". Yeah right....
I tried that and all polynomials sucked. Also, the polynomial libreoffice calculated seemed to fit perfectly. I wanna do that too!
After a while it struck me: It's a linear optimization problem (Of course it is! But it's been a while since I last worked with those, sorry.)
So...how to solve it?... ... ... QR decomposition...
Great! Now I'll have to do linear algebra in lua.
I always wanted to avoid using advanced math in brgc and now I have to work with matrices... great!
So...what do I need first? Right... matrices in lua. So I wrote a small library to work with matrices and the operations (and only those) I'm going to need to get QR decomposition working.
Next up? QR decomposition! But how does it work again? It's been a while since I last did something with that (at least 4 years).
Fortunately, Google is your friend (I'll append the links to the end of this post in case you're interested).
After 4 hours of implementation and debugging, everything worked. Well that was easy...not.
Next up: We're going to have to work with polynomials. So we need a library for that as well, right? 10 Minutes later: done.
I fed everything with my sample reactor values aaaaand....perfect!
Now...we got a nice way to interpolate functions. Maybe we can use it for the optimization as well?
Let's see...
Let the reactors efficiency denoted by E(p) = O(p) / C(p)
Where p is the percentage of the inverted rod insertion level, O(p) is a function that gives us the energy generation for rod level p and C(p) gives us the fuel _c_onsumption for rod level p.
O(p) is a polynomial of degree 3 and C(p) is of form C(p) = a * p. So we just devide two polynomials, right? How bad can it be.
I'll spare you the details, it's not worth it. The result is NOT a polynomial (well duh!).
BUT! Turns out we can use polynomial interpolation if we feed the interpolator the rod level and the efficiency values as samples (we already got those from the calibration).
Now we have a polynomial that describes the reactors efficiency!

(We want to figure out the peak of that little mountaint)
For optimization purposes we're interested in the local maxima of that polynomial between 0 and 1 (0 = reactor off, 1 = reactor max). Thankfully, this is easy!
Thanks to the QR decomposition, the numerical calulus lecture was still on my mind and we did that stuff as well.
And when I'm saying "easy" I mean it. Take this code:
function polynomial.converge(polynomial, x, iterations) local df1 = polynomial:derivate() local df2 = df1:derivate() local dx = 0 - df1:eval(x) / df2:eval(x) for i=1, iterations do x = x - df1:eval(x) / df2:eval(x) end return x end That's the code. Here's some background, if you like: https://en.wikipedia.org/wiki/Newton%27s_method_in_optimization
DONE! Does everything work? Hell yes it does! This time I tested it with multiple designs and on 1.7.10 and 1.10.2.

TL;DR
XyFreak assumed stuff about reactors that's complete bullshit. It never came to light because his testing sucked.
Magic (math) happened. Stuff now works perfectly fine. Optimization-mode is gone. Everything is awesome.
Also:
I'd like to mention that I've now officially used more university knowledge to develop Big Reactors Grid Control than I've ever used in my day job.
So kids...keep this in mind: Pay attention in school! You may not need it in real life. But you may need it in Minecraft someday!
If you read everything, thanks for staying with me
-XyFreak

QR decomposition links (german)
http://www.math.uni-frankfurt.de/~numerik/lehre/Seminare/ProSem_MA_SS11/qrzerlegung.pdf
http://numerik.uni-hd.de/~lehre/SS12/numerik0/12-la-5.pdf
http://www.mathematik.uni-muenchen.de/~lerdos/SS08/Num/trans4.pdf

Ok, while I wasn't able to gather the exact reactor design from what you described, I managed to build a somewhat similar reactor that triggers something that I believe is the same issue.
I can't believe I've overlooked that >_>. I dunno how long this is going to take me to fix but i'm working on it.