Saturday, July 30, 2016

Product ≠ Prototype ≠ Technology ≠ Idea

Production note: Some credit to Thunderf00t, for had he not made such a complete pig's breakfast of his analysis of Hyperloop, this "why scientists are bad at engineering" post wouldn't have been written. *


Product ≠ Prototype ≠ Technology ≠ Idea


There are significant differences between an idea ("it would be great to fly from London to New York in four hours, let's use fighter jet technologies to make an airliner") and a marketable product (the Concorde). That's just on the engineering side, without the additional complexity of the business side.


Ideas to technology

An idea is just an organization of thoughts, for example: "if we got a train riding on magnets instead of wheels, we could get rid of friction, wear, and fatigue; then if we put the train in a low pressure tube we could go really fast."

This idea becomes a technology when you get something actually working; this something is called, for obvious reasons, a technology demonstrator. It's used to show that the technology has some potential, and it used to be a minimum requirement for getting funding. (More on that below.)

Linear motor Maglev technology is already available, though maybe not quite up-to-spec, but there are some technological barriers to overcome regarding the tubes and the pods.

Here it's worth noting a common error of reasoning, which is to assume that just because something hasn't been done, it can't be done.
For example, TF's use of a video excerpt showing Brian Cox inside "the largest vacuum chamber in existence." It's the largest because there was never a need for a larger one. It doesn't represent a technology limit. It's not that difficult to make a long tube that can take a big pressure differential (= pipeline), though we currently design this kind of tube for over-pressure because that's what its current use requires.
Many of the "the largest X in existence" limits are determined by economic necessity, not laws of physics. Think about the largest pizza ever made; was its size determined by some limit of the laws of physics?
Sometimes the technology is based on existing science, or co-developed with it, like some of the current work in biotech. Sometimes the technology precedes the science needed to explain it (or at least the attention of the scientists whose expertise is necessary to build the explanation), as was the case of most of the mechanical innovations in the first industrial revolution.

Part of the funding of Hyperloop is an investment in technology development that will have applications beyond the Hyperloop itself ("spillovers"). There's this thingamabob called a "laser" that was imagined as a pew-pew death-ray in sciFi, became reality as a pure Physics experiment, and mostly is used to checkout groceries, read data off of polycarbonate discs, pump bits down fiberoptics, and annoy cats. Oh, some pew-pew, too.

Sometimes licensing or developing the technology in directions other than the originally intended ends up being the most important part of the business.

It's probably worth noting two things at this point:
  • Hyperloop projects haven't finished the technology development phase; that would be indicated by a technology demonstration. Assertions about the final product at this stage are futile.
  • Getting funded by professional investment organizations (with their due diligence and fiduciary obligations) requires passing much stricter scrutiny than that given to crowdsourced projects (like Solar Roadways, the Fontus water bottle, or Triton artificial gills).

Technology to prototype

Once the technologies necessary for implementing the idea exist, they have to be put together and made to work under laboratory conditions or at test-scale, in the form of prototypes.

Here's where the "scientists are bad at engineering" point becomes most pointy.

Prototypes will obey the laws of Physics (and other sciences), since they operate in reality. It may be the case that the laws aren't known yet (as with the first industrial revolution) or that they are being simultaneously developed, but no prototype can violate the laws of Physics.

The problem is that there's a lot of specialized knowledge that goes into engineering. Each small piece of knowledge obeys the laws of Physics, but deriving them from first principles isn't practical. (And real scientists don't dirty their hands with engineering.)
For example, a physicist friend of mine didn't know why the suspenders of a suspension bridge (the vertical cables from the big catenary cable to the bridge deck) sometimes have a thin metal helix around them. When pressed on it he said "it's probably a reinforcement of some kind." I knew that the helix is there to limit aerodynamic flutter, and told him. He said, "oh, of course" and mentioned some interesting facts of turbulent flow.
That's what I mean by "science is the foundation of engineering, but scientists don't learn the body of knowledge of engineering." Most scientists are humble enough to understand that there are things they don't know. My physicist friend didn't assert that the helix was for reinforcement; he actually said, "I don't know," a sentence more people would be wise to use.
For illustration, here's a series of videos about metal shop work (the presenter is a professor, I believe, since he keeps talking about research prototypes, but he's seriously shop-savvy):


