CRCS For Newbies (A Reference guide for the rest of us!)

Hello, and thank you for attending the CRCS Seminar. As promised, electric thermometers and red alloy wiring kits are included in everyone's package as a part of the cost of the seminar.

I'm sure you are here to hear about the new CRCS systems, likely having heard such things as 'CASUC 2.0'. The truth is... far more complex. There are many engineering challenges involved with a CRCS system.

In fact, that does bring me to a point. The CRCS system is not one which is designed for beginners. There are many fault-points in any CRCS system. Running and maintaining a CRCS system will absolutely require an in-depth knowledge in the following fields: Nuclear engineering, logistical networking, pneumatic engineering, redstone wiring, logic circuitry, mechanical engineering, and possibly LUA coding as well.

If you don't have at least a solid understanding with reference materials for these topics, I would strongly advise you to take this final opportunity to depart with a partial refund now. A HAYO Corp. agent is just outside with design specifications for their Mk. I Reactor line, which are far easier to set up and employ, and will meet the needs of most consumers.

Anyone else? There's no shame in acknowledging your limitations.

All right, now let's get down to the brass tacks.

CRCS stands for Continuously Re-applied Coolant System, and its roots do stem from the old CASUC system, or Continuously Applied Single Use Coolant. However, as the only single-use coolant which works with current generation reactors consumes copious quantities of redstone or lapis, it is no longer economically viable for most situations. So alternatives were explored.

The basic concept of the CRCS is a radical departure from standard Nuclear Engineering protocols. Rather than try to dissipate the entirety of the heat generated from nuclear fission, components are used to store the heat. Before the components exceed safe levels, the reactor is temporarily disabled and the 'expended' components are transferred to one or more 'cooling towers' which have no fissionable materials but significant cooling potential.

This allows you to disperse your heat to a far larger heat sink, and enables the CRCS system to handle far higher heat levels than any traditional reactor to date, which means producing Energy Unit output far higher than any Mk. I reactor, capable of meeting or even exceeding old-school CASUC levels. The downside, however, is the massive infrastructure and initial investment of resources required to build such a system. As every cooling tower is effectively its own reactor, the costs involved are non-trivial. Having said that, most CRCS systems have a higher efficiency rating than a traditional Mk. I reactor, so maintenance costs are actually lower than one would expect. However, it would take a great deal of time to achieve the break-even point on initial cost versus maintenance cost savings.

The very first CRCS system was the old and antiquated DDoS Alpha reactor as seen here. It employed 60k Cooling Cells to store the heat, which were then transferred into the classic Coolmaster tower found on the following page.

While it was able to exceed even the EU output of a CASUC reactor, there were several problems with the system. First and foremost, it required 24 cooling cells per cycle, and with a cooling of 12-16 heat per cell per second, it required a huge number of cooling towers. Quite frankly, it was not economically viable.

Later DDoS reactors would scale it down to more manageable levels. Still exceeding the EU/t and Eff ratings of Mk. I reactors, but requiring far fewer cooling cells and far fewer cooling towers to accommodate them. Some designs also employed Neutron Reflector caps on the uranium rods to normalize heat dissipation values and increase efficiency, albeit with a higher maintenance cost, due to the neutron reflectors needing to be replaced periodically.

The next advance in CRCS technology came from an innovator by the name of Kenken244, who introduced the HVC (Heat Vent Cycle) reactor. He realized that while the Overclocked Heating Vent could only hold a fraction of the heat a 60k Cooling Cell could, they were self-cooling. This resulted in the original HVC design, found here.

Since OC Vents cool themselves 20 heat/second, employing them in a Coolmaster tower more than doubled, nearly tripled in fact, the cooling per component. The downside is the dangerously narrow safety margins. The designer suggested a one-second micro-cycle, and any sort of server lag could have disastrous consequences. However, the cost savings in having so many fewer cooling towers was quite attractive, making it a very viable option.

You can also use an empty reactor as a cooling tower for an HVC unit, which dramatically slashes costs by doubling the space available per cooling tower, as well as the cost savings in all the component heat vents you don't need. While it cools down slower, it is also able to be far more compact.

