<h2 id="isPasted">Some Historical Perspective</h2>The relationship between physical engineering and the programmable computer is as old as the computer itself. The reality is that, for most of us, crunching lots of numbers by hand is frustrating, time-consuming, and error-prone.The British government of the 1820s agreed, opting to fund the early development of Charles Babbage&#39;s difference engines. These were visually striking machines: large mechanical computers, some capable of solving 7th order polynomials, that were intended to dramatically reduce the cost of production of tabulated trigonometric and logarithmic functions &mdash; the kind that were incredibly useful to scientists, engineers and navigators in the immediate aftermath of the Industrial Revolution.Fast forward to 1945, and we see the first glimpse of modernity: IBM&#39;s ENIAC, the world&#39;s first programmable, electronic, general-purpose digital computer. If you&#39;re curious as to what was it designed for, the answer is the computation of artillery and mortar firing tables; a task that involves exactly the kind of Newtonian mechanics calculations that will be familiar to any undergraduate mechanical or aerospace engineering student (see: Mayevski&#39;s <a href="https://books.google.co.uk/books/about/Trait%C3%A9_de_balistique_ext%C3%A9rieure.html?id=jE_zAAAAMAAJ&redir_esc=y" target="_blank">Trait&eacute; de balistique ext&eacute;rierure&nbsp;</a>, or the US Army Ballistic Research Laboratories&#39; <a href="https://asset-pdf.scinapse.io/prod/77299953/77299953.pdf" target="_blank">The Production of Firing Tables for Cannon Artillery</a>).Just a decade or so after ENIAC, IBM drew up its first specifications for a new programming language, The IBM Mathematical Formula Translating System, familiar to many of us as FORTRAN. Developed expressly for science and engineering, FORTRAN is a true titan of the scientific computing world. If you&#39;ve ever fired up MATLAB, analysed a load-case with an <a href="https://en.wikipedia.org/wiki/Finite_element_method" target="_blank">FEA</a> package, or run some new geometry in <a href="https://en.wikipedia.org/wiki/Computational_fluid_dynamics" target="_blank">CFD</a> &mdash; then it&#39;s almost certain that FORTRAN is involved in that stack somewhere, even six or seven decades on.<hr><h2 id="isPasted">Why Software Matters For Hardware</h2>The advantages of using digital computers in the physical engineering disciplines are both marked and multifarious, and I hope somewhat obvious.At a low level, these advantages can be quite straightforward. They include things like providing engineers with the ability to perform large numbers of calculations with little to no risk of human error. Think of something like repeated matrix multiplication, perhaps as part of a kinematics problem. How confident would you be in getting every step of that calculation right, without accidentally picking up a value one row down or one column across from where you intended? Thankfully, with the help of a few lines of FORTRAN, MATLAB, or Python, the computer can perform these calculations on your behalf, perhaps billions of times, without the threat of inconsistency or human error. At least... <a href="https://en.wikipedia.org/wiki/Pentium_FDIV_bug" target="_blank">almost all of the time.</a>At a higher level, however, these advantages are even more pronounced. They are the culmination of decades of work across several disciplines; the output of engineers, scientists and mathematicians who have designed, implemented, and shared computational techniques that address a myriad of challenging problems &mdash; from solving partial differential equations at scale, enabling modern FEA and CFD, through to the development of boundary representation solid modelling techniques that enable modern CAD systems. The convergence of these technologies has revolutionised engineering; accelerating development cycles, reducing the need for physical testing, and helping the world&#39;s engineers improve the quality and performance of everything from ships to spacecraft.As an illustration, think of the draughting process. For many engineering professionals who started their careers prior to the 1990s, draughting work would have still involved a drawing board, pens, and paper, cellulose, and/or linen. In the event of a mistake, the draughtsperson would have had to break out the scalpel or Tipp-Ex to &#39;erase&#39; the error, or issue an entirely separate drawing amendment to be paired with the original documents. With modern CAD systems, minor drawing modifications completed prior to release go completely unnoticed, and subsequent amendments can be as simple as a quick tweak and a brief change order &mdash; no redrawing of anything, no folder of amendments.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg1NTI3MDQ5MjY0LUhXRHJhd2luZ09mZmljZS5qcGciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 300px;" class="fr-fic fr-dib"><figcaption id="isPasted">The Harland &amp; Wolff Drawing Office, Belfast, at some point during the 1960s or 1970s. My father served part of his apprenticeship in this room a decade or two later. Maritime Belfast/National Museums Northern Ireland</figcaption>Better yet, imagine the difference in resource requirement and development cycle times for something like a turbocharger. If every minor tweak to blade or housing geometry requires an entire manufacture, assembly, and balancing routine before the new design makes it to the gas stand, every iteration will fall weeks behind and cost significantly more to explore than its simulation-driven counterpart &mdash; where a design change could make it to CFD in a matter of minutes. This is before we even consider the introduction of something like mathematical optimisation into this loop, where the responsible engineer could define their objective function, their variables, and their constraints, and conceivably let the computer play tunes with the geometry, feed that into the simulation, interrogate the results, then rinse and repeat until it reaches an optimum. Ultimately, well correlated models, <a href="https://en.wikipedia.org/wiki/All_models_are_wrong" id="isPasted" target="_blank">even if wrong</a>, are incredibly useful.<hr><h2 id="isPasted">Why Hardware Matters for Everyone</h2>So computers are wonderful tools, and so are the niche software packages we run on them, but so what? Well, I believe we now find ourselves at a critical point in both the trajectory of engineering as a discipline, and in its utility as a mechanism for improving our lives as a species. We have a lot of *very* active engineering fields right now, with a lot of important problems to address &mdash; and in the end, at some point, somebody has to actually make stuff to make things better.For example, it seems to me that we are standing but a few feet forward of the starting line in a new, privately funded space race. We have seen SpaceX engineers repeatedly achieve nothing short of a triumph of control engineering: reversing a rocket onto a barge in the ocean, opening the door to reuse, and as a result, both dramatically reduced space access costs and dramatically increased launch cadence. We have companies like SpinLaunch working to yield orbital access mechanisms that help escape <a href="https://www.nasa.gov/mission_pages/station/expeditions/expedition30/tryanny.html" target="_blank">the tyranny of the rocket equation&nbsp;</a>.We have a burgeoning paradigm shift in personal transport, with electric cars, scooters, and e-bikes encroaching further and further on the internal combustion engine&#39;s long-established territory.We have additive manufacturing evolving into a serious, cost-competitive manufacturing technique that can achieve geometries beyond the reach of traditional subtractive approaches, and we have generative design technology helping engineers produce mathematically optimised, often organic-looking solutions to pressing design problems. To see the power of these two in concert, just look at <a href="https://www.czinger.com/" target="_blank">Czinger</a> and <a href="https://www.divergent3d.com/" target="_blank">Divergent</a>.And, of course, we have ever more compelling incentives to overhaul the majority of our civilisation&#39;s energy infrastructure, pushing us to diversify the means by which we generate electricity, fostering the development of improved wind, solar, and &mdash; I hope &mdash; nuclear technologies.In short, we&#39;ve got a lot of real-world engineering to tackle, and plenty of hardware to build.<hr><h2 id="isPasted">Software is Eating the World</h2>Ultimately, it strikes me that the way in which we develop the physical systems around us is changing, and not all our tools yet accommodate this.Despite the arrival of an entire range of engineering software systems in the latter part of the last century, these were typically specialised products, often designed to form improved but effectively like-for-like replacements of an existing way of accomplishing a given task, whether that was replacing the draughtsman and his drawing board with a CAD workstation, or replacing a complex, <a href="https://twitter.com/CalumDouglas1/status/1550594001874698246" target="_blank">stiffness-altering oil pressure measurement apparatus&nbsp;</a>around a bearing with a CFD case.As a result, we find ourselves at a point where, as a profession, we&#39;re equipped with some extremely impressive tools; tools that can help us build the shorter iterative loops that are required to yield accelerated system development.However, it feels like we&#39;re still using these revolutionary tools, developing the technology that is critical to our species&#39; future, inside an operational framework that was designed for slide rules, drawing boards, and row after row of draughtsmen packing a tobacco smoke filled drawing office.Our systems are heavily siloed, our teams often fragmented. We struggle to collaborate across teams, sites, and time zones. We have vast and unstructured knowledge bases that are full of effectively undiscoverable data, put beyond the reach of those who don&#39;t know exactly where to look. And we struggle for visibility &mdash; of tasks, responsibilities, upcoming changes, and most importantly, of our data.Even the big players recognise this. Dassault push <a href="https://discover.3ds.com/reduce-non-value-added-work" target="_blank">research</a> that shows engineers spend 34% of their time performing &#39;non-value-added&#39; work; dominated by the amount of time spent just looking for stuff, trawling through network drives and cluttered inboxes. This same research shows that engineers are typically working with outdated information 20% of the time &mdash; imagine a full day a week, every week, for every member of your team, just being thrown away because of bad input data. This pattern has to change.In fact, for newer hardware companies, I think some things have *already* changed. <a href="https://a16z.com/2011/08/20/why-software-is-eating-the-world" target="_blank">Software is eating the world&nbsp;</a>applies not only to the electronic control of fuel injectors and ignition coils, but to the adoption of software-like management practices, with a focus on short design-build-test loops. I may hate the confusing, jargon-heavy nomenclature of &#39;agile&#39; methodology, but there is some method in the madness.<hr><h2 id="isPasted">Better, More Collaborative Software for Engineering Teams</h2>The future that I see is one where we not only have specialised tools for specific parts of the engineering cycle, but we have a central, engineering specific hub; an operating system that ties these things together.We want to see the world&#39;s physical engineering teams build better products faster; to achieve shorter development cycles, to iterate faster, and to better leverage their internal knowledge &mdash; so that they can achieve their goals, whether that&#39;s kinetic launch, faster cars, or greener energy.We think this will be brought about by transforming how hardware teams communicate, collaborate, and manage technical knowledge. That means better, more connected software; software that focuses on resolving the productivity-killing shortfalls in current engineering process. We think hardware teams should have technical communication mechanisms that are fast, painless, and traceable; that allow new hires to find the information they need, without requiring someone else to go rooting through their inbox for half an hour. We think engineers should be able to see what colleagues are working on, how these items are prioritised, and what&#39;s coming next. We think engineers should be able to annotate drawings, share calculations and schematics, and offer opinions on proposed solutions &mdash; all in real-time, wherever they are, with all that data stored and indexed for easy discoverability down the line.&nbsp;Above all, we think engineers should have a single source of truth to work with; a repository of version-controlled design values, simulation outputs, and performance targets &mdash; whether those are scalar values, or n-dimensional maps.In the end, what we want to see is engineering teams moving beyond the pain of e-mail ping-pong with spreadsheets and presentations, to stop scrawling performance differentiating IP over paper drawings that are destined for the shredder, and to start letting the computers handle the busywork.