Instructive and entertaining videos. A big hat tip to Star Simpson for the link, via Casey Handmer. Such is the serendipitous nature of internet knowledge discovery.

A prototype is a one-off, possibly scaled-down, version of the product reduced to its core elements. It's designed to be operated by specialists under controlled circumstances. It requires constant attention during performance and, conversely, is usually over-instrumented for its final purpose (as a product, that is), since part of its purpose as a prototype is to see which parts of the engineering body of knowledge need to be applied to the technology itself.

Sometimes that extensive instrumenting of prototypes helps discover hitherto unknown issues or phenomena and leads to rethinking of extant technologies and redesign or retrofit of existing products. Historically a good part of the body of knowledge of engineering has evolved by this process.
For example, vortex shedding in aircraft wings was not identified for the first several decades of aviation, even though the physics necessary for it was developed in the late 19th Century. Once the engineering idea of vortex shedding wingtips (or, for older airframes being retrofitted, winglets) entered the body of knowledge, it became universal for new airframe design.
The gulf between a prototype, typically a one-off object made to laboratory-grade specifications that requires an expert to operate, and a final product is almost as big as that between idea and prototype, and a lot of other specialized skills are necessary to bridge that gulf.

Prototype to product

Any engineering product development textbook will identify a lot of things that separate a prototype from a product, but here are a few off the top of my head (and the figure above):
  • Products have to be mass-produced by production facilities, not prototyping shops or laboratories. Figuring out how to mass-produce a product and organizing that production is what's called production engineering. Sometimes that involves the development of specialized production technology, and its prototyping and production, which might involve production engineering of its own, which might require... etc.
  • Products are to be operated by normal people, not expert operators (the drunk Russian truck drivers in the figure were motivated by the Only In Russia twitter account, a terrible sink of productivity). Though it's not entirely accurate, many people believe that Apple's success stems from its ability to deploy technology into final products by making it accessible to average users. That is the field of user experience design.
  • Products also need to be much more resilient, safe, repairable, and maintainable than prototypes. Though, sadly for the practice of engineering  ---and the environment --- the "discard don't repair" mentality has taken hold, so maintainability and repairability aren't priorities in much product design. It being a railway, Hyperloop would have to be designed for both, of course.
There are a lot more. Engineering textbooks exist for a reason, they're not just collections of photos of pretty machines. A lot of knowlege goes into actually making things.

In the case of Hyperloop the product is passenger rail transportation, so there's yet another body of knowledge involved, that of managing railroad operations.

Yes, it sounds exciting, doesn't it?

The whole "how hyperloop will kill you" schtick is nonsensical, since there's no final design to evaluate; but it becomes hilarious when almost all the ways to "kill" the passengers have well-established railroad solutions, namely sectioning (you can isolate sections of a line, and you can have isolation joints in the tube), shunt lines and spurs (to remove a pod from the main tube and access the outside world), instrumentation and control system with appropriate redundancies, and a wealth of other factors that any railroad engineer would be aware of.

I'm not a railroad engineer; these are basic Industrial Management observations.

And then there's deployment…

Anyone with a passing knowledge of operations management or project management could find some possible issues with the infrastructure of Hyperloop, even without knowing the details of the technology. Not impossibilities, issues that might cost money and time.
For example, a number of logistics complications come to mind regarding the construction of the Hyperloop along Route 5, namely: the movement of large-sized tube elements; the use of the Route 5 lanes as part of the construction area (even if most of the staging is done off of the road itself) while it's in use as a public roadway; and let's not forget that California municipalities are among the most anti-change in the world: NIMBY was invented here. Unless you know someone who knows someone who knows…
To have an idea of the scale of the problem created by moving the many elements of the tube, consider what happens when just one large assembly has to move on public roadways:

Building the Hyperloop infrastructure is essentially a large-scale project management problem, and specialists would be involved; I added the example above to show that there are more obvious difficulties than the risk of depressurization; in fact, depressurization isn't much of an issue under good operations management and a well thought-out track.

But pointing out commonsensical logistical difficulties doesn't help with the whole "I am a great scientist, hear me snark" persona.



- - - - - - - - - - Footnote - - - - - - - - - -

* My current view of transportation is that trains and ships are better for freight and cars and airplanes are better for people. By cars I mean autonomous individual vehicles, not necessarily individually owned, chaining for inter-city travel at 200-300 km/h (individual pods self-organizing into convoys), and swarming for autonomous intra-city travel. Most of the current problems with air travel are economic, regulatory, cultural, and managerial, not technological, though I'd like to see supersonic aircraft further along the product development process.

Maybe the Acela corridor would make sense for Hyperloop, though. Particularly since weather in the frozen Winter wasteland and broiling Summer Inferno of the Northeast is more volatile than in California, and the Hyperloop tube would be more resilient than the air shuttles, particularly the small planes. (Boston to NYC late December in a small plane… the horror, the horror.)

But as mentioned above, I believe there are some potential high-value spillovers from the technological developments necessary for Hyperloop, including advances in materials science and production engineering, even if it isn't ever actually built.


A couple of acquaintances asked me why I don't address TF's video (or its follow-up and comments on both YouTube and Reddit) directly. Giving it minimal thought,


But the main reason not to get into online arguments with strangers is basically the same as for not wrestling with a pig: you both get dirty but the pig enjoys it.

Monday, July 25, 2016

A rational case for Solar Roadways projects in organizations


The first time I heard of Solar Roadways my response was "so they are putting solar panels flat on the ground and shaded by cars?" My interlocutor correctly interpreted that as "What a thoroughly stupid idea; no point wasting more time on it." *

There are, however, some good reasons to start a Solar Roadways project in some organizations. Really: good, rational reasons, that you can convince an engineer with. Well, some engineers.

Because of the buzz surrounding Solar Roadways, the project might be funded. And a project funded means a number of ways to fund other projects that would not be funded. For example:

1. An overhead charge is applied to all outside grants and funding. For example, an organization might add a fifty-percent surcharge to any expenditure: spend 1000 on your Solar Roadways funded project, contribute an additional 500 to a general fund (from which the projects that aren't sexy or buzz-worthy can be funded).

2. Fund as much personnel as you can get away with from the Solar Roadways money; of course, funding them doesn't mean that they can't work on other things, and in many organizations it's difficult to tell which project a worker is working on without expending a lot of effort. Given its own problems, it's unlikely that Solar Roadways project funders will be too eager to get a serious audit of expenditures.

3. Fund as much infrastructure, capital investment, and current expenses with Solar Roadways project money. Basically same argument as personnel.

4. Use the buzz of having a Solar Roadways project to attract attention and more funding, to get potential donors to come to fund-raisers, to impress upon the alumni (for universities) how "with it" your institution is. Also, you can play the "Solar Freaking Roadways" clip with the Serenity captain over and over again for the nerdiest of your audience, thus distracting them from any inconvenient engineering professor whose pet project isn't being funded.

Obviously these aren't arguments for Solar Roadways as an energy source, but rather examples of why smart and knowledgeable people go along with nonsense like that.

Great video by Crazy Aussie Dave Jones (EEVBlog) on Solar Roadways:


- - - -

* Some people start going over the details and quibble over the durability of the panels and the visibility of the lights in them or whether they could really melt snow (hint: no, they can't).

That's like arguing about whether the container cross-bracing ties in a Maersk Triple-E would hold if instead of sailing it over water we attached rocket motors to the hull and sent it to orbit and then deorbited it towards the destination port.

(Yes, get it to orbital speed then deorbit, to make it even stupider than a simple --- though also highly unrealistic --- ballistic trajectory.)

The cross-bracing isn't the problem, the concept itself is demented.

Sunday, July 17, 2016

Fun with numbers while walking

Walk in San Francisco, July 16, 2016


Yesterday I went for a walk in San Francisco. To pass the time and keep my mind off the Pokemon Go players making pedestrian traffic in Golden Gate Park hazardous, I decided to do a few approximate calculations about jet engines.

Let's say a jet engine used as a gas generator produces 22 000Lbs (= 10 000 kgf or 100 000 Newton, approximately) of thrust at a nozzle velocity of 720 km/h. How much air is it moving?

To generate thrust, a mass $m$ of air is accelerated from zero to 720 km/h (200 m/s) per second. The thrust is given by $F= ma$, so the flow, or mass/second, is 100 000/200 or 500kg/s. Since air density is about 1g/l at ground level, we need 500 cubic meters of air to go through the engine per second. That's the volume of a large room (20 by 10 meters surface, 2.5 meters ceiling) per second.

Just for fun, how much power is the engine generating? Considering only the kinetic energy imparted to the air (per second, since we're interested in power), we have $1/2 \times 500 \times (200)^2$, or 10  MW. Of course, since the air is very hot, some more power could be recovered using heat exchangers on the power turbine exhaust gases (making it a Brayton-Rankine combined cycle power plant).

Since a gas generator has an efficiency of around 1/3, this turbine will need about 30 megajoule of chemical energy per second entering the combustors, or about one liter of jet fuel every 1.2 seconds. (Looked up jet fuel energy density on my phone while walking --- ain’t living in the future grand? In the past I'd have to look that up in Perry's or Marks'.)

Yes, the numbers are very rough approximations; that's what you do when walking around. I also picked numbers that would be easy to divide in my head. Remember, I had to avoid Pokemon Go players who kept moving in unpredictable patterns in my path:

Walk in San Francisco, July 16, 2016



Edited (about 30 minutes after posting): During my walk I incorrectly computed the power as 1 MW instead of 10 MW, basically because keeping a lot of zeros in your head while avoiding the Pokemaniacs is difficult. The original post used that value; while rereading it after posting, I realized my order-of magnitude error and corrected it and the fuel calculation.

Sunday, July 10, 2016

Two lessons from a simple puzzle

Suppose you're given a set of fifteen integers for a puzzle:

$A = \{ 1, 3, 7, 11, 19, 23, 35, 37, 41, 43, 57, 59, 61, 67, 71\}.$

The puzzle is to add six of these numbers to make up $101$.

Take a moment to try to solve it.

Ready to proceed?

Before we get to the puzzle, one of the people along the chain that brought me this puzzle said that there were "hundreds of combinations."

True. There are indeed fifty "hundred combinations" (plus five), since $\left(15 \atop 6\right) = 5005$.

Apparently a number of children and adults had been searching for the solution and someone thought that writing a search program would be a good idea; they didn't know how to do it, though, since none of them were programmers. Personally, I'd do it in Prolog, since tree searches are so easy to program in it.

Except...

Except that all the numbers in $A$ are odd, as is $101$. And a sum of six odd numbers is necessarily an even number. The problem has no solution.
PROOF: Each number we pick, $n_i \in A$, is odd so it can be written as $n_i = 2 \times k_i +1$ for $k_i$ integer; adding six of them yields 
$2\times (k_1 + k_2 + k_3+ k_4+ k_5+ k_6) + 6$, 
which is even for any $k_i$.
Some of the adults involved were primary school teachers. Who teach basic arithmetic. And apparently not one of them abstracted from the numbers long enough to see that the problem was impossible. I'm told some of them didn't want to believe there was no solution.

So, here are two lessons from this simple puzzle:

1. Understanding beats blind search.

2. Statements of "impossible" require a proof.