HAYO Corp. developed the next innovation in CRCS systems, the hybrid generator reactor. In essence, they employ cooling units in the generator reactor in addition to 60k coolant cells to increase the micro-cycle time. Focusing on reducing the copper expenditures required on the quad-cell reactors, they produced the CRCS Mk-1-EB-3.93 and the CRCS Mk-1-EA-4.5 reactors.

The significant advantage of the first is that it only uses regular Uranium Cells, instead of dual or quad cells, meaning far less copper and tin is consumed per cycle, further reducing maintenance costs. In fact, if one has access to certain bee species which produce tin and uranium, the entire system is completely renewable. The second system produces more EU/t, and still doesn't rely on quad cells which the DDoS reactors employ, resulting in a noticable savings in copper.

In rebuttal, ShneekeyCraft Inc. released an HVC design here which used a single Coolmaster Tower. With a 50 second micro-cycle, HVC may have found a new life in budged CRCS reactors.

The other truly revolutionary advance which HAYO Corp. published was a radically new cooling tower design philosophy. Kenken244 came up with the original design, which uses a fair amount of gold in the cooling tower in OC vents and component heat exchangers, as shown here. However, considering it gets a revolutionary 95 cooling per cell per second, it is well worth the expense. The only problem is the limited capacity. Most of these ultra-cooling towers only have a capacity for 4-6 cells at a time, requiring multiple cooling towers per cycle for some of the larger reactors.

These innovations, in turn, caused a radical re-design of the DDoS reactors, which also started employing OC vents and component heat exchangers to push the micro-cycle time.

There are several important numbers to keep track of when using a CRCS system which are not necessary in traditional Mk. I reactors. We'll go over these, why they are important, and get into some examples and how the numbers crunch.

One of the first numbers is a concept which nearly died out with the advance in nuclear engineering technology, and that is the Micro-Cycle time. Used in old-school Mk. III reactors, and revived again in CRCS systems, the Micro-Cycle represents how long the reactor can run before its components start melting. This number is easily found in any Reactor Planner software under the label 'Time Limit', found at the bottom of the same section the reactor components are kept. As an example, you can see on this DDoS reactor, the Micro-Cycle time is 179 seconds. You can also derive this number under the 'Timing' section, the very first number "Generation..." is your micro-cycle time.

The next important number is your cooling cycle time. This is derived from dividing your cooling capacity by your cooling tower's cooling per cell per second. Thus, a system using 60k Cooling Cells, with a 60 Cooling/cell/second tower, has a 1,000 cooling cycle time. Obviously, the higher your cooling per cell per second number is, the shorter your cooling cycle is, which is why the latests generation of cooling towers are so exciting. With a cooling of 96/cell/second, a 60k cooling cell has a cooling cycle time of a mere 625 seconds.

