Computing

Crude Monte Carlo Simulation of Light-Bulb Physics

drorzel — Tue, 26 May 2015 07:38:24 +0000

Crude Monte Carlo Simulation of Light-Bulb Physics

Last week, I did a post for Forbes on the surprisingly complicated physics of a light bulb. Incandescent light bulbs produce a spectrum that's basically blackbody radiation, but if you think about it, that's kind of amazing given that the atoms making up the filament have quantized states, and can absorb and emit only discrete frequencies of light. The transition from the line spectra characteristic of particular atoms to the broad and smooth spectrum of black-body radiation is kind of amazing.

The way you get from the one to the other is through repeated off-resonant scattering. The probability of any particular atom emitting a photon with a wavelength drastically different from its characteristic spectral lines is extremely low, but it can happen. And once it does, those new photons are unlikely to scatter again. So, in a sufficiently large sample of atoms, where an emitted photon is guaranteed to scatter many times on the way out, the light that finally escapes is pushed to longer wavelengths.

That post is based on this old blog post thinking out loud about this stuff, and more specifically on this AJP article that I was pointed to in the comments to that post. The article includes a simple model showing how you can take a bunch of two-level "hydrogen" atoms that absorb and emit in the deep ultraviolet (Lyman-alpha light, in spectroscopic terms) and end up with a black-body spectrum once the sample gets sufficiently optically thick.

It's a very nice paper, and I recommend reading it, but it does have one aspect that might feel like a cheat. The spectra they generate are based on solving the equations Einstein used in his famous 1917 paper on the statistical behavior of light quanta, assuming a particular temperature for the atoms. They do some work to get this in terms of the optical thickness of the sample, but they're always dealing with continuous functions, not discrete probabilistic absorption.

On some level, what you'd really like to see is a Monte Carlo simulation of this sort of thing, where you look at absorption and emission events by individual atoms, and see how that builds up light at lower frequencies. So I wrote one.

