Accelerator Driven Treatment of Nuclear Waste
quax writes "In the wake of the Fukushima disaster the nuclear industry again faces massive opposition. Germany even decided to abandon nuclear energy altogether and the future of the industry is under a cloud of uncertainty in Japan. But one thing seems to be here to stay for a very, very long time: radioactive waste that has half-lives measured in thousands of years. But there is a technology under development in Belgium that could change all this: A sub-critical reactor design, driven by a particle accelerator can transmute the nuclear waste into something that goes away in about two hundred years. Could this lead to a revival of the nuclear industry and the reprocessing of spent reactor fuel?"
Back in the 1990s this was developed at Los Alamos and a few other accelerator centers. it's not new or unique to belgium.
http://www.lanl.gov/orgs/pa/science21/ATW.html
http://www.world-nuclear.org/sym/1999/venneri.htm
Some drink at the fountain of knowledge. Others just gargle.
Primary reason is the many billions of dollars of development needed to figure it all out.
There is no design for a "working commercial thorium reactors". It's all just bits and pieces of theory, and experimental reactors that only answered some of the questions.
It's a possible technology, just not an actual technology. Kind of like the guy at NASA who recently got into the news for a pen and paper proposal of how warp speed might be possible. We are still a long way from building interstellar spaceships. Just like we are long way from building a Thorium salt reactor that works and is economically viable.
I'm the guy who write the software for the reactor (and the accelerator) of TFA. And yes, it run Linux, on embedded Xilinx cards with custom FPGAs. I can't vouch for the ability of the system to transmute long-life waste in a semi-industrial way as it's only a research reactor, not even a demonstrator. But it's the 3rd prototype of its kind and it's working well enough. More information is available here in french, and, as a long time /. member, if you have questions about the control/command software, I'll be happy to answer when I wake up in the morning ! Yeah, the name of the experiment is somewhat confusing: Genepi/Guinevere/3C/Venus/Ganddalf. One is the accelerator, one is the reactor, one is the data acquisition, one is the combined experiment... I get lost too.
Non-Linux Penguins ?
This is really neat. So is the current control software in Mol using your code?
Yes.
Will MYRRHA use the same code base or does it require a complete re-write?
Myrrha is only a concept so far: no development yet. It will most likely be a complete rewrite looking as to how far the code has diverged from the original specs.
Are you using a real-time kernel?
No. Everything that needs to be real-time is done on FPGAs and then transmitted to the kernel and user app via GPIOs.
What kind of quality control are you using to ensure the software performs exactly as designed?
Basically years of testing. Anyway, since it is a subcritical reactor, the security requirements are much less stringent. Some purely security stuff (read: not the control/command and or acquisition), is handled by other systems which have no interaction with mine. And as for the original 'design', well, it is research, meaning that specs start from a white sheet and build from there as we add pieces to the machine.
Are you using a functional programming paradigm?
All in C.
Are the reactors computer systems networked to the outside world? If so what kind of security measures do you have in place to safeguard access?
They are indirectly accessible (2 sets of firewalls). Like I said it is a research system with much less stringent security requirements, and quite a few researchers work on it and need remote access.
Is your software a critical component of the control feedback loop e,g. reduces beam intensity based on the measured neutron flux? If so what kind of redundancy is build into the system?
One set of software runs on the cards themselves: a minimalist BuildRoot install with a basic software that does as few things as possible (transferring acquired data to the network, reacting to commands from the Control/Command, sanity checks, basic security, going into security mode in case contact is lost, ...). One or more linux PCs run the C/C software and communicate with those cards and tell them what to do. If this soft crashes, nothing actually happens, the system keeps running for a while. You can actually shut down one PC and start another and everything keeps running like nothing happened.
But all the 'real' security is done in hardware: thermal shutdowns, beam intensity shutdowns, etc... It's actually difficult to turn the system on: everything has to be just right and there are plenty of little things that do stop the process.
Non-Linux Penguins ?