Betty Jean Jennings and Fran Bilas at the main ENIAC control panel. Moore School of Electrical Engineering. U.S. Army, ARL Technical Library Archives

The recent history of our physical engineering disciplines is intertwined with computing. The future is too. 

The Future of Hardware is... Better Software

Reflow soldering furnace used on mounted PCB

This article provides a detailed overview of the solder reflow process, types of reflow ovens, temperature profiles, solder paste composition and selection, reflow process potential challenges, solutions, inspection, and quality control techniques. 

Solder Reflow: An In-Depth Guide to the Process and Techniques

You may be one of those waiting for the quantum computer, the arrival of which we have been told is imminent for several years. Already at this point, DTU Associate Professor Sven Karlsson begins to look a little strained, because among his partners are the two European companies AQT and IQM which produce and sell quantum computers.&ldquo;It&rsquo;s a common misconception that the quantum computer doesn&rsquo;t exist yet. It does already exist, so it&rsquo;s not something we need to wait for. However, the current quantum computers aren&rsquo;t yet all that large, which obviously limits how complicated the calculations can be, but they exist and are being used,&rdquo; says Sven Karlsson.One example is IBM&rsquo;s quantum computers, which anyone can access via the internet. In addition, there are quantum computers in scientific laboratories, in supercomputer centres, at universities, and so on&mdash;worldwide. These are also among the customers to which AQT and IQM sell their products.<h2>Mostly for experiments</h2>It has not yet been possible to build quantum computers with many quantum bits. Quantum bits are used to process the information in the computer, and a low number of quantum bits therefore limits the complexity of the calculations the quantum computer can perform. Sven Karlsson therefore characterizes the current use as primarily experimental, making it possible to play with and understand the technology.&ldquo;The technical level of the current quantum computers is somewhat similar to the first stage of our current computers. When they first appeared in the 1950s, there were only a limited number of them, and, back then, they couldn&rsquo;t make larger calculations than those any calculator can perform today.&rdquo;However, there are examples of calculations performed using a quantum computer. One of the calculations known to Sven Karlsson was done during the coronavirus pandemic. The Italian football league needed to know how best to schedule the matches so that the different football teams came into contact with each other as little as possible to reduce the risk of infection. Likewise, travel distances for the players had to be limited, as travel by air was banned.&ldquo;A quantum computer is well suited for calculations of this type that will take too long for an ordinary supercomputer. The quantum computer can examine many solutions simultaneously and is therefore more efficient at such calculations than a supercomputer,&rdquo; says Sven Karlsson.<h2>Connects to supercomputers</h2>Sven Karlsson and his colleagues&rsquo; collaboration with AQT and IQM includes developing the hardware and software needed to connect the quantum computer to supercomputers.&ldquo;The future quantum computers will initially largely be connected to the relatively few high-performance computing centres with supercomputers that exist worldwide. The centres have already built an infrastructure with the right competences to operate the quantum computers, and it also makes sense to invest in relation to the existing centres. Today, a quantum computer costs around DKK 150 million, so it&rsquo;s a relatively large investment,&rdquo; says Sven Karlsson.The quantum computer will not replace supercomputers. Instead, it will supplement them and be used for highly specific calculations. Nor will the quantum computer have its own user interface, but must be accessed via the supercomputers.<h2>Standardization</h2>As a result of the current budding production of quantum computers worldwide, large-scale standardization work is being initiated. It includes standards for all the hardware and software parts that make up a quantum computer. The hope is to prevent inexpediencies that we struggle with in other technological areas, such as only being able to use one charger type for our mobile phone.&ldquo;We would like to develop joint standards so that, throughout the world, we have the same understanding and use of the different components that make up a quantum computer. This must be done already at this early stage, so that we don&rsquo;t risk individual countries or parts of the world introducing different standards,&rdquo; says Sven Karlsson.Sven Karlsson leads a group of researchers and practitioners with in-depth experience with and knowledge of quantum computers, who will meet in the coming years to create recognized standards that can be used in future production.

