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.