Well,sort of. My numerical simulation skills remain pretty rudimentary, but I cobbled together a crude thing in VPython. I put the code on Gist (GlowScript didn't like it), so you can point and laugh:

So, what is this doing? Well, I imagined a collection of "atoms" with a single transition frequency that it likes to absorb or emit, but two lower-frequency modes of possible light. Why three? Because that lets me store the state of the light as a vector object in VPython, saving me from having to figure out how to do arrays with more components. I imagined a single photon of light at the main transition frequency coming into a large array of these atoms, which could absorb it and then re-emit something.

A photon at the main transition frequency is represented by a vector (1,0,0), and is assumed to be absorbed (you could imagine lots of additional atoms that get skipped over). It can then emit a photon of one of three frequencies: the main transition (in which case the state vector goes back to (1,0,0)), a somewhat lower frequency (changing the vector to (0,1,0) with a 1% probability) or a really low frequency (changing the vector to (0,0,1) with a 0.01% probability).

A medium-frequency photon has a 1% chance of being absorbed at the next step, and a low-frequency photon has a 0.01% chance of being absorbed. If either of these get absorbed, they preferentially emit back to the state-- so if the state is (0,0,1) and it gets absorbed, there's a 1% chance of going to (0,1,0) and a 0.01% chance of going to (1,0,0).

Then this process gets repeated a whole bunch of times (ranging from 10 to 1,000,000), and we record the final state. That process then gets repeated 1000 times to give a probability of ending up in each of the three states. All this repetition leads to the following graph:

Results of the crude Monte Carlo simulation in the text.

The graph is a log-log plot (so each division increases by a factor of 10) showing the probability of ending up in each of the photon states-- the strongly absorbing resonant state, the medium-frequency state, and the weakly absorbing low-frequency state-- as a function of the number of absorption steps in the simulation.

A small number of steps corresponds to an optically thin sample-- the initial photon gets absorbed and re-emitted at most 10 times on the way through. As you would expect, this mostly leaves you with light at the resonant frequency, with a low probability of finding either of the other two-- about a 10% chance of the medium-frequency photon, and 0.1% of the low-frequency state. Those are about what you would expect-- with a 1% probability of emitting into the medium state, you you would expect about a 10% chance that this would happen in a set of 10 scattering steps.

As you increase the number of scattering steps, though, the chance of finding the lower frequency increases dramatically. By 200 absorptions, the probability of ending up in the medium state has shot up to about 90%, and after 1,000,000 absorptions there's a 60% chance of ending up in the weakly absorbing low-frequency state. This would presumably increase further for even more steps, but running through the loop a billion times took most of a lecture class period, and I don't have the patience to push it even further.

What's going on here? Well, it's the process described in the AJP paper: there's a very low probability of scattering into an off-resonant state, and once that happens, those photons are unlikely to scatter again. Which means that, over a long cycle of scattering, these highly improbable events inevitably push the state of the light toward the low frequency.

Now, there's a bunch of work to get from here to a black-body state (doing this right would need to start with a Maxwell-Boltzmann distribution of energies corresponding to some temperature, and include a lot more frequencies), but this illustrates the basic idea. Well enough for a blog post, anyway.

------------

(One technical note here: I dithered about what to use for the emission probability when an off-resonant photon scatters; this version of the simulation has it preferentially emit back to the same state that was originally absorbed (so (0,0,1) goes back to (0,0,1) most of the time, and only rarely to (1,0,0)). This is basically mapping a classical sort of frequency response onto the photon picture. The other thing you could do would be to treat it as a true absorption to the imaginary excited state, which would then emit with the same probability as the original state (so when a (0,0,1) state gets absorbed, it usually emits to (1,0,0) and only rarely back to (0,0,1). In that case, you see a similar sort of behavior, but the end result is rough parity between the three states.

(For completeness, that graph looks like this:

Results of the Monte Carlo simulation described in the test, with a different emission probability.

(As I said, I dithered about this for a while; I think the first graph is the right way to do it, and it's easier to see a path from that to the expected result of a black-body spectrum. I am not 100% confident in this, though; there might be some way to get from rough parity to a black-body spectrum through the Maxwell-Boltzmann distribution of energies. Which is why this is a blog post, and not a paper written up to submit to AJP.)

(Though if anybody with genuine computational skills wanted to collaborate on doing a better job of this, I'd be happy to talk about that...)

drorzel Tue, 05/26/2015 - 03:38

Tags

Atoms and Molecules

Computing

education

Optics

Very cool! The whole way through I was thinking I'd really like to see the real blackbody spectrum emerge out of this... maybe we should talk about that collaboration? :-)

Coming from a condensed matter background, it's a bit unexpected to see talk of discrete quantized states in a metallic conductor. The analysis you describe would seem right for me in the context of a very large volume of diffuse tungsten atomic vapour, but in a metallic filament the proximity of nuclei plays havoc on the Bohr model. Instead, we typically describe the electrical and thermal properties of metals in terms of an electron gas. In the basic undergraduate model it's quite successfully modeled in terms of a large collection of non-interacting fermions in a rectangular quantum well.

In that basic model, the Fermi sea fills up to a certain depth based on the electron density. At absolute zero you'd have a sharp boundary below which all energy states are filled, and above which all are empty. At non-zero temperature, we describe a diffuse interface with a width roughly the same as the Boltzmann energy width (1/40 eV at room temperature). Electrons that absorb thermal energy and are promoted into the nominally empty high-energy region are free to drop back into an effective continuum of unoccupied lower-energy states, emitting photons along the way. You don't expect to see sharp emission lines in this context.

Now, I would be interested in finding out whether your model reproduces a black-body curve for the case that it describes, but I maintain that this would be showing us the behaviour of a low-density atomic vapour, and I believe that you'd still see sharp absorption and emission lines due to edge effects at the boundary of the vapour cloud, as not all photons get a chance to pass into the main body of the cloud.

The little bit I remember from astro, concerning the formation of stellar spectral lines. At any given point in frequency and depth inside the atmosphere assume local thermodynamic equilibrium. Then the ratio of emission to absorption would be one, is the radiation field was the Plank distribution at the local temperature. So we can calculate the strength of the emission at a given frequency and beamangle by integrating over the optical depth, emission is delta opacity times the plank function, degraded by the absorption along the line of site (exp(-opacity). A back of the envelope approximation is to just use the Plank distribution at the temperature where the optical depth is unity. So if the bulb filament's temperature doesn't change too much with depth, you would expect a black body spectrum. Near line centers the emission is from very close to the surface. In more transparent frequencies the effective emission depth is greater. If you assume the radiation field at any given depth is near Plankian, then the scattered photons will also be (near) Plankian.

Diversity Is Frustrating: Cartoon Polygon Physics

drorzel — Wed, 07 Jan 2015 09:14:55 +0000

Diversity Is Frustrating: Cartoon Polygon Physics

Back in December, The Parable of the Polygons took social media by storm. It's a simple little demonstration of how relatively small biases can lead to dramatic segregation effects, using cute cartoon polygons. You should go read it, if you haven't already. I'll wait.

This post isn't really about that. I mean, it is, but it's using it for something dramatically different than the intended purpose of the post. You see, I am such a gigantic dork that when I looked at their toy model, the first thing that came to mind was physics.

(And, in fact, I sat on this post topic for the better part of a month, just because it's a serious and worthwhile post, and I didn't want to look like I was just taking the piss. It's been around enough that I hope everybody got the main idea, and I can repurpose it without seeming disrespectful...)

You see, this sort of model with two types of things that live on vertices of a lattice and interact with their neighbors is a very popular toy model in physics. It's close to but not exactly the same as the famous Ising model for spins in a magnet. Having this sort of thing all coded up and ready to play with is pretty cool, so I scrolled down to the "big sandbox" part and started trying to break it.

One of the most interesting phenomena that happens with Ising-type networks of interacting spins is "frustrated magnetism," which lots of people put time into simulating-- I wrote up an experimental demo a few years ago. The idea is that in some configurations, it can be impossible to find a scenario where all the spins can be aligned in such a way as to minimize their energy. The simplest example is a triangular system where each spin wants to point in the opposite direction from its neighbor. You can get two of them in the proper relative orientation, but the third has nowhere to go.

This polygon game isn't exactly the same-- the polygons don't change type, they hop from one site to another, vacant site if too many or too few of their neighbors are the same shape-- but it's similar enough that I wondered whether I could find some conditions where the simulation couldn't find a "happy" final state.

The first order of business was to figure out the rules of the simulation, specifically how many neighbors you count. In the simplest square-lattice Ising model, you only count nearest-neighbor interactions, so each point has four neighbors (one to the left, one to the right, one above, and one below). The next step up is to add "next-nearest neighbors" which would be the four diagonals, or eight "neighbors" for each point.

So, how many neighbors does the polygon parable count? Well, here's a grid with no blank spaces, and polygons who get unhappy if fewer than 12% of their neighbors are the same shape:

Full grid with polygons unhappy if fewer than 12% of their neighbors are like them.

And here's the same grid with the threshold bumped to 13%:

Full grid with polygons unhappy if fewer than 13% of their neighbors are like them.

You can find a couple of yellow triangles in there completely surrounded by blue squares, who go from "happy" to "unhappy" when the threshold is raised. This suggests that the relevant number for calculating percentages is eight neighbors (so one neighbor is 12.5%). This is complicated a bit by the addition of empty space to the model, but for simplicity, I'll talk about everything else as if the shapes have eight neighbors.

So, how do we break the simulation? Well, the way it works is that on each pass one of the "unhappy" shapes will jump to a vacant spot, while "happy" shapes will stay where they are. The simulation runs until this produces a configuration where all the shapes are happy, assuming it can do that. Obviously, the more picky the shapes are, the harder it is to find such a configuration, and at some point the whole thing should break down-- it obviously has to fail if the shapes want more than 87.5% or fewer than 12.5% of their neighbors to be the same as them, but you might expect a practical implementation to break down somewhere before those thresholds.

Now, of course, there's a halting problem issue here-- it's impossible to say whether a particular configuration will necessarily fail to produce a solution, as opposed to just not finding one yet. But as a proxy for this, I decided to measure the time required to settle into a "happy" configuration as a function of the minimum or maximum number of neighbors of the same type. It wouldn't be science without a graph, so:

Time required to find a "happy" configuration for some minimum number of neighbors of the same shape (black points) or some maximum number of neighbors of the same shape (red points).

Because this is random, I ran five trials for each; the error bars on the graph are the standard error of the mean of the five. Though that's understated for the top red point, for reasons I'll get to in a minute.

You can see that the simulation converges very quickly for extreme values-- for a minimum value of one neighbor or a maximum of seven, it's only a second or two. The time increases as the shapes get more demanding, and eventually blows up. I never got it to converge for a minimum number greater than five, or a maximum less than four. In fact, the maximum-of-four point is underestimated-- two of the five trials I did never settled down within the three minutes I allotted.

The diversity-demanding shapes produced some cool patterns, which sort of point to why the problem is so much harder in that case:

Final configuration for shapes demanding no more than half of their neighbors be the same.

You can see that this leads to a set of stripes, so that a typical shape has only two neighbors of the same shape. This pattern is completely self-organized, which is pretty cool.

Now, the model allows you to set both upper and lower limits. This obviously gives an awful lot of parameter space to play with, but because I didn't want to spend infinite time on this, I decided to fix the maximum number at seven neighbors of the same shape (or, if you prefer, demanding at least one neighbor of a different shape), and vary the lower limit. This produced patterns like this:

Pattern for shapes demanding at least two neighbors of the same shape, and at least one of a different shape.

Unfortunately, I was only able to get two data points. Requiring one of each converged within about 3.5 seconds. Requiring two of the same shape and one of the other shape took anywhere from 35 seconds to more than three minutes, and I never got a solution with a minimum of three and maximum of seven to work, even when I left it running while I went and took a nap for an hour and a half.

Other things you could investigate with this include the influence of changing the amount of empty space-- I kept it at 20% for these, because that gave reasonable convergence times. Reducing that to 10% increased the time slightly, and increasing it to 40% reduced the time a bit. I also kept the mix of squares and triangles at 50/50 for all of these tests, but you could obviously complicate things by putting in more of one or the other. Feel free to run your own tests, and send the results to Rhett for grading

So, what's the take-home message, here? Well, pretty much the usual: if you look for it, you can find physics in just about anything. Even the social interactions of imaginary polygons.

drorzel Wed, 01/07/2015 - 04:14

Tags

Quantum Optics: The Game

drorzel — Mon, 05 Jan 2015 09:19:24 +0000

Quantum Optics: The Game

Over on Facebook, my colleague Chris Chabris was talking up a smartphone game from a company he's associated with. Which of course got me thinking "Wait, why don't I have a smartphone game company?" (The Renaissance Weekend is also partly to blame, as I was one of about six people there who didn't have a start-up company of some sort...) Which, in turn, led to the realization that there really ought to be a quantum optics video game. Or maybe a series of games, because you could construct a whole bunch of puzzlers around quantum phenomena:

-- The most basic would be to do something like the mirrors-and-beamsplitters game Lazors, only bring in the wave nature. Have some targets that you need to illuminate, and others that can't see any light, and you have to arrange the position and relative phase of multiple light sources so that interference effects light the right ones and leave the others in the dark.

-- You could make a puzzle/strategy game about the adventures of the Elitzur-Vaidman Bomb Squad. You have some number of packages that may or may not contain light-sensitive bombs, and you need to identify the live bombs without setting them off. Which you do by placing them inside a Mach-Zehnder interferometer, or a pair of weakly coupled cavities, and exploiting the Quantum Zeno Effect. Of course, you can make the probability of success arbitrarily close to one by adjusting the mirror reflectivity appropriately and waiting a bit longer, but for game purposes, you could put a time limit on it, so you have to strategically decide which packages have the highest probability of being bombs, and allocate your measurement time appropriately.

-- Bell's theorem would let you make an "Are these entangled or not?" game: you get to make a series of measurements of the states of two particles, and have to choose the measurement bases appropriately to determine whether they're correlated in a non-local manner. Again, you can add a degree of difficulty by simulating imperfect detectors and restricting the total number of measurements.

-- Quantum cryptography would also seem to allow some game possibilities-- you can play either Alice or Bob as they try to generate secure keys, and determine whether Eve is listening in based on their bit error rates. Or you can play Eve, and run various attacks on Bob and Alice.

Really, the possibilities here are endless. If I didn't have this day job that requires me to, you know, teach classes and stuff, I'd be all over this. Also, I'd need some programming skill. That's kind of a problem, too...

Anyway, game designer types: Call me. If we play our cards right, we could turn these ideas into literally tens of dollars on the app stores...

drorzel Mon, 01/05/2015 - 04:19

Tags

PNAS: Benoit Hamelin, Computer Security Developer

drorzel — Fri, 05 Dec 2014 08:38:17 +0000

PNAS: Benoit Hamelin, Computer Security Developer

I've decided to do a new round of profiles in the Project for Non-Academic Science (acronym deliberately chosen to coincide with a journal), as a way of getting a little more information out there to students studying in STEM fields who will likely end up with jobs off the "standard" academic science track.

The eleventh profile of this round features Benoit Hamelin, a biomedical engineer turned network defense programmer.

1) What is your non-academic job? I am Chief Scientist for Arc4dia, a small company in the computer security and private network defense business. I develop software, lead some other developers and teach the courses we sell.

2) What is your science background? I have completed a B.Sc. and M.Sc. in computer science from the Université de Sherbrooke, after which I have completed a Ph.D. in Biomedical Engineering at École Polytechnique de Montréal. I specialized in large-scale nonlinear numerical optimization and statistical modeling for image reconstruction. My current work is a bit of a "virage" from that specialty -- I have gone back and honed skills developed prior to my (short) research carreer.

3) What led you to this job? I was pursuing a postdoc in medical imaging and, for various reasons, I was not able to build up my set of publications quickly. I was warily contemplating years of post-doc and student-to-position purgatory when Arc4dia's founder, a trusted friend from my days in Sherbrooke, called me to help him start his business. I jumped off and did not look back.

4) What's your work environment like? (Lab bench, field work, office, etc) II have the immense pleasure of working from home. I relish the monastical silence of my basement, where I can write code on a high-end laptop computer, with few distractions.

5) What do you do in a typical day? A typical day is one of a lead developer in a software shop: I plan software projects, delegate some coding tasks and handle some by myself. I'm also the go-to guy when some documentation or technical communication requires writing up.

6) How does your science background help you in your job? Academic research taught me rigor and critical thinking. With software forensics and debugging, in particular, my methods of investigation, cast from good old scientific method, are more efficient and I trust their conclusions more.

7) If a current college student wanted to get a job like yours, how
should they go about it? The studies over the bachelor's degree were interesting, but I could likely have obtained this job with just the skills from that first program. The research experience makes me really good at my current job, though. That kind of skill can be gathered from summer projects in university laboratories, investing oneself in the research process beyond one's immediate tasks and responsibilities.

8) What's the most important thing you learned from science? Read attentively and critically; write clearly and mindfully; think openly and playfully; experiment carefully and rigorously.