Quantum computers are being manufactured and used. But they cannot yet make the large-scale calculations that are expected to be possible in the future.

The quantum computer exists, but is not all that powerful

<h2 id="isPasted">Quick Wins</h2>We&#39;ll be looking at three items here that should be broadly universal across any Mechanical Engineering function, and should also be applicable to other disciplines. Our objective is to highlight some minor changes in workflow that can offer a significant benefit for your team. Taking these in order...<hr><h2 id="isPasted">1. Drawings: Datum Tables</h2>This is something I started doing several years ago to combat my own frustration with trying to read other people&#39;s drawings, and I was always surprised that it wasn&#39;t a standard practice in any of the design departments I&#39;ve worked in.Picture the scene: one of your colleagues has just finished off the drawings for a new cylinder head, and they pass them to you for peer review. If your brain works anything like mine, the first things you want to check are all the major datum features. However, when a drawing pack runs to six or seven substantial pages, this turns into a less entertaining, more time-consuming, monochrome version of Where&#39;s Wally? &mdash; which isn&#39;t really what we&#39;re after.For me, the fruit doesn&#39;t hang much lower. Work up a table&dagger; that lists datum features in alphabetical order, list their sheet, list their grid reference, then place the table somewhere easy to find on the drawing. Anyone else lifting the drawings will be able to dive right into reading the important bits, without having to scour the thing for ten minutes before they start actually thinking about the task at hand. This can as simple as Table 1.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MjI1NDYxMjE1LVRhYmxlSW1hZ2UucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 766px;" class="fr-fic fr-dib">Table 1 &dagger;If you&#39;re so inclined, I also imagine that it should be possible to implement automatic table assembly with a little bit of code. From memory, when I last explored this with CATIA v5 macros, I couldn&#39;t find any reference to datum objects in the object model documentation.<hr><h2 id="isPasted">2. Excel: Named Ranges</h2>As the sort of engineer whose professional home lies in writing code to analyse, simulate, and control physical systems, this point is much closer to my heart. With a few notable use-case exceptions, such as its easily accessed optimisation tools, I basically hate Excel. I consider it to be like the adjustable spanner of the software world: it might work for the task at hand, but it&#39;s still the wrong tool for just about every job.I believe that Excel inadvertently pushes people to construct terribly organised models and analyses that are often borderline unintelligible, and that building a clean solution in Excel requires the adoption of some very considered practice that you would basically get by accident if you did this work in any one of MATLAB, Python, Julia, Fortran etc. &mdash; the list goes on.More specifically, when I&#39;m forced to unpick somebody else&#39;s Excel-based model or analysis, there is one overwhelmingly common piece of practice that makes me want to tear my hair out: an overflowing formula bar, brimming with unnecessary parentheses and mysterious references to <code>!Sheet2&nbsp;</code>and <code>$C$907</code>. Let&#39;s take a real-world example of how unnecessarily messy this can get, even for relatively simple cases, then we&#39;ll move onto cleaning things up.<h3>The Problem</h3>The simple example case I&#39;m going to give here will be familiar to anyone who&#39;s ever designed an engine, a gas strut, or a (hydro)pneumatic suspension system: computing gas pressure in a cylinder of known volume. We&#39;re going to use the <a href="https://en.wikipedia.org/wiki/Van_der_Waals_equation" target="_blank">Van der Waals equation of state,&nbsp;</a>owing to the fact that the ideal gas law is pretty rubbish at approximating the behaviour we&#39;d typically see in any of these systems. The Van der Waal&#39;s equation of state is given by:<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3MzEzOTIyLUVxMS5wbmciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 766px;" class="fr-fic fr-dib">For simplicity, we&#39;ll take the case for n moles of gas, so this becomes:&nbsp;<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3MzQ0NzcxLUVxMi5wbmciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 766px;" class="fr-fic fr-dib">Where:<ul><li>P denotes pressure.</li><li>V denotes volume.</li><li>n denotes moles of gas.</li><li>R&nbsp;denotes gas constant.</li><li>T denotes gas temperature.</li><li>a denotes Van der Waals constant for intermolecular interaction.</li><li>b denotes Van der Waals constant for real gas molecule volume.</li></ul>In our example scenario, we can pretend that we&#39;re solving for pressure, with all other values known, so we can quickly rearrange as follows:&nbsp;<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3Mzk1NTExLUVxMzQucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 766px;" class="fr-fic fr-dib">Equation shuffling out of the way, let&#39;s pluck some values from the air and get these plugged into a spreadsheet to see what we&#39;re dealing with. The values we&#39;re going with assume a 10cc volume, 20&deg;C, and enough pure nitrogen fill to generate approximately 86barA.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MjIxMjQ5NDg2LVNjcmVlbnNob3QgMjAyMy0wNS0xNiAxMDA5MTYucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 766px;" class="fr-fic fr-dib">The typical quick spreadsheet setup leaves us with something that looks like this:&nbsp;<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3NTAxNDA0LTIyMDUxOS0zUXVpY2tXaW5zLU5vTmFtZWRSYW5nZS5wbmciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 730px;" class="fr-fic fr-dib">In my view, this isn&#39;t the end of the world; all the referenced cells are close by, and I can pick apart the formula quickly &mdash; but you can already see that extension of this sort of pattern to something more complex will start to cause serious headaches. By the time you&#39;re working with something which has parameters spanning sheets and substantially more complex formulas in play, this method is a nightmare.&nbsp;<h3 id="isPasted">The Solution</h3>Thankfully, a better way forward here is entirely quick and painless: <a href="https://support.microsoft.com/en-us/office/define-and-use-names-in-formulas-4d0f13ac-53b7-422e-afd2-abd7ff379c64" target="_blank">named ranges.&nbsp;</a>Named ranges effectively allow us to assign variable names of our choosing to these parameters, while also allowing us to configure the scope of the variables, i.e., whether they are visible only on a given worksheet, or whether they&#39;re global across the workbook.Setting a named range on a single value is as easy as clicking the cell in the top-left corner that currently shows cell address, overwriting it with an appropriate value, and hitting enter. There are plenty of other websites that explain how to use the &#39;Name Manager&#39; tools and get the most out of named range usage, but I&#39;ll just show you how much cleaner things look once you&#39;ve converted cell addresses to named ranges:<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjg0MTY3NTI3MDI2LTIyMDUxOS0zUXVpY2tXaW5zLU5hbWVkUmFuZ2UucG5nIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 766px;" class="fr-fic fr-dib">At least to my mind, this is an immediate and significant improvement. Compared with how it was previously, it is now substantially more straightforward to compare the formula with our target equation above. Any misplaced brackets or indices that might otherwise cause some serious pain to review or debug can now be caught much more readily, and you can move forward with increased confidence that your spready is trustworthy.<hr><h2 id="isPasted">3. Files: Naming Convention</h2>Finally then, the best (and shortest) tip: file naming convention. As far as I&#39;m concerned, there is precisely one correct way to name the sort of files generated by most engineering operations, and that way is as follows:<ul><li><code>YYMMDD-FileName.ext</code></li></ul>For example, the file in our named range scenario might be called something like <code>220519-NamedRangeExample.xlsx</code>.By placing the date at the start of the filename, and by following the <a href="https://en.wikipedia.org/wiki/ISO_8601" target="_blank">ISO8601</a> date component order, lexicographical sorts will yield files in chronological order, irrelevant of when they were copied to the particular directory.Then, by adopting dashes instead of spaces, underscores, or whatever else you might fancy for separation of sections of the file name, you&#39;re making the decision up-front that you simply want to avoid any funnies with respect to how filenames are handled.For example, any files appearing at a web URL will have spaces substituted for <code>%20</code>, which isn&#39;t exactly readable, and underscores can cause issues with both certain platforms and certain indexing systems.&nbsp;

