Reactor Auto-Planner (Genetic algorithm to automatically design reactors)

1st Official Post

    As a software developer, I like to try to automate as much as possible. Addons like IC2 and Buildcraft are great for this - but there are still some manual processes involved, such as actually designing the nuclear reactor. So I figured, why not write a program to automatically design an optimal reactor for me?


    The result is a two-part application - an ultra-fast simulator that can analyze a reactor design in milliseconds, and a genetic algorithm controller to control the optimization process. The genetic algorithm can be configured to optimize for any type of reactor based on simulation results. You can see the current status of the ongoing simulation here:


    http://www.silentkitty.net/share/temp/reactor/test/


    Currently, it is optimizing for an efficient mark I reactor that does not utilize consumables (reflectors or condensators), then optimizing for EU/t output, then for component cost. It's an intensive algorithm, so it's not likely to stabilize on a great result for several days. If anyone has suggestions for other types of designs to optimize for, let me know, and I can reconfigure the algorithm.


    Essentially this works by treating reactor designs as DNA, and applying Darwinian evolution (ie, natural selection). It starts out with several completely random reactor designs (just a random mish-mash of components across the board), and tweaks it based on making many different types of random mutations. Poor performers die off, while the better performers survive to produce offspring. Additionally, two different designs can mate with each other to produce a hybrid, increasing the genetic diversity.


    Note that the designs produced by this simulator may not perform identically in existing reactor simulators. The code for the simulator used here is based on reverse engineering the decompiled code from IC2. In general, this simulator will produce more accurate results. The only way to know for sure is to actually try the design in-game.


    Note that the version of IC2 the simulator is based on is IC2 2_2.0.397-EXPERIMENTAL


    There's a lot more involved in actually getting this to be an effective designer. Anyone interested can look at the code:
    For the simulator (C++ for speed): https://github.com/crispy1989/node-ic2-reactor-sim
    For the genetic algorithm (Node.JS for configurability): https://github.com/crispy1989/ic2-genetic-reactors


    Simulator and genetic algorithm are by myself, crispy1989. The web UI is by clueless222 aka cluekitty.


    Feedback is welcome! In particular, if you have particular design requirements that you'd like to optimize for, just post them here. Things that can be optimized for (including in combination with each other) include: Efficiency, EU/t, mark level, overall EU/t (for Mark II+, the average EU/t including cooldown time), whether or not reflectors are used, whether or not condensators are used, component cost, and more. Since simulations are long-running and can take several days, I'll periodically select a popular request to run, and will post here when a new run has started.

    It's worth noting that, as with Darwin's concept of natural selection, the designs produced by this algorithm come from nothing but pure randomness. Even though the designs may seem like they are designed logically by a person, in reality, it's just a series of random mutations.

    • Official Post

    Very fancy. Much potential here.

    145 Mods isn't too many. 9 types of copper and 8 types of tin aren't too many. 3 types of coffee though?

    I know that you believe that you understood what you think I said, but I am not sure you realise that what you read was not what I meant.


    ---- Minecraft Crash Report ----
    // I just don't know what went wrong :(


    I see this too much.

    What happens if you start it off with some human-created designs already known to work well, instead of whatever random mish-mash it generates randomly? Would is be able to find improvements that have slipped our engineers' brains?


    Also, I see that a few of the designs on that page look kind of intelligently built, rather than a bunch of random components that happens to not explode. Keep up the good work.


    And, a final suggestion: Make it work with MOX by having it really like designs that do not heat up or cool down over time while running, and like designs that don't cool when turned off either even more. Heat dumped into hull equalling that pulled out by vents and things is good; the smaller those rates are, the better.

    If you stare at my avatar hard enough, you'll notice that it consists of three triangular rings, interlocked in such a way that if you were to remove any one of them, the other two would be free to float apart.

    Quote from Someone Else 37

    What happens if you start it off with some human-created designs already known to work well, instead of whatever random mish-mash it generates randomly? Would is be able to find improvements that have slipped our engineers' brains?

    Yes and no. The final phase of the genetic algorithm (the "promoted" population) is essentially an annealing/fine-tuning phase, where it only makes minor tweaks to make small optimizations, without changing the overall design. This could be applied to human-generated designs to make minor improvements. However, *only* minor improvements would result. Human-generated designs would lack genetic variability, which is key to the correct function of genetic algorithms. In DNA terms, human-generated designs lack introns.


    I'd be interested in having a contest between this genetic algorithm and a human designer. Specify a set of exact requirements on which designs are evaluated, pick the current best human-generated design, and see if the genetic algorithm can find a better design - without any help or pre-seeding from the human design. It's quite possible that this could outperform the human design process, making pre-seeding it with a human-generated design completely unnecessary.

    Quote from Someone Else 37

    Also, I see that a few of the designs on that page look kind of intelligently built, rather than a bunch of random components that happens to not explode.

    Only the very first generation is random components thrown together. Complex patterns arising in the result doesn't imply intelligent design - just as the complex arrangement of molecules and cells in animals doesn't.


    Quote from Someone Else 37

    And, a final suggestion: Make it work with MOX by having it really like designs that do not heat up or cool down over time while running, and like designs that don't cool when turned off either even more. Heat dumped into hull equalling that pulled out by vents and things is good; the smaller those rates are, the better.

    I haven't coded in support for MOX fuel cells yet. I may add support if there's enough interest, but the result would likely take longer to stabilize, as exact equilibrium is harder to achieve using annealing-style techniques. Also, if I do add support for MOX cells, it wouldn't rate reactors based on the equilibrium being achieved - it would rate designs based on the same basic factors, eu produced, cycle time, efficiency, etc. The nature of the algorithm is that many different approaches can achieve the same result. Consider the case of a reactor that (somehow?) produces a sinusoidal wave of heat. While not in equilibrium, such a reactor could potentially have better overall results.

    Quote from SpwnX

    For MOX designs, you just "blacklist" reactor hull heat transfer.

    The way these types of algorithms work, they "figure out" what needs to occur to get to the end goal (which is an efficient reactor that doesn't explode), instead of being programmed with intermediate goals (such as trying to balance heat transfer). This allows them to approach problems (insofar as random mutations are an approach) in ways that a human may have not even considered.

    Quote from crispy1989

    Yes and no. The final phase of the genetic algorithm (the "promoted" population) is essentially an annealing/fine-tuning phase, where it only makes minor tweaks to make small optimizations, without changing the overall design. This could be applied to human-generated designs to make minor improvements. However, *only* minor improvements would result. Human-generated designs would lack genetic variability, which is key to the correct function of genetic algorithms. In DNA terms, human-generated designs lack introns.

    But I would think that finding minor improvements to an existing design would be much faster than coming up with something on par with a human-created design first, even if you had to create some new variations yourself. You've said this thing takes days to run- clearly, time isn't a concern. If it was, though, I would try feeding your program something from the Official Reactor Designs thread, and seeing what it comes up with.


    Quote from crispy1989

    I'd be interested in having a contest between this genetic algorithm and a human designer. Specify a set of exact requirements on which designs are evaluated, pick the current best human-generated design, and see if the genetic algorithm can find a better design - without any help or pre-seeding from the human design. It's quite possible that this could outperform the human design process, making pre-seeding it with a human-generated design completely unnecessary.

    I'd like to see that, too. Say you're looking for max EU/t from a 0-chamber reactor (3 columns) using only single cells. This design is already engineered for precisely this purpose.


    Quote from crispy1989

    Only the very first generation is random components thrown together. Complex patterns arising in the result doesn't imply intelligent design - just as the complex arrangement of molecules and cells in animals doesn't.

    Of that, I am very well aware. I was specifically referring to designs that looked something like this amid obviously random nonsense. Columns of single cells topped with dual cells isn't something I would've tried, but that's the whole point of having a computer try lots of things.


    Quote from crispy1989

    I haven't coded in support for MOX fuel cells yet. I may add support if there's enough interest, but the result would likely take longer to stabilize, as exact equilibrium is harder to achieve using annealing-style techniques. Also, if I do add support for MOX cells, it wouldn't rate reactors based on the equilibrium being achieved - it would rate designs based on the same basic factors, eu produced, cycle time, efficiency, etc. The nature of the algorithm is that many different approaches can achieve the same result. Consider the case of a reactor that (somehow?) produces a sinusoidal wave of heat. While not in equilibrium, such a reactor could potentially have better overall results.

    MOX fuel works exactly like normal fuel, except it burns half as long and produces more power if the reactor is hotter. With normal reactors, you want them to cool down faster than the uranium heats them up, in case something goes wrong. However, with MOX, you want it to be balanced, so the reactor stays hot after you heat it up. Additionally, designs that do not transfer heat between the reactor core and the components are even more preferable, because they don't cool down after the fuel expires.
    All you'd need to do is edit your scoring algorithm to give reactors with more balance and less core transfer higher scores.


    Also, I'm pretty sure fluctuating heat is impossible- unless you count Mark 1s and 2s periodically running out of fuel; Mark 3s, 4s, and 5s periodically being switched on and off; and the last couple hundred heat bouncing around in things like this cooling tower. While your point may be valid in some cases, I don't think most players want to use a MOX reactor that cannot remain stable at 85% heat- anything cooler means a smaller MOX efficiency boost, and anything hotter means stuff will start melting into lava.


    Quote from crispy1989

    The way these types of algorithms work, they "figure out" what needs to occur to get to the end goal (which is an efficient reactor that doesn't explode), instead of being programmed with intermediate goals (such as trying to balance heat transfer). This allows them to approach problems (insofar as random mutations are an approach) in ways that a human may have not even considered.

    But balanced heat transfer IS an end goal- arguably the most important end goal- of a MOX design, and not using components that interact with hull heat is the best way to fulfil it. As I noted above, you'd just need to work that into your scoring algorithm, alongside cost, efficiency, output, etc; or follow SpwnX's suggestion and ban basic, advanced, and reactor exchangers as well as reactor and overclocked vents altogether. You wouldn't even need to take special action against designs that put heat into the reactor hull with the latter suggestion- with nothing to take it back out, all such designs would explode.

    If you stare at my avatar hard enough, you'll notice that it consists of three triangular rings, interlocked in such a way that if you were to remove any one of them, the other two would be free to float apart.

    Quote from hoho


    Wouldn't that just make the algorithm fill the reactor with only MOX fuel?


    No, it would only block the Basic, Reactor, and Advanced Heat Exchangers and the Reactor and Overclocked Heat Vents. These are the only components than remove heat from the reactor hull- designs that use them tend to cool down over time, which is not good for MOX reactors. MOX fuel burns more efficiently when the reactor is hot, so you want MOX reactors to stay hot all the time.

    If you stare at my avatar hard enough, you'll notice that it consists of three triangular rings, interlocked in such a way that if you were to remove any one of them, the other two would be free to float apart.

    Hey,


    the web page is not working for me, so i can't see the results of your run. Is there a summary available somewhere?


    With the future updates in mind(MOX and heat reactor) i would like to copy your code and implement the new changes. Would that be okay for you?

    I am running the simulation on 8 machines at my university. I started yesterday and until now there are no exceptional designs. One Efficiency 4 reactor developed, the rest is mostly efficiency 3-3.7


    The reactors run at 100 EU/t in average, so unfortunately no efficiency 3 400EU/t reactor yet

    • Official Post

    Don't they mind that your using up their computing power to generator a game's reactor designs? :P

    145 Mods isn't too many. 9 types of copper and 8 types of tin aren't too many. 3 types of coffee though?

    I know that you believe that you understood what you think I said, but I am not sure you realise that what you read was not what I meant.


    ---- Minecraft Crash Report ----
    // I just don't know what went wrong :(


    I see this too much.

    Haven't asked yet but the jobs are all running with nice lvl of 19, so nobody should be bothered. The systems were all on idle before.


    Because there are no lectures at the moment nobody is sitting in the computer rooms. I'm not using some computing cluster that is running on heavy load 24/7 where i would delay scientific work, just some workstations in the computer rooms.


    I can always defend with the argument that i wanted to see how the genetic algorithm develops over time and that i am trying to optimize it. Since i am studying physics and programming is important i don't see a problem, but i'll ask the admin on monday.