9) What advice would you give to young science students trying to plan
their careers? The idealized endgame for the Ph.D., the tenured professorship, has become a lofty goal: hard work and competence will get you somewhere, but it's also largely a matter of contacts, luck and privilege. Plan on getting out of academia, at least as plan B: keep an eye out for job opportunities related to your specialty. If you plan on doing research in a program beyond a bachelor's degree, do it *for its own sake*, if you want badly to do this research. If that need wanes, if doing research no longer tingles you, stop at the soonest sane moment: reject whatever shame you get from dropping out, and whatever skill you've managed to gather in the process can sell. One last bit of advice: while you're in some university or grad school, try and enroll in a few business courses, at least to get the gist of it. Knowing your way around biz administration can make starting up on your own an appealing carreer path, especially if you're keeping track of things people need in your field.

10) (Totally Optional Question) What's the pay like? My salary range is that of an experienced senior software developer, so northwards from 70k CAD.

drorzel Fri, 12/05/2014 - 03:38

Tags

PNAS: P., Web Developer

drorzel — Mon, 24 Nov 2014 10:20:20 +0000

PNAS: P., Web Developer

Fourth in this round is a Union alumn (another nice bonus of this is getting to promote some of my college's former students...) who prefers to remain anonymous, but is a computer engineer turned web developer for a public relations firm.

1) What is your non-academic job? I'm a web developer at a public relations agency. I do a frontend and backend (PHP with my preferred framework being Laravel) web development, and a little native Android stuff.

