Old fashioned mechanical engineering gives zeptosecond accuracy

Accuracy that makes a hydrogen atom look big.

Those of you who know me know that I get excited by clever tricks. So, sometimes I take a break from writing about the latest and greatest scientific results, and talk about some cool new way of performing an experiment. You can think of these sorts of developments as enablers of better research.

Recently, a group of researchers has shown a very simple way to control light pulses with unheard of precision, which will make a whole class of common physics experiments accessible to many more researchers.

I punched him in the face to see how the crowd would react

Before we get to their cool trick, I want to describe a very common physics experiment, called a pump-probe experiment. Imagine that you want to test and understand the full range of human interaction. You could spend years observing people in different situations, noting their reactions and drawing correlations between behavior and environmental stressors.

A physicist would probably not take this approach. Being simple-minded, we would walk into a room full of people, punch someone very hard in the face, and walk out again. We'd then observe all the people in the room, noting their reactions to the initial event, to each other, and to whoever entered the room as a function of time. Essentially, we use one shocking event to probe as large a range of human behavior as possible.

Regretfully, these experiments are unethical, so physicists get their kicks by being cruel to atoms and molecules instead. The same experimental approach is taken; a large and very short laser pulse kicks a bunch of atoms into a highly excited state. We then follow that with a second, weaker laser pulse that measures some aspect of the atoms. For example, the second laser pulse might attempt to kick an electron out of an atom, but can only do that if the first put the electron in a specific state.

To give you an idea of the time scales we care about, electrons do interesting things in about a femtosecond (10-15s), so a short sharp shock needs to be in the attosecond (10-18s) region. Likewise, to measure where or what an electron is doing right now requires a laser pulse with attosecond duration.

Generating these light pulses is relatively simple. A charged particle, like an electron, will radiate light when it is accelerated. To get attosecond pulses, one simply needs to put an electron through a very short, powerful acceleration. But where would you get a large, accelerating field? A pulse of laser light, of course. Certain lasers can produce pulses of light that are just a few femtoseconds in duration, but have huge intensities. These fields are so strong that, when they encounter an atom, they simply rip an electron away from it and give it a short, very violent joy ride.

Although the electron is initially driven out of the atom and accelerated away, the electric field associated with light oscillates. So, as the electric field changes sign, it drives the electron back to the atom, where it slams back into place. All the energy gathered by the electron during this process is released during that moment of violent deceleration as a single, high-energy photon.

By carefully controlling the relationship between the laser light pulse envelope—the flash that one would see if you could measure fast enough—and the electric field that makes up that pulse, one can ensure that very short light bursts are emitted. Hence, attosecond pulses are... easy. Simply blast a laser beam through a gas jet.

So, getting the pulses are easy. Using them experimentally is more tricky, because you need to control the timing between two pulses. We ask the electron "What are you doing right now?" But, actually, right now means "in the time since we gave you a good kicking." We know the two laser pulses—one to do the kicking and one to do the asking—have attosecond duration, but to get reliable answers, we need to know the time delay between them to much less than attosecond precision.

Like getting a hair to sit still in Manhattan

But timing is a nightmare. Light travels at about 300 million meters per second, so in an attosecond, a light pulse travels only 0.3nm. Even the movement of mirrors due to thermal effects, passing air currents, and mechanical vibrations will produce changes that are much, much larger than that. So the timing problem comes down to one of mechanical stability: controlling the relative positions of a pair of mirrors to within 0.3nm. That can be done, but only to within 10nm. It involves rather dramatic amounts of technology, dedicated technicians, and a huge budget.

The only alternative is to be really clever.

Remember how above I said that you need to control the relationship between the light's underlying electric field and its pulse envelope to generate short pulses? This also controls where within the overall light pulse the attosecond pulse is generated. Under ordinary conditions, the phase of the light (which is related to its electric field) doesn't change: if I measure the phase at one location and then let the light propagate a few meters, I will find no change.

But this is not true when light passes through the focus of a lens. In the region of the focus, the light behaves as if it is travelling slightly faster—indeed the phase of the light is travelling faster. So, the phase relative to the envelope of the pulse changes by a half cycle over a few millimeters. So by placing two sources of atoms (typically, jets of gas) at different locations relative to the focus of the lens, we can create two attosecond pulses with a defined separation.

Let me explain that another way: if I had no lens, but just two gas jets separated by five millimeters, then the light encounters the first gas jet and generates an attosecond pulse. That travels with the light beam to the second gas jet where it generates a second attosecond pulse that overlaps perfectly with the first. You simply get a more intense attosecond pulse. From an outside perspective, you have a single attosecond pulse, and the number of gas jets makes no difference.

