标签: simulation

When I first tried to run a quantum mechanical calculation in a computer, I used a humble Sinclair Spectrum ZX+. These days we have GFLOPs-scale computational capabilities available to us in products as unassuming as a smartphone.   Quantum simulations that previously required a huge and expensive supercomputer can now be efficiently executed in an affordable embedded device. This new computational power is a key enabler for STEM (Science, Technology, Engineering, Mathematics) education.   This allows for a new approach for physics, not from the pure mathematical point of view, but from a very simple algorithmic focus. We can think about this as an analog vs. digital approach. From my own experience, I can assure you that simulating complex quantum systems by running a little program on your own computer is a really enlightening experience.   While attending the EE Live! 2014 conference and exhibition earlier this year, I had the opportunity of getting acquainted with Adapteva's CEO, Andreas Olofsson. Adapteva broke into the mainstream EE scene with its Parallella board Kickstarter project. This credit card-sized open-hardware USD$99 system is widely considered to be the world's most energy efficient supercomputer.   You can imagine how happy I was to discover that Max Maxfield, my editor at EETimes, was one of the backers of the Parallella project. I became even happier when Max said he would loan me his own brand-new Parallella supercomputer -- the only condition being that I should do something cool with it. The point is that I already knew what I wanted to do with the Parallella.   As a proof of concept, my mission was to run the most energy-efficient quantum simulation ever performed in a classical -- non quantum -- computer. This is the story of how a $99 embedded supercomputer can be used to perform state-of-the-art quantum physics simulations.   The Standard Model In the context of particle physics, the Standard Model is a theory concerning the electromagnetic, weak, and strong nuclear interactions that mediate the dynamics of the known subatomic particles.   Now take a look at the mug in the photograph below. This is the mug from which I drink my coffee every morning. The equation on this mug reflects a Lagrangian formulation of the Standard Model.     Everything we know about physics (except Gravitation) is embodied in this apparently simple equation. Of course, you also need to understand underlying mathematical and physical concepts, such as the QFT (quantum field theory) framework and the Lagrangian formulation, in order to extract useful information from this expression.   The first line describes the dynamics of all the force fields -- the gauge bosons which carry the force; e.g., the photon, which is the massless particle behind the electromagnetic field.   The second line describes the matter fields. This accounts for fermions and anti-fermions and their coupling to bosonic fields; i.e., the electron -- the particle from which all our EE technology arises.   The third and fourth lines represent the coupling of matter fields with the Higgs field and the dynamics of the Higgs field itself, respectively. The Higgs field not only accounts for the mass of both the gauge bosons and the matter fermions, but it also hides some other secrets of our universe.   Computational physics From the Lagrangian formulation of the Standard Model we can create algorithms that we use to calculate predictions that can be experimentally verified. This is the way in which our most accurate theories are tested in huge experimental facilities such as CERN.   The problem is that simulating a quantum field in a classical computer is a very difficult task. It requires massive parallel floating-point computation capabilities. Fortunately, many of the calculations that previously required a supercomputer can now be performed in a conventional desktop or laptop machine.   As an example, the image below is a snapshot from my own Ubuntu workstation running a Python script coding the Dirac equations. The whole Dirac and Maxwell equations can be derived from the QED (Quantum Electro Dynamics) section of the Standard Model Lagrangian formulation expressed as an algorithm with no more than 100 lines of code. Despite this simplicity, the code accounts for spin, quantum mechanics, relativistic effects, anti-matter, and so forth.     I've actually tested this piece of code on a variety of ARM, i386, and AMD64-based machines, which demonstrates that it can be run on any hardware floating-point capable processor, including the one that powers your smartphone. Furthermore, this code can be easily modified to squeeze all the power of specialized data-crunching hardware (OpenCL, CUDA, etc.).   In this point, it's quite clear what I want to do -- use the awesome power of the Parallella to run an optimized QED simulation.   Meet the Parallella The photograph below shows the Parallella computer lying close to its box and a dollar coin. Despite its credit-card size, this little rascal boasts a vast amount of processing resources.     The chip under the heat sink is a Xilinx Zynq device, which comprises a dual ARM Cortex-A9 processor and a 7-series FPGA on a single die. The Zynq is a game-changing device on its own, but there is more inside the Parallella.   The shiny chip, is an Adapteva Epiphany III multicore processor. Built using a 65nm process, the Epiphany III embeds 16 cores, which are able to deliver an awesome 25GFLOPs performance in single-precision format (the new Epiphany IV is built using a 28nm process, sports 64 cores, and provides an impressive 90 GFLOPs throughput).   With only 5 watts of power consumption under typical workloads, it's clear why this tiny processing beast is claimed to be the world's most energy efficient computational engine. Furthermore the Parallella is designed in such a way as to facilitate the building of processing clusters, which makes this board an optimal choice for deploying low-cost and low-power supercomputers.   Hot stuff! Processing information is a physical process that wastes energy. The more complex the simulation you intend to run, the more energy (and time) you are going to consume.   Energy consumption in electronic systems translates into thermal issues. This is why most of the processing engines used in supercomputers require advanced active cooling, such as industrial-grade air conditioning, liquid cooling, or hardware specific heat-pipes.   Despite the fact the Parallella is extremely power efficient, the small size of the board does mandate some level of active cooling. Fortunately, extracting the unwanted thermal energy from the Parallella board requires a not very powerful fan.   Thus, in order to avoid thermal issues when running at full steam, I constructed a Lego Parallella case that includes a low-end standard PC cooling fan. The two images below show my case with the fan raised for access and lowered when running.       If you are the proud owner of a Parallella, you'll be interest to hear that Adapteva is working on offering active cooling cases for both cluster and standalone configurations ( click here for more details).   All systems go! In the photograph below we see my Parallella setup running a full-blown Ubuntu desktop based on the Linaro project. With a full HD-capable HDMI connector, USB interface, and Ethernet connectivity, the Parallella really is a fully functional, credit card-sized supercomputer for just USD$99.     On the number-crunching side, the Parallella toolchain is completely self-contained. An algorithm can be written, compiled, and executed on the platform with no need for an external host. What's more, you can easily upgrade the entire toolchain, the Operating System libraries, and even the Zynq FPGA bitstream when a new upgrade is published.   In the image above, the Parallella is simulating the evolution of an electron/anti-electron field using a QED framework. More specifically, the Parallella is calculating and plotting the relativistic evolution of a spin-1/2 fermion field inside an electromagnetic potential.   An un-optimized version of the algorithm can be run on the Zynq's dual ARM Cortex A9 processors, just as could be done on a low-end embedded computer such as the BeagleBone or the Raspberry Pi. But when the code is optimized so as to take advantage of the Epiphany III processor, an approximately 15X speed-up is achieved.   This is maybe the world's most power efficient Quantum Field Theory computation ever performed on a classical computer, but this not the important issue here. The important thing is that this experiment is just an example demonstrating how current embedded computer technology allows for a new age of affordable state-of-the-art physics simulations. We are facing a revolution in the way physics is performed and taught -- a new paradigm in which computer science is an essential part in the search for a deeper knowledge of our universe.   Javier D. Garcia-Lasheras, Open Science Activist