2) What is your science background? B.S. in Computer Engineering from Union.

3) What led you to this job? Web development was always a hobby. I though I'd do embedded systems forever since I liked Arduinos and it's the kind of programming that Real Programmers™ do. But I was kind of terrible at it. While I was terrible at that I met an agency web developer through colleagues at the embedded systems place. He ended up recommending me at an ad agency, then after some tortuous early-20s career path business, I followed him to our current gig.

4) What's your work environment like? (Lab bench, field work, office, etc) Desk in a large open plan office with wee cubicle walls that stop just short of my eye height.

5) What do you do in a typical day? Get to the office at about 9:15–9:45. What I do from there depends on what kind of place I'm in project-wise: am I developing new features or am I responding to QA fixes? For the former: I'll jump back in where I left off, making incremental commits in git (with the project hosted on bitbucket) and pushing to a staging environment as I go. If I have open QA issues in our issue tracker (we use Jira) I'll just jump on those right away, and generally all of my commit messages will have a ticket name in them.

I have just a few meetings a week: the tech group meets to go over status for an hour, and I've got a 1-1 meeting with the tech group supervisor to assess my workload and plan for upcoming projects.

6) How does your science background help you in your job? Learning how to learn to program was big. Design patterns come up every so often. The meta design pattern of "see if the current problem is either solved or a trivial permutation of a solved problem." A big thing is metrics: speed is the building block of good user experience on the web, and we fortunately have tools to make running an experiment 10M times trivial. So I check my assumptions a decent amount with JSPerf or chrome dev tools to see whether or not some bit of "good programming" is going to make the user experience all terrible on bad hardware

7) If a current college student wanted to get a job like yours, how
should they go about it? Have something to show, I think. If you come into an interview with "my best project was this, I used these technologies in it (backend language/framework, frontend framework, whatever) and my experience with them was positive for these reasons and negative for these reasons" I'd be really excited to work with you. Maybe intimidated. With agency work there's simply no way for you to be an expert in every client's stack, and that's totally OK. Be awesome at one thing and be adaptable in all things.

8) What's the most important thing you learned from science? From CS: an ounce of planning prevents a pound of late night development misery. From science: check your assumptions.

9) What advice would you give to young science students trying to plan
their careers? If I'd followed my career plan I'd be utterly miserable; I was awful at my first job out of college and assumed I was awful at software engineering. Plan, certainly, but do it in pencil, and when good opportunity walks into your life don't waste it.

10) (Totally Optional Question) What's the pay like? $80K

drorzel Mon, 11/24/2014 - 05:20

Tags

PNAS: Fran Poodry, Educational Technology Specialist

drorzel — Fri, 21 Nov 2014 08:59:39 +0000

PNAS: Fran Poodry, Educational Technology Specialist

Third in this round is a physics teacher turned developer of physics education technology at Vernier.

1) What is your non-academic job? Title: Physics Education Technology Specialist

Dept: Tech Support and R&D

Responsibilities:
Support teachers using Vernier sensors, interfaces, and software on phone, email, webinars, and twitter; develop/author experiments; develop new sensors; represent Vernier at conferences; teach workshops in-house, in schools, and at conferences; develop training and support materials; star in product videos.

2) What is your science background? BA, Physics, Swarthmore College;
MSEd, Science Education, Temple University

3) What led you to this job? A long process, explained in a blog post.

4) What's your work environment like? (Lab bench, field work, office, etc)Office cubicle mostly, sometimes lab bench, sometimes classroom, sometimes convention center exhibit hall. I spend a LOT of time staring at a computer screen and recently transitioned to a standing desk.

5) What do you do in a typical day? Wear a phone headset all day long and stand in front of the computer.

Plus, a mix of:
answering phone calls, emails, tweets for assigned time periods
exercise class/go for a run
discussions with colleagues
setting up experiments and collecting data
writing
reviewing material to be published
meetings on various topics from product revision to health and wellness committee

6) How does your science background help you in your job? Well, the job description required at least a bachelors degree in physics, so I needed it to land the job. Plus, since I am talking to teachers every day, I need to determine if the source of their difficulty is the equipment or something else. Sometimes it is a misunderstanding of physics principles. I know what experiments physics teachers are likely to want to do with students at various levels, which helps me develop experiments and products. I also review text for physics content, to make sure we are not publishing things that are incorrect from a physicist point of view. This can be very challenging when developing elementary school materials for complex topics such as electrical power.

7) If a current college student wanted to get a job like yours, how
should they go about it? Well, my job also required a teaching background, so they should get a science degree and teach for a few years at some level (probably middle school or higher). While teaching, they should actively involve themselves with learning about different pedagogies, curricula, and technology. Technology is always changing, so they should make sure to stay aware of the latest technology trends and practice analyzing their utility and effectiveness.

8) What's the most important thing you learned from science? How to analyze data and extract useful information from it.

9) What advice would you give to young science students trying to plan
their careers? Follow your passion! I almost dropped out of the physics major twice, but I was too stubborn and too in love with physics to stop. I dropped out of ballet as a teen in favor of an off-campus math program for gifted students, then dropped out of that math program when I ran into trigonometry, but there was no way I was going to give up physics!

10) (Totally Optional Question) What's the pay like? Better than academia, commensurate with public school HS teaching in a state with higher-than-average teaching salaries, and at this company (one of the top 100 companies in Oregon) the benefits are really sweet. I doubt most places have such good benefits.

drorzel Fri, 11/21/2014 - 03:59

Tags

PNAS: Bob Cross, Naval Computer Scientist

drorzel — Thu, 20 Nov 2014 09:32:39 +0000

PNAS: Bob Cross, Naval Computer Scientist

Second in this round is a computer scientist turned underwater warrior. With bonus video!

1) What is your non-academic job? I am a computer scientist at the Naval Undersea Warfare Center in Newport, RI. I work in the Ranges Department as a part of the Range Software branch. That means I write software for all different kinds of things: underwater tracking, device control, situational awareness displays, image processing, etc. As a fairly senior person, I'm expected to work without supervision, define standards, lead efforts, form teams around me, mentor organically and a bunch of other things. I'm expected to solve whole classes of problems before most people even realize they could happen. I get pretty bossy but I'm able to explain why I'm saying we should do things and how my idea will help you go home on time.

2) What is your science background? My degrees are all in Computer Science (BS-Duke, MS and Ph.D. from Indiana University). I studied a bunch of different kinds of science and math in high school and college. I took Astrophysics as an elective in college and still talk about it: a great class but also the hardest class of all four years.

3) What led you to this job? I love writing code, working with computers and solving hard problems. The Navy has all of those. I also come from a Navy & public service background so this sort of thing is something of a family tradition.

4) What's your work environment like? (Lab bench, field work, office, etc) I work in a cubicle most days. Today, I spent the morning in a classified lab analyzing underwater tracking data coming from AUTEC via our real time data link. Last week, I was in Sydney Australia working on a joint project with our allied partners. So, it kind of depends on which of my many projects is on the agenda.