Now, we add a lens. The first gas jet is five millimeters before the focus and the other is right in the focus of the lens. The phase shift due to the focusing of a lens, causes the second attosecond pulse to be generated slightly earlier within the laser pulse than expected, so the two attosecond pulses do not overlap. From the perspective of the experimenter, two attosecond pulses are generated, and their separation depends on where the two gas jets are with respect to the focal point of a lens.

Suddenly, instead of worrying about the stability of two mirrors with respect to each other, all you need do is place two gas jets at different locations within a light field.

To put it in perspective, a change of about 15mm in one gas jet position changes the timing between two attosecond pulses by, at most, a femtosecond. That means both that you have very precise control over the timing, and that small changes in the position of the gas jet don't change the delay all that much. Indeed, the researchers showed that their pulse generation scheme was stable to within 100zs (10-21s). To do this using normal optics would require positioning your hardware with an accuracy of about the radius of a single hydrogen atom.

But that isn't science

There are those who philosophize at great lengths about science as a method. To them science is the tool, and all the lab equipment and so on is a necessary evil that is required to make the tool function. What matters are the great results that make us scratch our heads and rethink our understanding of the world. What gets forgotten in this perspective is that these great new results are usually generated by equipment that was unavailable to the previous generation of scientists.

It is rare that the glory is shared by the instrument makers. So, you can view this column as applause for everyone who spent a few years of their lives putting together a machine for someone else to make all the cool measurements with.

So by using the lens technique, you can achieve accuracy that would have previously required tolerances on the scale of 656×10-12 cubits -- depending on the length of your arm -- but now you can just about eyeball it. This is one seriously impressive achievement.

It's funny, I was a robotics engineer (was, not is - I got bored) and I'm one of that rare kind that shunned software solutions where I could use a mechanical solution. With a mechanical one, you can SEE where things go wrong, diagnosis is simple, and you can fix it a lot easier in many cases. It's not a black box full of code you have to debug.

Our over-reliance on software is a bad thing in the long run, sure it may be a little faster, a little smaller when everything works right, but when things go wrong, you can get it working right again a lot quicker mechanically.

It's funny, I was a robotics engineer (was, not is - I got bored) and I'm one of that rare kind that shunned software solutions where I could use a mechanical solution. With a mechanical one, you can SEE where things go wrong, diagnosis is simple, and you can fix it a lot easier in many cases. It's not a black box full of code you have to debug.

Our over-reliance on software is a bad thing in the long run, sure it may be a little faster, a little smaller when everything works right, but when things go wrong, you can get it working right again a lot quicker mechanically.

We need to reintroduce the art of the mechanical as well as the code.

Software and hardware aren't much different. For simple things, its pretty easy to see where something is wrong with both software and hardware. When each becomes more complex, that becomes very hard.

I like seeing simpler, equally or more effective solutions found to problems. It shows, in my opinion, more ingenuity to find a simple solution than to throw a bunch of partial-solutions at an issue.

pckilgore wrote:

Chris Lee wrote:

So, you can view this column as applause for everyone who spent a few years of their lives putting together a machine for someone else to make all the cool measurements with.

Instrument. Instrument, instrument, instrument. If it does work it's a machine if it measures something it's an instrument!

This pet-peeve freak-out brought to you by your local physical/analytical chemist.

Machine is something that uses or applies mechanical power. Instrument is a delicate tool or implement.

Instrument, in this case at least, is a subset of machine.

Andrew Norton wrote:

It's funny, I was a robotics engineer (was, not is - I got bored) and I'm one of that rare kind that shunned software solutions where I could use a mechanical solution. With a mechanical one, you can SEE where things go wrong, diagnosis is simple, and you can fix it a lot easier in many cases. It's not a black box full of code you have to debug.

Our over-reliance on software is a bad thing in the long run, sure it may be a little faster, a little smaller when everything works right, but when things go wrong, you can get it working right again a lot quicker mechanically.

We need to reintroduce the art of the mechanical as well as the code.

I conditionally agree. There are certainly circumstances where one or the other has distinct advantages; small size favors digital solutions, as well as digital output.

We're moving from an analogue to a digital transfer switch for our building generator because the digital switch is more reliable and has far more output for us to monitor.

Our gate operators, on the other hand, are and will remain analog because the relay-based systems are easier to troubleshoot and in that application are more reliable.

From the article: "So, you can view this column as applause for everyone who spent a few years of their lives putting together a machine for someone else to make all the cool measurements with."

** Applauds **

Of course, you just know that the people who designed and built this equipment are already using it to measure all kinds of interesting stuff - anyone who can think that far outside the box is also going to be asking highly original questions!

It's funny, I was a robotics engineer (was, not is - I got bored) and I'm one of that rare kind that shunned software solutions where I could use a mechanical solution. With a mechanical one, you can SEE where things go wrong, diagnosis is simple, and you can fix it a lot easier in many cases. It's not a black box full of code you have to debug.