Three straightforward, easy to implement tweaks that can help make life easier for engineers. 

3 Quick Methods Wins for Mechanical Engineering Teams

<a href="https://physics.cornell.edu/eun-ah-kim" target="_blank">Eun-Ah Kim</a>, professor of physics in the College of Arts and Sciences, and Google researchers report the first demonstration of two-dimensional particles, called non-Abelian anyons, that are the key ingredient for realizing topological quantum computing, a promising method of introducing fault resistance to quantum computing.&ldquo;<a href="https://www.nature.com/articles/s41586-023-05954-4" target="_blank">Non-Abelian Braiding of Graph Vertices in a Superconducting Processor</a>&rdquo; published May 11 in Nature. The experiment with Google Quantum AI, first posted to arXiv in October, is built on&nbsp;<a href="https://news.cornell.edu/stories/2023/04/physicists-take-step-toward-fault-tolerant-quantum-computing" target="_blank">the ground-breaking theory</a> also posted to arXiv in October and published in March by Kim and co-author Yuri Lensky, a former postdoctoral researcher in the&nbsp;<a href="https://www.lassp.cornell.edu/" target="_blank">Laboratory of Atomic and Solid State Physics</a>.Theorized about for 40 years but not realized in theory or experiment until 2022 by Kim and collaborators, non-Abelian anyons can, in certain 2D systems, produce a measurable record of their movement when two of them exchange positions. They retain a sort of memory, making it possible to tell when two of them have been exchanged, despite being completely identical.The resulting trail through space-time &ndash; known as a &ldquo;braid&rdquo; &ndash; could protect bits of quantum information by storing them nonlocally and could be used in a platform for protected quantum bits (qubits), Kim said.Google experimentalists used one of their superconducting quantum processors to observe the peculiar behavior of non-Abelian anyons for the first time and demonstrated how this phenomenon could be used to perform quantum computations. Error correction systems based on qubits will be necessary for quantum computing as the field develops.Following the protocol laid out in Kim and Lensky&rsquo;s theoretical work, Google Quantum AI experimentalists created and moved non-Abelian anyons physically on a 2D grid of qubits resembling a checkerboard. To realize non-Abelian anyons, they stretched and squashed the quantum state of qubits laid out on the grid, letting the qubits form more general graphs.Although backed by robust mathematics, Kim said, a simple geometric and creative insight is at the heart of both theory and experiment realizing non-Abelian anyons in the physical world.&ldquo;We needed to introduce a new theoretical framework relying on the mathematics of gauge theories,&rdquo; Kim said, &ldquo;to implement the edge-swinging moves on the device and predict quantum measurement outcomes.&ldquo;It looks simple, but the particles remember the history,&rdquo; Kim said. &ldquo;If you want this to be the technology of the future, you want it to be simple and straightforward.&rdquo;In a series of experiments, the Google researchers observed the behavior of these non-Abelian anyons and how they interacted with the more mundane particles in the setup. Weaving the two types of particles around each other led to bizarre phenomena; particles disappeared, reappeared and shapeshifted from one type to another, Google researchers said.Most importantly, the researchers observed the hallmark behavior of non-Abelian anyons researchers have been seeking for years: Swapping two of them caused a measurable change in the quantum state of their system. Finally, they demonstrated how braiding non-Abelian anyons might be used in quantum computations, creating a well-known quantum entangled state called the Greenberger-Horne-Zeilinger (GHZ) state by braiding several non-Abelian anyons together.Kim, co-chair of Cornell&rsquo;s&nbsp;<a href="https://provost.cornell.edu/academic-initiatives/radical-collaboration/quantum/" target="_blank">Quantum Science and Technology Radical Collaboration</a>&nbsp;initiative, called thiswork a major advance in both condensed matter physics and quantum information science.&ldquo;Our observations represent an important milestone in the study of topological systems, and present a new platform for exploring the rich physics of non-Abelian anyons,&rdquo; Kim said. &ldquo;Moreover, through the future inclusion of error correction, it opens a new path towards fault-tolerant quantum computing.&rdquo;

