Big Reactors Grid Control

[Gepetto 0]

On 7/3/2017 at 0:25 PM, XyFreak said:

Hi @Gepetto

This is (basically) what the grid controller does on its own. It will alternate between running just enough to increase the charge in your storage or just enough to (barely) discharge your storage. "Charge" mode just tells it to use all available energy sources to fill your energy storage once.

There is no direct way to configure the thresholds BUT you can find them in /usr/lib/brgc/grid_controller.lua

You're looking for lines 46 and 47. The default is: Start discharging after the storage has exceeded 95% and start charging if the storage has fallen below 20%. If you choose to change these values, you'll have to restart your computer.

Also note that the controller attempts to identify instances where your energy demand will exceed the max capabilities of your energy generation and act accordingly. This is only important if you throw passive reactors into the mix though.

Hi, sorry for the long time, I was on vacation. I have a list of baffling things about my whole setup:

- on every computer startup, the storage core level is not being read and is shown as 0.00/0.00. Once I remove one piece of cable that connects the computer to the adapter on the core and put it back brgc can read the core level just fine. Don't even know if it's the computer's problem or brgc's problem

- core level is 5%, grid mode is INCREASING CHARGE yet all my turbines are suspended. Actually one of them on startup was in kickoff mode, it spun up to 1800rpm, then it switched it to SUSPENDED. When the mode is INCREASING CHARGE, shouldn't it increase the charge to 95%?... or is this because on startup the core level wasn't being read properly? Even if I cycle the Grid with the ON/OFF button, nothing changes, turbines are still SUSPENDED. EDIT: Occurs to me that maybe INCRESING CHARGE means there's something else increasing the power in the core... I got a bunch of culinaries burning, but that's small potatoes and I would still expect brgc to try to move the charge in the core to above 95% (that's because the charge now is <20%)....

- editing grid_controller.lua - most of the lines have had the tab char replaced by a strange char - not sure what that char would be, I can screenshot it if needed; would this in any way mess things up (eg, where mPWMLimitUpper is defined, if the tab was replaced by a non-ascii char, would that change the variable name?

 

Please tell me if you want screenshots

[XyFreak 36]

Hi @Gepetto,

Lets start with the easy part:

-> 3) You can safely edit the files with tab characters. It's just a display thingy.

Now to the odd part:

-> 1) Good catch - there is a bug in the grid controller init script: It forgets to initiate scanning for energy storage components on startup. However that raises another question: Why does it even find the energy storage blocks on computer startup on my test world in the first place?

-> 2) I didn't read your EDIT at first and went bug hunting. But....

BRGC measures the energy that is output from your energy storage and substracts the amount of energy that is currently produced by components connected to it (aka turbines / reactors). If you feed it energy from an external source, your energy output becomes negative. Thus it is indeed INCREASING your CHARGE by not running anything. This is part of the logic that shuts down everything if you're not consuming any power and... as far as I'm concerned... the correct behavior (only produce as much power as needed).

I'm guessing you're generating the ingrediends out of thin air (aka a farm)? Wouldn't it indeed be most efficient to not burn any fuel then?

If you have a good idea on how to make the logic smarter I'm all ears. I guess I can see the issue you have with your energy storage being essentially empty all the time thus removing the advantage of having it in the first place.....

[corbanj6534 2]

Quick question, can multiple capacitor banks be connected to the computer with different adaptors?

[XyFreak 36]

@corbanj6534

Absolutely, yes. You can mix types of storage components as well. Just make sure they're all connected to the same power network.

[corbanj6534 2]

4 minutes ago, XyFreak said:

@corbanj6534

Absolutely, yes. You can mix types of storage components as well. Just make sure they're all connected to the same power network.

Nice thanks. Also, when does the program auto start charging, I'm guessing below 50%?

[XyFreak 36]

Correct

[Ghan 2]

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.

[blunge 0]

