XyFreak

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

@BatouOfNexus that line can only crash when the monitor is suddenly disconnected oO.

But I'm glad to hear things are sorted.

Also I owe you guys a story.... *starts writing*

Okidoki, I fixed it!

Unfortunately, you'll have to redownload the installer to upgrade to 4.1.

I'll post the story tomorrow, I need some rest now. Have this changelog in the mean time:

4.0.1 -> 4.1
 - Fixed a bug where turbines that are being calibrated can be suspended
 - Fixed a design bug where the performance prediction for passive reactors was based on linear regression.
   BRGC now has the ability to do polynomial interpolation.
 - Because the polynomial interpolation is THAT GOOD we can do numerical reactor optimization based on the polynomial.
   OPTIMIZATION-mode has been removed. This also fixes all issues of the OPTIMIZATION-mode (obviously).

-XyFreak

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.

@6XAM, can you give me your reactor setup?

@pwnstar It works with little to no effort with extreme reactors. I haven't gotten around testing turbines on ER though

So...here's what i THINK is happening:

The control programs are not running. Your turbine is turned off.

Then you start the reactor control program. Since the reactor control program does not have calibration data on the turbine it'll attempt to calibrate itself. HOWEVER the steam doesn't have anywhere to go and your reactors steam tank will "overflow" thus the temperature will raise.

When your reactors core reaches 2000°C the controller assumes there's something seriously rong with your setup and the safety mechanism kicks in; your reactor is flagged faulty.

What you need to do is (this is also described in the howto) is to give the reactor something to output the steam to. Just enable your turbine and you're good. I recommend that you can at least consume 10% of your reactors max steam production (the more the better) for the auto calibration to work as intended. It does work with less but more data means more accurate calibration.

After calibration is done you can start the turbine controller.

Note that you only need to do this once. The controller will store all calibration data in /etc/brgc_control.cfg