Fernando Birck greatly enjoys racing simulators—so much so, that he runs Fergotech, a company specialising in racing simulation hardware and tools. Recently Birck shared a really easy way to add a wind simulator to your home setup. The goal is to be able to have a variable amount of wind blowing in your face, getting stronger as you accelerate. He pulled it off pretty well and shared all his code and schematics so you could follow along. As you can see in this video , thanks to his amazingly technical and advanced method of displaying the fan speed (a piece of paper), it seems to be quite effective. As his car accelerates on the screen, the fan smoothly also accelerates to supply more air movement. Yes, he points out that the windshield on his vehicle would stop the wind, but the effect is quite nice anyway. How he's doing it is as follows. First, there's a piece of software installed on the computer that reads the speed of the car in the game. This data is then sent out to an Arduino, which is simply controlling a 12V DC computer fan via PWM (pulse width modulation). Fernando acknowledges that these fans aren't really made to run with PWM, so its life might be shortened, but they're cheap so he's not too concerned at this point in prototyping . The schematic is extremely simple, requiring only a single transistor to handle the 12V power to the fan. He actually points out that if you were to go with a 5V fan, you wouldn't even need a transistor. You can download the Arduino code as well as the client piece of software from his web page if you'd like to try this out for yourself. This kind of addition would be absolutely perfect not only for the kind of racing simulation in the video, but also for virtual reality setups like the occulus rift. Caleb Kraft Chief Community Editor EE Times  