Our over-reliance on software is a bad thing in the long run, sure it may be a little faster, a little smaller when everything works right, but when things go wrong, you can get it working right again a lot quicker mechanically.

We need to reintroduce the art of the mechanical as well as the code.

Software and hardware aren't much different. For simple things, its pretty easy to see where something is wrong with both software and hardware. When each becomes more complex, that becomes very hard.

To an extent.

I'm always reminded of the Mars Climate Orbiter for instance. They screwedup the units in software. If you had done the same thing in hardware, you probably would have noticed...

This is an interesting article and the analogies made it easier to grasp some of the concepts discussed. I'm not a physicist and I don't understand the impact of this new method; however, I look forward to future articles of the 'this new understanding of <insert scientific area> is a result new measurements enabled by this method' variety.

This is an interesting article and the analogies made it easier to grasp some of the concepts discussed. I'm not a physicist and I don't understand the impact of this new method; however, I look forward to future articles of the 'this new understanding of <insert scientific area> is a result new measurements enabled by this method' variety.

Unfortunately, zeptosecond accuracy will also enable new levels of pedantry that make mere "hair-splitting" look coarse. Hopefully enough good will come of this to offset the pedantry!

...Our over-reliance on software is a bad thing in the long run, sure it may be a little faster, a little smaller when everything works right, but when things go wrong, you can get it working right again a lot quicker mechanically.

We need to reintroduce the art of the mechanical as well as the code.

Software and hardware aren't much different. For simple things, its pretty easy to see where something is wrong with both software and hardware. When each becomes more complex, that becomes very hard.

To an extent.

I'm always reminded of the Mars Climate Orbiter for instance. They screwedup the units in software. If you had done the same thing in hardware, you probably would have noticed...

On the other hand, if the Mars rover turned out to have a mechanical screwup that wasn't noticed until it got to Mars then it would be pretty hard to fix. The software bugs usually can be fixed remotely.As somebody else said, right tool for the job.

+1 for the description of a physical scientist measuring the impulse response of a crowd. As a controls engineer that is exactly how I would do it. Maybe afterward I would do a frequency sweep of nitrous oxide in the room just to see how controllable the system is

This is a drawing of how I understood the article. I found the article very interesting, but it was definitely way over my head. Does this look accurate? Can anyone explain to me how this is important with regards to actual experiments you would do?

This is a drawing of how I understood the article. I found the article very interesting, but it was definitely way over my head. Does this look accurate? Can anyone explain to me how this is important with regards to actual experiments you would do?

I'm glad someone other than me was pining for a diagram while reading the article. It appears to match the mental picture I had, but I am way out of my field, and level, on this one.

One of the fun things of living in a physics department is seeing all the beautiful machines people build.

An amplifier limited but the thermal glow of a wall at 300 milli Kelvin above absolute zero, ok. Routinely measure the distance to the Moon to 1 mm, yep. A radio telescope to see the first stars and galaxies 13 billion years ago, working on it.

As for the software vs. hardware question, most experimenters are very agnostic. Whatever will do the job given the small amount of funding you've received. It is really performance for cost, remembering you live at the bleeding edge of what is technologically possible.

This is a drawing of how I understood the article. I found the article very interesting, but it was definitely way over my head. Does this look accurate? Can anyone explain to me how this is important with regards to actual experiments you would do?

I'm glad someone other than me was pining for a diagram while reading the article. It appears to match the mental picture I had, but I am way out of my field, and level, on this one.

My mental picture was a little different. As I understand it, your bottom pulse would actually be two pulses. So instead of a single arrow head picture another one a little to the left on the same line. Now, when they hit something the second one will hit a little bit later than the first one. How later is defined by the positioning of the other components. Without the mirror you still have two pulses, but they are overlapped so when they hit, the do so at the same exact time, so for practical purposes it's just one pulse. That said, I am no expert on this so I might be totally wrong.

It's funny, I was a robotics engineer (was, not is - I got bored) and I'm one of that rare kind that shunned software solutions where I could use a mechanical solution. With a mechanical one, you can SEE where things go wrong, diagnosis is simple, and you can fix it a lot easier in many cases. It's not a black box full of code you have to debug.

Our over-reliance on software is a bad thing in the long run, sure it may be a little faster, a little smaller when everything works right, but when things go wrong, you can get it working right again a lot quicker mechanically.

We need to reintroduce the art of the mechanical as well as the code.

... I see the software and mechanical sides to a project as being equally important. I'm a software person myself, but often get my hands dirty with the hardware as well... when either the software or mechanical side fails - in my experience you cannot do much to make up for it without fixing the root cause.

Then again - I don't like rigging things to make them functional. I prefer problems be fixed properly... not everyone is that way.

Chris Lee / Chris writes for Ars Technica's science section. A physicist by day and science writer by night, he specializes in quantum physics and optics. He lives and works in Eindhoven, the Netherlands.