To derive the number of cooling towers you will need for a CRCS system, you will need to divide your cooling cycle time by your micro-cycle time, then multiply by the percentage of towers needed to hold the components. Therefore, in our examples, a generator tower with a micro-cycle time of 179 seconds has 8 cooling cells. However, the cooling tower can only handle 6 cells at a time. This means you will need 1.33 towers per cycle. Therefore, 625/179 = ~3.5 (rounding up for simplicity's sake) * 1.3 = 4.655. Now, you can't build half of a cooling tower, so you have to round that up to 5 cooling towers required to accomidate that reactor tower.

Now then, let's say the reactor tower got an upgrade with some OC vents and component heat exchangers, as shown here. This one has a micro-cycle time of 200 seconds. So crunching the same numbers, we end up a tiny fraction larger than 4. Now, since you have to have a brief pause to swap cooling cells, and give the OC vents time to cool, you can probably get away with 4 cooling towers, although you'd be cutting your safety margins down to slim pickings. So, despite the additional expense in the tower, you save far more by cutting down the number of towers needed by 1.

Now then, a major engineering challenge is to automate the exchange of the heat-laden components to the cooling tower(s) and cool ones back to the generator reactor. By far the most roubust system employs uses Redpower2 logic circuits.

A Timer is employed in conjunction with a State Cell to run the reactor. The Timer and State Cell are set to the same number, which should be a factor of your micro-cycle time. Thus, if you have a micro-cycle time of 200, these should be set to 20 seconds. If you have a remainder, that can be added to the state cell time. Thus, if you had a micro-cycle of 202, you set your timer to 20, and your state cell to 22. When the Timer pulses, it resets the State Cell's timer, then on the final cycle, the state cell finally gets to use those last two seconds.

Also connected to this timer is a counter. This will count the number of times the timer pulses. When it hits the desired number of pulses, it will activate, and stop the timer. It would be good practice to use an OR gate which accepts input from this timer, which is connected to a Toggle Latch that triggers the timer to be stopped.

Your thermal monitor and Nuclear Control System should also be able to send a signal through that same line, so if any heat buildup occurs in your reactor, it will automatically shut down the whole operation.

Next will be a Filter and a Retriever. If the system is transferring nine or fewer cells each way, then a signal from the Toggle Latch is all that is necessary to trigger the exchange. Simply have precisely the number of cells in each, and one pulse pulls the correct ammount.

**IMPORTANT**

Redpower2 machines differentiate between cells with a damage value and those without a damage value. Therefore, it is imparitive that you have components WITH a damage value in the Filter, to pull them out of the generator reactor, and components WITHOUT a damage value in the Retriever, to keep it from pulling still warm components back.

If you have more than nine cells in your generator reactor, you will need to employ a State Cell hooked up to a NOT gate and a Timer. When the signal from the Toggle Latch hits the State Cell, it will start a countdown. This will turn off the NOT gate, and allow the Timer to pulse. The duration of the state cell divided by the pulse rate of the timer will be the number of cells pulled in both directions.

You may need to employ cover strips to prevent unwanted connections in more compact designs.

Attached to your Retriever should be an in-line Item Detector connected to a counter. It will count the number of cells entering your reactor. Once it reaches the tally of the number of cells that are supposed to be in there, it will send a signal to the OR gate attached to the Toggle Latch. Assuming there isn't already a signal in the OR gate, say from your Nuclear Control system detecting heat or the cooldown period hasn't been reached yet, the OR gate will pulse, turning on the Toggle Latch and restarting the system. This will ensure that your reactor will not start without all cells physically present in your reactor.

As an alternative, you can use ComputerCraft to automate this system far easier. Use rp.setBundledOutput commands, have one color going to your reactor, and a seperate color going to both the retriever and the filter. You hook up your Nuclear Control killswitch to the computer. Set it up so that when it receives a redstone signal from that side, it automatically kills the reactor and initiates a cell cycle, then waits for the greater of either a full cycle time or the signal turning off before restarting.

While this is a much more compact and elegant design, it is not 'restart resistant'. When the server resets, so do the computers. Developing a program whch is restart resistant is theoretically possible, but I leave that up to the experts in the LUA field.

Thank you all for coming today. I hope you now have a deeper understanding of the strengths and weaknesses of a CRCS system, and what is involved in running and maintaining one. If you wish to keep abreast of the latest discoveries in the CRCS field, I suggest you keep an eye on the Nuclear Engineering newsfeeds.

Refreshments are available in Ballroom C next door. Representatives from HAYO Corp. and ShneekeyCraft Inc. are available to discuss what options are best for your situation, and have order forms on hand with special discounted offers for atendees of this seminar. You may also indicate on the guestbook if you wish to be kept abreast of new products from either of these companies.

Ladies and gentlemen, a moment of silence for the workers who gave their lives to bring us this new technology... okay, that oughta about do it. There will be a two hour recess until the next lecture. Thank you, and good day.

Quote from Kenken244

Very nice, well written. A couple of your links are messed up or link to the wrong thing though, you might want to check that.

Ahh, thank you for letting me know. Everything should be pointing properly now. Let me know if anything remains screwed up. Those responsible have been re-assigned to reactor prototype testing.

Quote from Gavote

Having problems with phantom heat with the coolmaster towers. it just seems to keep shuffling around.
http://www.talonfiremage.pwp.blueyonder.…utgf5op852o4um8 is the one that I'm using.

Over a one and a half year necro-post. Good job!

This information contained herein is from a previous edition and is no longer functional with the EX branch of IC2. If you notice, I even mention RP2, which should have been an indication as to just how old and out of date this post was.