Hi, I've used the big reactors control program before but for some reason this time, it's stuck on calibrating my passive 9x9x9 reactor. It moves all the control rods in, says its calibrating and doesn't do anything from there. I have had to get it started with brgcctrl discover to see the reactor as well, and it is also not saving any data to a cfg file. It's on a hard disk so room and permissions shouldn't be an issue? No idea where to go from here.

[corbanj6534 2]

Okay so slightly weird issue. Running 1.7.10. I've got 3 reactors and a capacitor bank connected to the pc. My friend on the same server has 4 reactors and 2 capacitor banks. Every time we leave them running over night, we come back to empty capacitor banks, one empty reactor and 2/3 that are full of fuel and aren't doing anything. All the reactors are in grid mode and the program says it is increasing charge.

[XyFreak 36]

@blunge

Sounds like it temperatures are jittering too much. I've gotta find a different way of finding "the" stable state....

 

@corbanj6534

If your reactors run out of fuel, the grid controller gets confused (or rather - it doesn't care). I'll put that on my TODO

 

@Ghan

Thanks for your input. A few pages back where I talked about the "overdrive" mechanic I've stated that I do not want to add a lot of state to the controller because that makes it increasingly harder to debug. I'd rather use an incredibly complicated algorithm that uses very little state than a very simple algorithm that uses a lot of state. Most of your suggestions require the controller to keep measurment values - a lot of them. You did give me an idea however:

Decaying Maximum

The issue with figuring out the maximum energy consumption is that if we blindly take the all time maximum, we're going to be trapped if there is a spike ONCE. This is bad obviously. We can counter this by keeping track of energy consumption over a given amount of time and aggregate things. This, however, requires to add a lot of state. So my idea now is to just take the maximum and have it decay over time. That way we have a maximum which will be affected by spikes but will not get trapped. The basic idea is the following:

If storedMax <= current then
  storedMax = current
else
  storedMax = storedMax * weight + (1 - weight) * current
end

"weight" is going to be inversely based on the energy storages fill level - similar to how the weighted energy consumption metric works but with a different range and curve. If the energy storage is full, we might not need to care too much about the maximum and it decays faster.

Now we also need to keep track of the duration of these peaks. I plan on measuring the duration between first exceeding the "storedMax" value and a significant drop (not too sure on how to define this). The controller will then attempt to always keep "storedMax * duration" RF stored at all times. I'll see how this performs....

Again, thanks for the input. I'll keep you updated

[corbanj6534 2]

1 minute ago, XyFreak said:

@blunge

Sounds like it temperatures are jittering too much. I've gotta find a different way of finding "the" stable state....

 

@corbanj6534

If your reactors run out of fuel, the grid controller gets confused (or rather - it doesn't care). I'll put that on my TODO

 

@Ghan

Thanks for your input. A few pages back where I talked about the "overdrive" mechanic I've stated that I do not want to add a lot of state to the controller because that makes it increasingly harder to debug. I'd rather use an incredibly complicated algorithm that uses very little state than a very simple algorithm that uses a lot of state. Most of your suggestions require the controller to keep measurment values - a lot of them. You did give me an idea however:

Decaying Maximum

The issue with figuring out the maximum energy consumption is that if we blindly take the all time maximum, we're going to be trapped if there is a spike ONCE. This is bad obviously. We can counter this by keeping track of energy consumption over a given amount of time and aggregate things. This, however, requires to add a lot of state. So my idea now is to just take the maximum and have it decay over time. That way we have a maximum which will be affected by spikes but will not get trapped. The basic idea is the following:

If storedMax <= current then
  storedMax = current
else
  storedMax = storedMax * weight + (1 - weight) * current
end

"weight" is going to be inversely based on the energy storages fill level - similar to how the weighted energy consumption metric works but with a different range and curve. If the energy storage is full, we might not need to care too much about the maximum and it decays faster.

Now we also need to keep track of the duration of these peaks. I plan on measuring the duration between first exceeding the "storedMax" value and a significant drop (not too sure on how to define this). The controller will then attempt to always keep "storedMax * duration" RF stored at all times. I'll see how this performs....

Again, thanks for the input. I'll keep you updated

Ah okay, I'm not sure why it's mostly using 1 of the multiple reactors but i'll see what happens once it's fixed  

[XyFreak 36]

Its always prefering the one it thinks has the best efficiency. Since there is a lot of randomness going on, two identical reactors are never calibrated to exactly the same values. Even recalibrating a reactor may yield different results.

[corbanj6534 2]

Just now, XyFreak said:

Its always prefering the one it thinks has the best efficiency. Since there is a lot of randomness going on, two identical reactors are never calibrated to exactly the same values. Even recalibrating a reactor may yield different results.

Ah okay that makes sense, so no easy workaround right now I assume?

[XyFreak 36]

Not right now, no. I'll have to include the fuel levels into some decisions - that's going to require a bit of code changes here and there.

I'm kinda burned out from traveling all over the place this weekend so... no code is going to be written for BRGC this week, sorry.

[corbanj6534 2]

Just now, XyFreak said:

Not right now, no. I'll have to include the fuel levels into some decisions - that's going to require a bit of code changes here and there.

I'm kinda burned out from traveling all over the place this weekend so... no code is going to be written for BRGC this week, sorry.

Ah okay, fair enough. No rush dude  

[Arcanox 0]

I'm experimenting around in creative mode with this because I'd like to eventually run it on my server, but I can't get the turbine control working. When I start the computer, it starts spinning up the turbine (KICKOFF mode), but once it reaches the CALIBRATING stage, it doesn't seem to be adjusting the steam flow rate at all, so it keeps spinning up until it hits the ERROR state. The Target RPM is displayed as "0" and the steam flow rate stays at 600 after it reaches CALIBRATING stage, never decreasing to stabilize the RPM. I'm guessing I'm doing something wrong with setup, but I have no idea what.

[Ghan 2]

7 hours ago, Arcanox said:

I'm experimenting around in creative mode with this because I'd like to eventually run it on my server, but I can't get the turbine control working. When I start the computer, it starts spinning up the turbine (KICKOFF mode), but once it reaches the CALIBRATING stage, it doesn't seem to be adjusting the steam flow rate at all, so it keeps spinning up until it hits the ERROR state. The Target RPM is displayed as "0" and the steam flow rate stays at 600 after it reaches CALIBRATING stage, never decreasing to stabilize the RPM. I'm guessing I'm doing something wrong with setup, but I have no idea what.

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.

[Arcanox 0]

1 hour ago, Ghan said:

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.

Ah, I will play around with it later today. I didn't know it tried to calibrate with max efficient steam flow...the turbine program I wrote a long time ago just used a PI loop on the steam flow to keep it at 1800 RPM.

[XyFreak 36]

Well BRGC also has something like that, the regulation takes place on the energy, not the RPM  

Especially since max efficiency turbines peak out at 1780 RPM

Also: @Ghan is 100% correct.

[CraXyOW3 0]

Searching and checking, for some reason my energy core wont show up in brgc!?

It is connected with enderio OC cable as my turbines and reactor are, but with an adapter on the stabilizer.

Anything special i am doing wrong? playing FTB Beyond 1.10.2

EDIT;
PLEASE move along, nothing to see/read! Connected adapter to pylon and now it works! DOH!!!!

[BaconxDragon 0]

For some reason the gui does not show the reactors I have connected. I have 4 turbines and 1 reactor connected by computer ports, i assume you just need to connect them by cables but i havent used oc with reactors before. I am also wondering how the adapter on a draconium multiblock structure placed. Is it next to a particle generator, or next to one of the draconium block? Thanks

[CrazyTolradi 0]

I'm using BRGC with two active cooled reactors to pump steam into a Mekanism turbine, however the program is basically just maxing the reactors at about 3400mb/t of steam each. The turbine certainly isn't full of steam or power and I re-ran the calibration just to make sure, but it seems to sit at that 3.4b/t or at about 93% rod insertion. Any ideas how to get the program to ramp the reactors to maximum capacity as demand allows?

[CrazyDolphin 0]

Hey, I really like your program and it has been mostly working smooth for me. But, recently I have been having issues with the GUI and my actively cooled setup with 1 reactor (calibrates successfully) and 10 turbines (also calibrates successfully).

So I start the installer through

wget

with the proper URL and it downloads and installs successfully. So I run

brgcctrl service all start

and it loads and all of the services start and it runs perfectly fine without the GUI. And normally when I start the GUI, it works fine and nothing is wrong with it (6 tall, 4 wide screen.) 

But just recently, when I start the GUI with the proper command

brgc_gui

(which I normally use), it breaks and looks like this (copied my world to go in creative and debug it.)

.

with a place to type at the bottom which is perfectly functional. I tried uninstalling it and reinstalling it along with my OS (OpenOS), EEPROM, and my whole hard drive. I even broke and reassembled my computer, but it didn't work and the crazy thing is that I didn't change anything that I was doing before other than made my reactor a tad bit larger.

Here are my system specs:

• Tier 2 server (w/ 3 floppy drives in rack with it)
• Tier 3 CPU
• 2 x tier 1 component bus
• 3 x tier 3.5 memory
• Tier 1 hard disk
• Tier 3 graphics card
• Internet card
• Wireless network card
• EEPROM (LuaBIOS) (No openloader)
• OpenOS 1.6.1 (functioned normally on same version before GUI stopped working

Now, here is what is connected:

• 10 x turbine
• Actively cooled reactor capable of supplying > 20 B/t of steam (but isn't supplying required steam, will get to that later)
• Wayppoint
• 4 tall 6 wide tier 3 screen
• keyboard
• 3 x rack floppy drive
• Tier 2 computer (personal use) *
• Disk drive *
• Tier 1 screen *
• Another keyboard *

* indicates that it is connected over a power distributor and switch to server.

I am also running the hermitpack 1.10.2 on FTB

Also, my reactor can output way over 18 B/t of steam but the program is preventing it from doing so when I need 20 b/t at max to run my 10 turbines. So tell me if I should reinstall a fixed version or if I should just re-calibrate it all.

And I would also like to mention that the reactor can get well over 2 B/t of steam to each turbine and well over 20 B/t of water pumped into it; *BIG BREATH* AND it can store the power on a huge capacitor bank.

So please respond and tell me what i can do or what you have to do to get the GUI working and/or the reactor outputting 20 B/t of steam, it's not the end of the world if I can't use the GUI or if I can't use the program at all, but I really like your program and I think that it's fantastic and I would like to keep using it without these annoying bugs.

[BrisingrAerowing 12]

For anyone still using 1.10.2, Extreme Reactors just released an update for that version that fixes a lot of bugs. I'm not sure if it fixes the turbine crash bug, but it appears that the OC integration was rewritten, so that issue may no longer appear.

[XyFreak 36]

Hey guys - I JUST got a bunch of notifications from the OC forums so... I'll go through them now...pretty late if you ask me.

Anyways:

• My desktop computer is broken.
• I'm building a new one.
• The parts are on the way.
• No data has been lost.
• I'll resume development once everything is up and running again.

@CrazyDolphin I don't know whats wrong right now but it seems you've connected a looooot of stuff. Can you replace the tier 1 component card with a tier 3 one and/or put in more? I'll try to reproduce the issue once I have a working desktop again

I'll also look at the issue where BRGC doesn't allow reactors to output as much steam as you want it to. My money is on your reactors temperature. Anything close to 700°C (IIRC) for an active reactor is going to cause BRGC to throttle.