5) What do you do in a typical day? Again, it depends. I plan to write a lot of code for the rest of this week, cleaning up the quickie work that I did in Australia. I'll also be cleaning issues that have accumulated in a different older code base over time and defining standards and automated tools that will prevent that sort of creeping crud from happening again.

Multiplexed with all that, I'll be working with other teams on long-term project planning. A lot of the projects that we're working on are focused on getting extra value out of existing assets: can we use something that we already have in a novel way that gets us a new capability without spending more money (critical in today's budget environment!)?

6) How does your science background help you in your job? Computer science education is critically important for truly effective software engineering. Math is everywhere: you can't know enough math. Physics is likewise all over the place and there's a unstated expectation that "of course you know how to calculate terminal velocity / sound pressure level / etc."

7) If a current college student wanted to get a job like yours, how
should they go about it? https://www.usajobs.gov/

NUWCDIVNPT (where I work) is currently hiring entry-level scientists and engineers. We also have summer internship programs: all three of my previous interns have gone on to graduate school.

8) What's the most important thing you learned from science? That events occur for a reason: there is a cause for every effect. I find that to be quite comforting. The universe is a pretty uncaring place overall but it is at least fair: the same rules apply to everyone and everything, all the time.

9) What advice would you give to young science students trying to plan
their careers? Long term: your eventual employment might be only loosely connected to your current science interests. This isn't necessarily a bad thing: the more you learn, the more you want to learn. This will pull you into new directions. Your employer might also pay you to become an expert in something completely unexpected: embrace the opportunity!

Short term: you must learn to speak in public. Give presentations to large groups at every opportunity. Push through the fear of public speaking (hint: when you get nervous, speak loudly and slowly). The ability to present your case / argue your position / persuade a grant committee will have concrete positive effects on your career.

10) (Totally Optional Question) What's the pay like? It's a matter of public record and it's not bad.

My command uses a banded pay scale that merges adjacent GS grades. I'm in the ND-05 band: that includes GS-14 to GS-15. I'm considered a "high grade": it's hard work to get an ND-05. Many people top out at ND-04 (which goes up to the top of the GS-13).

drorzel Thu, 11/20/2014 - 04:32

Tags

PNAS: W. F., Patent Lawyer

drorzel — Wed, 19 Nov 2014 11:40:12 +0000

PNAS: W. F., Patent Lawyer

First up in this round is a CS major turned IP lawyer.

1) What is your non-academic job? I am an intellectual property attorney. I work for a "boutique" law firm, which means it specializes in one area of law (that being intellectual property, naturally). I work on all areas of IP, principally patent, copyright, and trademark (but especially patents).

In 2014, I was seconded to Japan for a major client of my firm, a Japanese corporation that you've heard of (to say the least) but that I won't name. I do the same job, but I work directly and solely for this corporation.

2) What is your science background? I have a Bachelor's of Science in Engineering from the University of Pennsylvania in Computer Science Engineering. (I'm also a member of the Patent Bar, which is relevant because that requires a level of scientific background usually seen through coursework.)

3) What led you to this job? When I started college, I figured I was going to get my programming degree and go off and work at Google or somewhere and write code for a living. But while I was there I took several courses in the History and Sociology of Science department (which I ended up minoring in) on the relationship between science/technology and society/culture, including History of Western Technology, Science and Literature ("science fiction as the mythology of the modern scientific/technological society"), and Cyberculture.

I realized that I was still fascinated by technology and computers, but not for their own sake: I wanted to be involved in how they fit into the world. And in that interplay, I found the issues of law. Cyberlaw, copyright law in the digital era, constitutional questions applied to the Internet, and the underlying questions of creativity, technology, and culture...it grabbed me and didn't let go.

I graduated and spent two years working as a programmer, more to get some "real life" experience before going back to school than anything else, then went to law school. From there it was straightforward interviewing through my school.

I got my secondment because it was a preexisting program at my firm, but I made a point of asking about it a lot.

4) What's your work environment like? (Lab bench, field work, office, etc) I work in an office. In New York I have my own office with a door that closes and everything, and my firm is business formal four days a week with casual Fridays; in Japan I'm in a big open-plan office (which is apparently the norm here) and business casual every day unless we're having a big meeting and want to look the part.

5) What do you do in a typical day? Most of my job is reading and writing. On a typical day I'll research case law to write legal opinions or legal arguments, review patents for legal analysis, consult with a client about their case, maybe do some filing of documents with the relevant court, or review documents we received as part of our cases (the dreaded "doc review").

In Japan, it's pretty much the same, but with an emphasis on reviewing contracts for proper English usage, and meeting with American adversaries (companies we're involved in disputes with) to be involved in negotiation, including translation--of gestures and tact as much as language. I spend a good amount of time explaining to my Japanese coworkers what I, as an American, read from adversaries' body language or tone of voice.

6) How does your science background help you in your job? Most important for me is that I review patents, and I really do need a science background for that. (As I said above, a science background is actually required to be on the Patent Bar, which just means I'm allowed to file patent applications for other people.) Patents will frequently have schematics or specialized terms, and a lot of patent law is based around the perspective of a "person having ordinary skill in the art," so it's pretty important to speak the language or technology and science.

7) If a current college student wanted to get a job like yours, how
should they go about it? They shouldn't.

Just kidding. That's the standard answer to people college students who want to be lawyers, though. Google around and you can find plenty on that point. But if you've actually decided that you want to be an IP lawyer, get a grounding in the law (I took a "law 101" course as an undergrad), and choose your law school carefully.

IP is kind of an odd duck in the law; unlike a lot of other fields it's more specialized (hence there are a lot more boutique firms like mine), so if you're in this, you'll be in for the long haul. You can't really decide to chuck it and switch to bankruptcy. (I mean, you can, but it's a bit harder.)

On the other hand, I do entertain fantasies of going in-house at places like Google (and it's possible).

Some things don't change.

8) What's the most important thing you learned from science? Logic. During my 1L course on statutory interpretation, I seemed to be the only person in the room who understood the difference between "and" and "or" when used in a list. (It's pretty important because if a law, especially something like a criminal law, says "A, B, _and_ C," that's really different from "A, B, _or_ C." And the law is full of multi-part tests.)

Relatedly, my experience with computer code makes legal code easier to understand. Jokes on the names aside, the two forms of writing have a lot more in common with each other than either does with fiction.

And like I said, the language of science is pretty damn important. Especially when you're dealing with engineers giving depositions.

9) What advice would you give to young science students trying to plan
their careers? Never be afraid to reevaluate why you want to do something. I thought I wanted to be a programmer, but it wasn't writing code that I really cared about.

10) (Totally Optional Question) What's the pay like? I'm a lawyer, in a traditional law firm to boot. More has been written about legal salaries than about why college students shouldn't want to be lawyers. All I'll say is, I'm on the lowish side of the ridiculous salaries common to my profession.