"You never know..." Many years ago, NASA distributed a space trajectory simulation called the N-body Program. It quickly became the standard for lunar and interplanetary studies and enjoyed a well-earned reputation for excellence among its users.   Around 1963, NASA assigned a programmer at Goddard Space Flight Center to rewrite the program using the more structured constructs of Fortran IV. I was among the first to see a copy of the "new, improved" program.   I was stunned. Oh, the program had modules, alright. But the calling lists were completely absent. When he set out to rewrite the program, the new guy had what was, to him, a Good Idea. Instead of the nicely structured arrangement of the original program, he'd take every single variable in the program and give it global scope.   I said, "Um, it appears that you've moved all the variables to COMMON."   "Yes," he acknowledged proudly.   "Why would you do that?" I asked.   He explained,   "You never know when you might want to print something out."   I thought that surely this resoundingly Bad Idea was an anomaly, not one I'd be likely to see again. But I was wrong. It's surprising—also depressing—how often the idea re-emerges. Only a few years ago, I ran across another Fortran simulation, a much-used program written by a highly experienced Ph.D. This guy not only had the same idea, but compounded it with another, even more resoundingly bad one.   Dr. Seuss wrote the book, Too Many Daves . It describes "Mrs. McCave, who had 23 sons, and named them all Dave." It goes on to say:   "And often she wishes that, when they were born, She had named one of them Bodkin Van Horn, And one of them Hoos-Foos. And one of them Snimm. And one of them Hot-Shot. And one Sunny Jim. And one of them Shadrack. And one of them Blinkey. And one of them Stuffy. And one of them Stinkey. Another one Putt-Putt. Another one Moon Face. Another one Marvin O'Gravel Balloon Face. And one of them Ziggy. And one Soggy Muff. One Buffalo Bill. And one Biffalo Buff. And one of them Sneepy. And one Weepy Weed. And one Paris Garters. And one Harris Tweed. And one of them Sir Michael Carmichael Zutt, And one of them Oliver Boliver Butt And one of them Zanzibar Buck-Buck McFate...   But she didn't do it. And now it's too late."   My colleague did something shocking similar, only it wasn't nearly as funny. He must have thought, "Here's a great idea: Let's move all 60,000 of the program's variables into global COMMON, and name them all x ."   This is not a joke. I'm serious. He did exactly that. More precisely, he defined:      Common x(60000)   Then he equated elements of x to the real variables, so that:   x(1) was really BodkinVanHorn , x(2) Hoos_Foos , etc.   To make all of this work, he developed a preprocessor that would allow him to write his code in the usual way, giving the variables names with mnemonic significance. As it read the source file, the preprocessor assigned the user's variables to a unique element of x . Then it wrote a new source file, with every reference to every variable replaced by the equivalent element of x . The preprocessor also wrote a symbol table file, which my pal used later. He built a DOS batch file that moved the appropriate files around.   Why would he jump through all these hoops, just for the chance to name all of his variables dave? I wondered too, so I asked him. He replied:   "You never know when you might want to print something out."   Sigh.   I've thought about this program many times since. Haven't we seen other development tools that take names with mnemonic significance and assign array addresses to them? And don't they also build symbol tables? Of course we have, and they do. They're called assemblers and compilers.   Think about it. IBM's original assembler wasn't called Symbolic Assembler Program (SAP) for nothing. A large part of its job was to replace both instruction mnemoics and user variables with numeric values—opcodes for the mnemonics, RAM addresses for the data variables. Compilers do something similar.   In effect, this guy's preprocessor duplicated the work of the compiler, building its own symbol table and assigning each variable to a slot in the x array. Then his batch file would pass the new, "intermediate" source file to the Fortran compiler, which would do exactly the same thing, assigning every element of x to a location in RAM.   Such a deal.   How could anyone have ever thought this was a Good Idea? It's because it satisfied his need to "print out" any variable in the program. He had written an interactive tool that ran in concert with the simulation program. Using the symbol table his preprocessor had built, he could select a handful (10 or 12, as I recall) of the 60,000 elements and display them in little text boxes. Think the Display block of a Simulink program, and you won't be too far from the idea. If he chose, he could pause the program, single step, and switch the selected variables for new ones.   For a production program, I can't see much value in sitting at my desk, watching the selected outputs spin by like odometer readings, usually too fast to read. I suppose my pal could look for special events, such as the altitude going through zero, but other than that he'd only be able to see, in "real time," the coursest of trends.   Looking back, I think he used the display tool mostly for debugging. In effect, the interactive display tool served as the symbolic debugger that the compiler vendor hadn't provided. Having all the program variables in a single, global array meant that my pal didn't have to depend on the compiler to give him the RAM location of each variable.   But I'm still not convinced that this approach gives much bang for the buck. When I'm debugging, I need to see the exact numeric values of the variables of interest, so I compare them with the values predicted by hand calculations. I can get those values with the primitive mechanisms called debug prints.   When I'm debugging simulations these days, I like to use graphs. A picture is worth a thousand words, and although I can't measure exact values from a graph, I can at least see that things are going in the right direction, and I can see it much better than if I watch display dials spinning by.   But here again, I don't need a special tool to get the graphs. All I need to do is write the selected variables to a file, then use an offline graphing tool to draw the pictures. Matlab can do this, as can Mathcad or Excel.   In the end, this guy's desire to be able to "print out" any variable he chose, and watch it evolve before his eyes as the program ran, completed dominated the design of his program. To achieve this end, he was willing to completely destroy the structural integrity of his program, all the while creating tons of gratuitous complexity, generating two major applications of dubious value, and violating the KISS principle all to heck.   He was very, very proud of his Great Idea and his accomplishments in getting it all to work. I, in contrast, though it was a monumentally Bad Idea, squared. Needless to say, disagreements ensued.   Of all the mistakes one can make, holding onto a bad idea just because it's your bad idea has got to be the worst idea of all.