Flying Through a Turbine Blade

Turbine blades are complicated and delicate pieces of engineering. Each blade has cooling channels that allow air to flow through and exit the porous shell of the blade, maintaining a stable temperature for the assembly. Due to their nature, each turbine blade requires a series of rigorous testing procedures in order to verify their structural integrity. Visual inspection is simple matter but capturing the integral structure is no easy task.

This is where neutron imaging can play a vital role. Neutron imaging is the process of making an image with neutrons. The resulting image is based on the neutron attenuation properties of the imaged object. The resulting images have much in common with industrial X-ray images, but since the image is based on neutron attenuating properties instead of X-ray attenuation properties, some things easily visible with neutron imaging may be very challenging or impossible to see with X-ray imaging techniques

Researchers from Oak Ridge National Laboratory (ORNL)’s Spallation Neutron Source (SNS) have recently utilized neutron imaging to examine the cooling channels and other inner workings of Inconel 718 turbine blades. Watch the video.

Intersection Of two curves in Pure Numpy

Faced the following problem a few months back: Have two sets of curves in Cartesian coordinates, want to find if they intersect and where?

No straight forward solution was available, could find various solution using functions but none available with x, y coordinates.

Solution, found a matlab implementation that did just that, ported it to python. This is a pure python numpy implementation of interaction of two curves.


Example Usage:

Produces the picture at the start of this post. As always the entire code freely available at this github repo.








For many people, the word “algorithm” evokes the arcane and inscrutable machinations of big data, big government, and big business: increasingly part of the infrastructure of the modern world, but hardly a source of practical wisdom or guidance for human affairs. But an algorithm is just a finite sequence of steps used to solve a problem, and algorithms are much broader—and older by far—than the computer. Long before algorithms were ever used by machines, they were used by people.

The word “algorithm” comes from the name of Persian mathematician al-Khwārizmī, author of a ninth-century book of techniques for doing mathematics by hand. (His book was called al-Jabr wa’l-Muqābala—and the “al-jabr” of the title in turn provides the source of our word “algebra.”) The earliest known mathematical algorithms, however, predate even al-Khwārizmī’s work: a four-thousand-year-old Sumerian clay tablet found near Baghdad describes a scheme for long division.

But algorithms are not confined to mathematics alone. When you cook bread from a recipe, you’re following an algorithm. When you knit a sweater from a pattern, you’re following an algorithm. When you put a sharp edge on a piece of flint by executing a precise sequence of strikes with the end of an antler—a key step in making fine stone tools—you’re following an algorithm. Algorithms have been a part of human technology ever since the Stone Age.

From the book Algorithms to live by Brain Christian and Tom Grifiths

The Best Debugging Tool of All

Rob Pike (one of the authors of the Go language) has this to say on debugging…..:

A year or two after I’d joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I’d reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we’d just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, “I know what’s wrong.” He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he’d intuit where the model was wrong or where our code must not be satisfying the model.

Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.

I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinkingwithout looking at the code—is the best debugging tool of all, because it leads to better software.