drorzel Wed, 11/19/2014 - 06:40

Tags

Why Fortran Lives

catdynamics — Mon, 21 Apr 2014 14:07:24 +0000

Why Fortran Lives

Julia is a nifty new language being developed at MIT

I stole this plot from github, it shows Julia's current performance on some standard benchmarks compared to a number of favourite tools like Python, Java and R. Normalized to optimized C code.

And, there, in a single plot, is why Real Programmers still use Fortran...!

catdynamics Mon, 04/21/2014 - 10:07

Tags

A nitpick: Javascript != Java

fair point - compiled java ought to do factor of few better on some benchmarks than the script does

The author of Mathematical Recipes once said to me "I don't know what the future computer programming language for science will be but it will be called Fortran"

The Javascript V8 engine (the one built into Google's Chrome browser) can be significantly faster than Java depending on the circumstances. (There is lots of debate about that to be found on the web.) Thank you for the heads up about Julia.

Actually, the benchmark says that Fortran is merely average.

All the numbers, with the exception of the Fibonacci series cluster around the C values. And since the Fibonacci implementation is purely recursive (and, honestly, pretty bad), it might well be that the compiler just makes the smarter decision about which path to follow by default here.

Second, the benchmark tests the performance of low-level features to show that Julia performs well here, in contrast to scripting languages. It has no further validity.

As an example, the Fibonacci benchmark is implemented recursively, which is something you would never do in a scripting language because function calls are really expensive there. Not surprisingly, it gives about the worst speeds in all scripting languages.

In contrast, if you look e.g. at the Matlab values, those benchmarks that measure real performance of the underlying system, or contain loops that can be easily vectorized (pi_sum, mat_mult) are about the C level. Which tells you that Fortran does not really excel, but is about average as one would expect intuitively.

I will restrain myself and not continue bashing Fortran for the lack of good libraries and stuff, but your claim is simply wrong. The benchmark by design does not show that Fortran is superior.

The reason is pretty simple. If offers c-like times (order of magnitude) and coding it's simpler than Cs as long as your problem lacks complicated derived data types, and is restricted to array operations. Many problems solved today fit those restrictions.

Julia is not suited for HPC over a MPI supercomputer, as far as I can tell, at least, in it's current state of development.

So my question is, Why it should not?

Hmm: the benchmarks say that there is a four order of magnitude variation in the performance of compilers for widely used and popular languages for simple core computational tasks.
Despite the fact that commodity computing is now a near monoculture and most of these compilers as a first approximation cross-compile into something like C object code and run under *nix kernel running on a very predictable CPU

I would have expected the compilers to all cluster near 1 for these benchmarks, with NONE outperforming C and some underperforming by a factor of few depending primarily on how dynamic the structure was.

Fortran is average in the sense that it is the extreme outlier, that is the ONLY one of these languages to significantly outperform C on any of these computational tasks, and only underperforms significantly on the one obvious one. Despite the fact that this is the GCC fortran compiler!

This tells me that my naive prejudice is right: which is that Fortran is still optimal for certain arithmetic intensive scientific computing tasks; and is still mediocre at I/O and suboptimal at bit level manipulation of strings. As always.

It also tells me that most of the newer languages are still unsuitable for CPU intensive scientific computing, by orders of magnitude, even if they are convenient for low intensity computing where manhours are more valuable than CPU hours.

After 50 years, there is still a large class of numerical computing where the only way to beat Fortran is to hand optimize code at the machine level.

I have survived far too many computational theological skirmishes to make any claims of superiority of anything over anything else (other than Mac vs PC natch, of *nix vs M$, or TeX vs anything or...). Choose the tool that suits the task. This tells me what Fortran is (still) suitable for. For me.

Julia is looking like an interesting candidate for a viable future computer language candidate and possible Python replacement - I am somewhat underwhelmed by Python. Julia is in release 0.2 I believe - we'll see how it look as release 0.9

As for libraries - I would argue that the main reason Fortran survives is not in fact the speedup, but the legacy code - especially the large libraries of verified and validated subroutines of scientific and mathematical tools available out there, but also some open source ready-to-run out of the box code that is useful. In fact a fair amount of the useful scientific C code is either translated from legacy Fortran, or is C main wrappers around thinly disguised Fortran subroutines -but I digress...

For whatever mostly accidental legacy reasons the defacto rules for Fortran allow compilers to make pro-optimization choices. In C it is hard to disambiguate memory pointers: "if I have two statements x=y followed by say a=b, can I safely change the order I do them in? You have to know if the address spaces of any of these numbers overlap. Thats usually quaranteed in Fortran". Also the Intel Fortran compiler does a pretty good job, modern X-86 processors have vectorlike units, which can perform several times faster, but the compiler has to be able to figure out that loops -or loop fragments can safely vectorize. Also alignment of stuff in memory is very important, loads and stores that span word or cache line boundaries are inefficient. Again, with Fortran you can have common blocks aligned properly (and the compiler is aware of this).

A few years back, I played some bit crunching games, stuff like the popcount (number of one bits), in an array of 1000 64bit words, and Fortran clobbered C!

Well, I'd actually claim that Fortran rules are quite deliberately chosen to make certain optimizations more optimal at the expense of a less elegant and flexible language (barring illegal deliberate overrides of common blocks and other fund games). C's choice of how to handle pointers makes optimization harder for many tasks - it would be easy to change this, or have compile options which made trade-offs, but these are not made because the maximizing numerical throughput is not the overriding optimization concern for C design. If it were, it'd be F95. ;-)

If you really need to do cpu limited bit operations and C is not fast enough then go to machine level...

I will purely restrict this post to the benchmark and grind my teeth not to argue further against Fortran.

The benchmark is set up on purpose to test the speed of low-level language features, such as function calls, for loops etc. The test cases are heavily geared towards that without even the simplest optimizations. This has three consequences:

1. _Any_ reasonably low-level language with a decent compiler will produce approximately the same speed. So the speed of Fortran, C, C++, even Basic, Pascal, Java etc. will be about the same. Go, if I recall correctly, simply does not have a good compiler.

2. All interpreted languages (all examples except Go and Julia) have made deliberate tradeoffs. They are slower in handling low-level features like function calls, but more flexible/easy to use. That is why you do not program in an interpreted language like in a low-level language; instead you use functions provided by the respective standard library (this is coding 101). Consequently, it is completely unsurprising that the interpreted languages are slower.

3. Commenting on how bad the other languages (except Fortran and Julia) are is pointless, these languages have been deliberately misused in this benchmark. When they have been used correctly (like the multiplication case for Matlab and Mathematica), they give similar performance to low-level languages, which again is not surprising.

Another post, because there are two major errors in the followup posts:

1. C is faster than Fortran. Iff you know how to optimize. The simple reason is that C allows more fine-tuning. For example, the pointer problem mentioned by Omega can be overridden by a keyword that tells the compiler "The values at this pointer position should not be changed by other variables", leading to Fortran-like output. As an example, the linear algebra library that they used in the benchmark is written largely in C.

2. Fortran is not "safe". In fact, the pointer problem mentioned by Omega can be easily reproduced in Fortran; just pass two overlapping pointers (sub-arrays of an array) to a unction. The Fortran compiler will by default produce incorrect, but fast code, while the C compiler produces by default (without keywords) correct, slower code.

Choose the tool that suits the task.

This cannot be emphasized enough.

I frequently use C because it has certain features I find desirable. Specifically, it lets you work closely with the operating system (no surprise, since Unix was written in C). I like to have access to command line arguments, for instance. C is not the only way to do this (you can do a Bourne shell script instead), but it is one of the more efficient ways to do it. Fortran is specifically designed for numerical computation, so of course it is frequently used for that purpose. In many cases the best solution is to write a C wrapper to handle the I/O and OS level stuff, and call Fortran functions/subroutines to handle the actual mathematical details. As Steinn notes, there are many legacy libraries in Fortran, which allow coders to avoid reinventing wheels.

Somebody upthread mentioned Numerical Recipes. I have the second edition C version of that book. It is occasionally useful as a reference for basic numerical techniques, but it is also an object lesson in how not to write C code. Comments and interior spaces are wonderful things which vastly improve code readability. And speaking of comments: Their purpose is not so much to help other people figure out what the hell you were thinking when you wrote that piece of code, as to remind you what the hell you were thinking when you return to that code after three weeks or three months or three years.

In my past life in supercomputing I came to realize that in the STEM field, many endevours have pushed as far as the current computing technology will allow. This means there is often an opportunity available for those who can find some clever mechanism to push the limits of what can be computed.

Today that has often been translated into the attempt to use graphical processors to accelerate some computing tasks. But the basic X-86 CPUs contain some pretty impressive compute engines derived from the SSE technology. In the near future these will be able to process 512bits of information with a single instruction on a single core, and some chips may have 16cores. If you can pack the data bitwise and work on it in a bit parallel fashion, this means that you have access to several thousand bit operations per machine cycle per chip, i.e. many trillions of bit operations per second per chip. This can enable tremendous capabilities in certain situations. Fortran does allow you nearly full access to these capabilities.

Minor nit: javascript and java are completely different language. It's just a coincidence that they have similar names.

Yay! Just what we need. Another new programming language.

Since my last post was maybe a bit too righteous, and another day has passed, I can maybe summarize my arguments better.

I agree with Eric Lund, I am well aware that you can also write even good code in Fortran. I am aware that STEM people are often bad coders, which cause a good part of Fortrans reputation. And I have seen that these same people can write horrific C++ code.

What bothered me in the original post was the incorrect representation of the benchmark results, and the self-righteousness "Fortran is best". "Real programmers" outside a very narrow STEM field do not use Fortran, because for many applications it actually sucks (and even in STEM there are many applications are not only number crunching but also writing a big program that you can maintain, test and modify).

The real competition is not between Fortran and, say, JavaScript in a benchmark testing recursion, but between, say Fortran code and well-designed, highly expressive numerical libraries in other languages. I mostly code in C++, so the examples that I have come across are boost::odeint, or thrust, which are worlds beyond what I could imagine in Fortran.

Fortran is currently being used to get spacecraft to orbit, and will be for a long time to come (I speak with first hand knowledge).

Fortran's benchmarks are like Beckenbauer entering open trials for the German team for this summer's World Cup and not only winning the sweeper slot, but being competitive for both winger and striker and only just losing out for the goalie...

It is one thing knowing that it ought still be good for something (I actually do think Fortran would make a great coach, at least for the English team) and definitely not be the best at others (eg never make goalie for the Dutch team) but for it to be broadly competitive at all is amusing, and so apparently think the intertubes.

Though apparently the most interesting thing on the intertubes is someone lazily and hastily confusing one early 90s web oriented structured object oriented code loosely based on C, for another entirely different similarly named code structured object oriented code loosely based on C, but using a slightly different syntax and structure, but very different target audience...
java/mocha/whateva

Must remember that if I ever want to pump up traffic.

Since you're not taking this too seriously, here are some funny answers:
http://stackoverflow.com/questions/245062/whats-the-difference-between-…

If you want to pump up traffic, drop tantalizing hints about upcoming extrasolar planet announcements and rhapsodize about where the US Navy has placed its carriers. Lets go back to the good old days!

Oh, I figured out how to pump up traffic a few years ago and doing so felt too slimy to actually do it. I'd have to go too far downmarket for my tastes, and go to gee-wiz on the hype. Also too busy with my real jobs.

I actually have a real problem with blogging about sciency bits, which is that I am now an ApJ Science Editor, and I Must Not, in general, do stuff like leak interesting hints about extrasolar planets - I'm handling a significant fraction of the papers.
We haven't decided how to handle this yet, since I think the ApJ vaguely does think it might like to join the modern world in terms of communicating exciting sciency bits.

I don't think the US Navy is crazy enough to cross the Bosphorus with a carrier group...

On the other hand that might be better than me feeling like I must keep the blog alive by posting another free verse.

OTOH - Real programmers still use C for benchmark baselines.

I don’t think the US Navy is crazy enough to cross the Bosphorus with a carrier group…

Why would they need to? If they were inclined to stir up trouble over the Russia/Ukraine situation, or even be on hand as a deterrent, they could park that carrier group just south of the Dardanelles, or use NATO bases in Poland and other nearby countries. Not that I think the CinC is eager to stir up trouble, although some of the fire-breathers in the opposition are. Besides which, is the Turkish government crazy enough to allow a US carrier group to transit the Bosphorus?

Poland to Crimea/Eastern Ukraine is a long way to go... but no, there is no way Turkey would permit hostile passage of the Bosphorus, however amusing it'd be for a demonstration off Sevastopol...
I personally favour the theory that Crimea has formally reverted to Turkey now that it has separated from the Ukraine ;-)