I also recommend you use more than one turbine. The turbine controller has been designed to work well with very high workloads and tries to prevent power shortages at all cost. Thus if you only have one turbine it will be sped down but never shut down completely (which is only important if you're not using much power at all).

You do that, be sure to wear some armor with diamond level protection though.

No committing suicide

yeah ok you mounted a disk to /BRGC.

However brgc is installed into /usr/lib and /usr/bin (think linux) so you need to install openos onto the disk and boot that.

Grab a new disk (or remove everything from the old one) and then just type "install". The OpenOS installer will ask you where to install OpenOS to. When done it'll ask you if you want to reboot. Remove the floppy and say "Y".

Once the computer has rebooted (which will be faster btw) download and run the brgc installer again.

Ok. This is just a guess but....

are you booting off the OpenOS install disk?

EDIT:

Can you do a simple "mount"? That should tell us why /lib/ is read-only

Honestly, I'm at a loss. It seems the installer can't open ANY of the files for writing.

The only thing I can think of is that /usr/lib is a _FILE_ on your computer for some reason and not a directory.

Can you check real quick if you can create a file at /usr/lib/oop.lua ?

-XyFreak

@DarkEternal,

I'm not sure what you mean exactly. I'll do a dry-run tomorrow to see if something broke with the bootstrap process.

Do you mean the installer fails?

@Chaoschaot234,

sorry I didn't answer you, for some reason I didn't get an email notification.

I'll do that, thanks for the input.

Ok, I'll need some info then:

 * What version of Draconic Evolution are you running?

 * Do you use any kind of non-default settings for Draconic Evolution?

 * Did it happen immediately or did it happen towards the end of the reactors runtime?

 * Do you run the program on a server with larger tickrate lagspikes?

-XyFreak

EDIT:

I just checked the code and it should work fine with the current DE versions. Time for me to do some actual tests on newer releases I guess?

Hello i have been racking my brain for a week trying to figure out how exactly you start it up, you do not mention how to power the reactor. Does it power itself? Thanks in advance

Hi,

the reactor powers itself but you have to jumpstart it.

You do that by supplying power to the "power injector" and having the reactor in "charging" mode. You can do so by pressing the power on button in the reactor gui.

@Dustpuppy

Sorry for some reason I didn't get a notification when you replied. I will update my test system this weekend to see if draconic evolution has been updated and broke the API (again). If that's not the case then maybe you switched something around?

-XyFreak

I've sent you a PM a few days ago. Please check that

I do everything like this , but , the produce of power just reduce '-'

Please keep an eye on the internal power storage on the reactor. Does it decrease below ~10%? If so, you're running into a failsafe and your reactor might not be setup correctly.

To make sure the controller is running correctly, please run "draconic_control runOnce" and see if it displays an error.

I've released the bugfixed version.

To upgrade to version 4.0.1 just run the installer again and restart your computer(s).

Here's the changelog:

4.0 -> 4.0.1
 - Fixed a bug where the controller failed to properly calculate a reactors rod limit (affects reactors with 50 B/t output).
 - Fixed a bug that prevented "brgcctrl" from setting the steamtarget manually.
 - Fixed a bug that caused turbines to not speed up as fast as intended during "SPINUP" phase.
 - Improved decision making for unsuspending turbines.
 - Controller will now try to prevent the internal steam tanks of active reactors from overflowing more aggressively.

-XyFreak

Hey, sorry for disappearing for a bit and not getting the update out by the promised time.

As compensation I've tweaked the turbine shutoff algorithm so it's a bit more efficient.

The update will definitely be released tomorrow. I will also run additional tests so I can figure out why my controller doesn't like your setup kevinkk525.

Fortunately my test-reactor is fairly similar to yours.

@Chaoschaot234

It is not possible to get the turbines to that speed with my program. This is simply because you can't get full blown turbines to >>1780 RPM with 2000mB/t.

Also the CC scripts "just" turn on/off the turbine so they can speed up the turbines while idle. This script regulates your turbines so they produce exactly the ammount of energy you need.

Additionally, I've hardcoded 1950 RPM to be detected as turbine failures. Explosions ARE coming to big reactors - we just don't know when

As for the networking question: The answer I gave you for the DR program applies here as well. It's just that this time, things won't explode but will fluctuate way too much to be able to control them properly. Running a non-GUI server (one for the entire grid) and a simple GUI-client can be done. I'll consider doing that as soon as kevinkk525s problems are gone.

-XyFreak

Okidoki,

I found an issue with the calibration of reactors with > 50 B/t steam output. The fix will be published tomorrow.

I was not able to reproduce the issue with the turbines not speeding up. Can you tell me how big your energy delta (in RF/t) is/was?

If a turbine still has energy stored, the controller will not power on additional turbines. Also, the controller tries to estimate the suspended turbines energy output and enables only the ones that're required to fit your energy needs.

From what you told me (turbine spinning up and down) you have quite irregular energy needs - but that's ok. To me it looks like the controller estimated one turbine being enough to power your grid. The turbine spinning up and down does support this assumption (spin down = turbine producing too much energy, spin up = turbine does not produce enough energy).

If your energy storage still empties, pls make sure your conduits can actually transport enough energy per tick (I'm pretty sure that's the case for you but I still wanted to mention it).

If everything should be in order from your point of view and your energy storage still empties, please provide more information:

• What's your typical energy consumption
• How are your turbines built (a screenshot will do)?
• How is your reactor built?

-XyFreak

I'll look into it, thanks for reporting the issue.

Hey Chaoschaot234,

---Server---

unfortunately, the delay caused by the OC networking "stack" would make the controller pretty unreliable. Having a central controller for multiple reactors via wireless lan is not going to happen.

HOWEVER: If you don't want a graphical interface, you can run the controller on a T2 computer without any trouble (maybe T1 - I have to test that).

You can also setup a single computer/server to controll all reactors locally.

The GUI being able to display the state of all reactors is definitely on my long-term TODO-list.

If you want, I can implement networking support by having the controller run locally and having it send the reactor state(s) to a remote computer, which handles the GUI. I won't be able to do so until the end of next week though.

---Refuling---

Refuling the reactor can NOT be automated. The reactor gets shut down and that's pretty much it. The controller itself does not notify the user but it's pretty easy to implement that as a third party program. If required, I'll provide an example program doing just that.

When refuling the reactor, you have to reheat it. When offline, it looses its heat pretty quickly. You can try refuling it directly after it shut down but I don't know whether that affects the core heat or not. You can not blow up the reactor when refuling/charging it other than breaking some of the reactors components after the core heat reached 2000°C. Breaking the reactor <2000°C is safe (assuming its offline).

(Note: I have had some issues with the reactor NOT storing its core heat properly when unloading the reactor cores chunk. Your issue might be related. This issue DOES occur on server restarts as well.)

---goBoom()---

Another thing regarding the explosion: The explosion is very wide - but not very deep. Building the reactor above your base at max world height is a safe way to run it in the overworld (or...well....to avoid holes).

-XyFreak

EDIT:

Also the explosion can be stopped by unloading the chunk, the center of the explosion is located at. A very nice way of "securing" the reactor is placing your chunkloader very close to the reactor core. Once it gets destroyed, the explosion will be unloaded and it'll stop.

Haha yeah the 1.9 MRF/t avg settings ARE scary.

"Burn mode" is not the final stage but more like the initial stage where it burns through a lot of fuel to get more RF/t earlier.

The reactor generates more and more energy, there more fuel it has converted to chaos. That's why you get higher average output at the cost of efficiency.

You can set "burnRFt" to 0 to disable that. That'll also make things less scary .

If you're using my settings It'll stay in burn mode until the reactor generates 2M RF/t (a few hours).

-XyFreak

Ok I updated my Draconic Evolution and it turns out they changed some of their API. I've adjusted the controller.

You can update to the latest version (1.3) by simply running the insaller again.

Thanks for bringing that to my attention - I propably wouldn't have noticed that for a bit

-XyFreak

Hello i have a little problem with this i just can't get it to work it always say unknown status on the screen the setup should be right i inserted the right adresses for each adapter 

Hi there.

"UNKNOWN" means the controller has not yet/wasn't able to query the reactor info.

Can you please run a "draconic_control runOnce" and see if it throws an error?

-XyFreak

Edit: Can you also post your configuration? Just for reference.

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.

• 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

1. wget the installer from here: http://xypm.tenyx.de/standalone/brgc_installer.lua
2. Run it
3. Done

Big Reactors Grid Control comes with three rc.d files:

1. /etc/rc.d/brgc_reactor.lua
2. /etc/rc.d/brgc_turbine.lua
3. /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.

As mentioned before the controller tries to autoconfigure everything:

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).

Main view:

Passive reactor details:

Active reactor 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.

This is where it gets interesting.

You will notice that passive reactors have two modes and an "auto" mode.

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.

Load

"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.

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.

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!