Researchers report the first demonstration of two-dimensional particles, called non-Abelian anyons, that are the key ingredient for realizing topological quantum computing, a promising method of introducing fault resistance to quantum computing.

Cornell, Google first to detect key to quantum computing future

Build your digital signage solution to manage advertising displays with single-board computers.


Building Cost-Effective Advertising Displays with SBCs

Wafer dicing separates individual integrated circuits or chips from a semiconductor wafer without damaging their delicate structures and circuits. This process is crucial for the production of electronic devices and components used in various industries, and the demand for it has increased with the development of high-performance and smaller electronic devices. Different dicing techniques, such as blade dicing, laser dicing, and plasma dicing, have been developed, and new innovations continue to emerge to address the challenges of complex semiconductor devices.

The Ultimate Guide to Wafer Dicing: Techniques, Challenges, and Innovations

The highly automated and connected vehicles of the future will require powerful computer systems that perform sophisticated calculations and process huge amounts of data.&nbsp;30 partners from industry and research are developing suitable processors, interfaces and system architectures in the CeCaS project.&nbsp;The Karlsruhe Institute of Technology (KIT) is involved with two institutes in the project coordinated by Infineon.&nbsp;The Federal Ministry of Research supports CeCaS within the MANNHEIM initiative.&nbsp;The next generations of vehicles will be increasingly automated and networked in order to move more and more autonomously on the road and gradually relieve drivers.&nbsp;This requires enormous computing power, which only the most powerful computer systems can provide - whether in the vehicles themselves, along the roads or in the higher-level data centers.&nbsp;In addition to internal communication systems connected to the outside world, the vehicles require a central computer.&nbsp;This, in turn, consists of sub-components that perform sophisticated calculations, process huge amounts of data and have to achieve maximum reliability.<h2>KIT and TUM have assumed scientific coordination</h2>&nbsp;In the CeCaS (stands for: CentralCarServer) research project, 30 partners from industry and research are working on the architectures, the software engineering principles and the forms of implementation for future high-performance computers in cars.&nbsp;Infineon Technologies AG is responsible for coordinating the overall project.&nbsp;The KIT with Professor J&uuml;rgen Becker, head of the Institute for Information Processing Technology (ITIV), and Professor J&ouml;rg Henkel, head of the research area Embedded Electronic Systems at the Institute for Technical Informatics (ITEC-CES), as well as the Technical University of Munich ( TUM) with Professor Alois Knoll, Head of the Chair for Robotics, Artificial Intelligence and Real-Time Systems (AIR).&nbsp;&quot;The development of energy- and cost-efficient high-performance computers with full automotive qualifications, which meet the enormous demands on computing power and complexity in a scalable manner, makes a decisive contribution to the future viability and technological sovereignty of the German automotive industry,&quot; says Becker.&nbsp;In CeCaS, automotive supercomputing is created that meets the highest standards of safety and reliability.&nbsp;The project consortium designs processors, interfaces and system architectures.&nbsp;A flexible software environment is tailored to the requirements of the latest algorithms in automobiles - especially, but not only, for the use of artificial intelligence (AI).<h2>Hardware accelerators enable highly effective image processing</h2>In CeCaS, the KIT has taken over the design of novel multi-purpose hardware accelerators for highly effective image processing including the integration of reliable AI in the automobile.&nbsp;The innovative accelerators are connected via high-speed interfaces and integrated into the high-performance processors.&nbsp;The researchers are particularly focusing on the AI components between the sensor nodes and the central computer.&nbsp;In addition, the KIT is working within CeCaS on new development tools for the analysis and compliance with real-time criteria as well as on comprehensive benchmarking software for evaluating the hardware accelerator.&nbsp;&quot;Progress in automotive technology is directly dependent on progress in computer technology and information technology - but above all on the ability of the automotive industry to use modern chip technologies for itself,&quot; explains Becker.&nbsp;&quot;CeCaS supports the German automotive industry in playing a leading role in global competition, even in the digital age.&quot;&nbsp;<h2>About CeCaS</h2>The Federal Ministry of Education and Research (BMBF) is funding CeCaS in its MANNHEIM initiative, named after the birthplace of the automobile, with around 46 million euros.&nbsp;The total project volume is almost 90 million euros.&nbsp;CeCaS is scheduled for three years.The 30 cooperation partners of the MANNHEIM-CeCaS project are: Bosch, Continental Automotive, ZF Friedrichshafen, Hella, AVL Software &amp; Functions, Ambrosys, Infineon Technologies AG (coordination; with Infineon Technologies Dresden GmbH &amp; Co. KG and Infineon Technologies Semiconductor GmbH), core concept , Berlin Nanotest and Design, Missing Link Electronics, Inchron, Gl&uuml;ck Engineering, STTech, Steinbeis ZFW, Swissbit Germany, Karlsruhe Institute of Technology (KIT) with the institutes ITIV and ITEC-CES, FZI Research Center for Information Technology, Technical University of Munich with the chairs AIR , LIS and SEC, Munich University of Applied Sciences, L&uuml;beck University, Chemnitz University of Technology, Fraunhofer ENAS, IMWS, IPMS and IZM.&nbsp;

Computer systems in future highly automated and networked cars must perform sophisticated calculations, process huge amounts of data and achieve maximum reliability. (Icon graphic: © kaptn – stock.adobe.com, KIT)

The CeCaS research project creates processors, interfaces and system architectures for highly automated networked vehicles - KIT develops hardware accelerators and benchmarking software