Ulf@13: " Fortran is not “safe”. In fact, the pointer problem mentioned by Omega can be easily reproduced in Fortran; just pass two overlapping pointers (sub-arrays of an array) to a unction. The Fortran compiler will by default produce incorrect, but fast code, while the C compiler produces by default (without keywords) correct, slower code."
Sorry, but this is wrong. The Fortran language specification says that you are not allowed to do that. Therefore the compiler does not produce incorrect code, it's the programmer who broke the rules, not the user.
Language standards are a contract that cuts both ways. They are not just restrictions on the compiler, but also on the user.

The Sound of Simulated Bombs

drorzel — Thu, 13 Mar 2014 08:19:43 +0000

The Sound of Simulated Bombs

So, last week I idly wondered about the canonical falling-bomb whistle. The was originally intended to be a very short post just asking the question, but I got caught up in thinking about it, and it ended up being more substantial. And leaving room for further investigation in the form of, you guessed it, VPython simulations.

This one isn't terribly visual, so you don't get screen shots, just a link to the code at Gist. It's a simulation of a falling bomb, with air resistance, tracking the velocity as a function of time. Then it calculates a "Doppler shift" using the velocity as a fraction of the speed of sound for an observer standing on the point of impact, and another some distance away.

Putting this together required some guesstimated numbers, so I gave the bomb a mass of 1000kg, a radius of 30cm (which don't seem wildly unrealistic from this page about WWII munitions) and dropped it from a height of 6000 m (around 20,000 ft, which is a reasonable value for high-altitude WWII bombing; I'm using WWII as a reference point because the whistling-bomb noise dates back at least that far).

What I wanted to see was how significant the shift would be for somewhat realistic conditions, and whether this could make a sound like the canonical falling-bomb whistle, decreasing in pitch. Looking at the physics, as in the diagram above, it ought to-- the falling bomb starts out coming toward the observer, shifting up in pitch, but an observer off to the side should see the velocity become more tangential as it drops, eventually coming back to whatever the default whistle frequency is. The question I wasn't sure about is how significant this change in pitch could be.

So, what does the simulation show? Well, the primary output is this graph:

Doppler shift due to a 1000kg falling bomb with a 30cm radius.

There are three curves here. The black points show the shift as seen by an unlucky person at the impact point, and it increases through the whole fall. In the absence of air resistance, this would be a straight line, but with air resistance, there's a little bit of curvature. The red points are for an observer who starts out 6000m away (the same distance as the height the bomb drops from), and first increases in pitch, then decreases. The green points are for an observer 3000m away from the impact point, and the shift is more dramatic, because the bomb has a velocity toward them for longer than in the more distant case.

The shift here is fairly substantial, because the bomb is falling very fast. It also does exactly the sort of thing you expect from looking at the velocity components above: first goes up, then down. So, you could get a falling-bomb whistle with the canonical decreasing pitch provided you're standing off to the side of the impact point. The closer you get to the impact point, the more dramatic the shift, both in terms of amplitude and speed-- if you make the distance to the observer just 600m, the shift goes from 70% above the original pitch to zero in just six seconds (not plotted here).

Now, this obviously presumes a particular size and shape, and thus an effect of air resistance. So, if we change the size, what happens? I tried doubling the radius for the same mass, and you can see what that does here:

The Doppler shift of a falling bomb for two different sizes, showing the effect of air resistance.

A bigger radius means more air resistance, and thus a slower terminal speed (this almost reaches terminal speed), which in turn means that it takes longer to hit, and has a smaller peak shift. You still get the reversal in pitch, though.

The other question that came to mind back when I was thinking about this was whether the decreasing-pitch whistle was a result of imagining things from the perspective of the person dropping the bombs rather than the person being bombed. I've seen clips of bombs being dropped where they seem to whistle as they leave the plane, but that might've been a dubbed-in effect, for all I know.

Anyway, just for fun, I thought it would be interesting to compare the decreasing-pitch whistle of bombs observed from a safe distance to that of a bomb dropped directly from a plane, which led to this graph:

Doppler shift of a falling bomb during the decreasing-pitch phase compared to the shift heard by the person who dropped it.

The Doppler shift just depends on the velocity, which is initially increasing at a steady rate due to the acceleration of gravity, so we expect the points for the pilot's perspective to fall on a straight line, and they do. The others are decidedly non-linear, but again, we expect that, because it should go like the cosine of the angle to the line of sight.

So, does this accurately reproduce the falling-bomb whistle? I had hoped to make Mathematica reproduce the sound pattern here, but it's very picky about which users it's friends with, and life is just too short to keep wrestling with that program. We can turn to some eyewitness testimony, though, in the form of a comment that must have a good story behind it, left by Time Eisele:

I can vouch for the ‘descending whistle’ sound in the case of falling bowling balls, at least. From an estimated peak altitude of about 1500 feet, and standing approximately 1000 feet away from the ultimate impact point, the sequence goes:

- Whistle starts by getting gradually louder at a more or less constant pitch.

- In the last few seconds of the drop, the pitch drops noticeably, all the way down to the ground.

And, you know, that looks pretty much like what we see in this graph: a slow decrease from the peak at first, that rapidly speeds up toward the end of the drop. So, I think this works out nicely. I'd like to know why Tim was being bombarded with bowling balls, though...

drorzel Thu, 03/13/2014 - 04:19

Tags

I assume you dropped with no initial lateral velocity (and no velocity for the pilot). For folks on the ground, that would average out in people's perceptions of the sound going up or down, but a pilot is always going to be flying away from the bomb, which isn't being propelled laterally after it's released.

Also, I wonder if we can make some estimate of the volume of the sound. It might be the case that the Doppler effect increase in frequency comes while the bomb is too far away to be audible. There's also the possibility that the falling bomb doesn't actually produce a sound until it's near terminal velocity - was there any resolution on the origin of the sound?

Well, you see, there were a bunch of us who had a bunch of bowling balls, and a heavy-walled pipe just a bit bigger than a bowling ball, and some gunpowder, and some wadding, and a remote igniter, and a vast expanse of uninhabited sand at an Undisclosed Location(tm), and so was born an event we like to call "Bowling for Altitude". So we dug a hole and buried the pipe so that the top end was just flush with the ground (both to hold it steady, and to stop any fragments in case of explosion), and angled just a few degrees *away* from where we planned to be standing. After a bit of practice we were getting "bang to thump" times of about 20 seconds or so, which, neglecting air resistance, comes to a peak altitude of around 1500 feet. I think the record hang time might have been as much as 30 seconds

The bowling ball has an interesting warble in the sound as it descends, probably because of the wind whistling in the fingerholes as the ball spins. It also made an odd crater that was about three feet across, but only an inch or so deep.

I can't help but think that if you're going to drop a metric ton on somebody, including explosives seems almost superfluous.

From your first figure it looks like the bomb was dropped from a balloon and not a fast flying airplane. Shouldn´t the bomb start with a horizontal speed of around 100 m/s if it falls from a WWII bomber?

@Grant Goodyear Only if you actually hit your target dead on and that target isn't particularly strong.

Against things like submarine pens, a 1000kg bomb didn't do much even with the explosive payload. For those you had to send in the Lancasters with 6000kg Tallboy and 10,000kg Grand Slam earthquake bombs.

Some bombs are equipped with arming vanes, which are little propellers that spin in the windstream and arm the detonator only after the bomb has fallen a sufficient distance; this prevents explosions too close to the airplane or in a crash landing. Do these make any noises audible from the ground?

@Grant Goodyear: Usually your target is a building of some kind, which will be quite a bit larger than the bomb you are dropping, and with enough structural integrity to remain standing after a ballistic impact of that magnitude.

If you want to destroy a target with a non-explosive projectile, you want to launch the projectile from orbit, as in The Moon is a Harsh Mistress. In that case, your terminal velocity is close to 11 km/s.