Napa Valley Earthquake - Aug. 24, 2014

As I'm sure you've heard/read by now, there was a moderate earthquake in the Napa Valley region of California earlier today. At 3:20 AM a fault ruptured producing a magnitude 6.0, the largest for that area since 1989. So far the damage pictures I've seen coming out of the area show moderate to severe structure damage on older structures and lots of toppled book shelves and wine racks.

This earthquake has nearly a textbook slip pattern or focal mechanism. The plot below is often called the "beach ball plot" and is a way to represent how the fault moved. Without going into the details of how we construct a plot like this, we can simply interpret what we see. This plot shows a traditional strike-slip motion. This means that the plates slid past each other laterally with little motion up and down on the fault. This doesn't mean that there will be no up and down motion as the seismic waves propagate though!

Focal Mechanism Solution (

Focal Mechanism Solution (

We can also interpret from this beach ball that the strike-slip motion was right-lateral. If we were standing out in the ocean looking towards the other side of the fault inland California, we would see things shift to the right. This makes sense with the tectonics there as the pacific plate is grinding northwest past the North American plate. The locked plates bend and deform storing elastic strain energy, then finally fail, snapping into a state of lower stress. I've shown this elastic property of rocks before, but we have yet to really discuss the earthquake cycle in detail. Maybe one day soon I'll do some demonstrations about that though!

The final piece of the earthquake story I want to show you is a movie of the ground motion experienced at a seismometer in the Marconi Conference Center, Marshall, CA. This video shows what we would see if we could track a piece of the ground in 3D and watch it's motion as different seismic waves go by. There is lots of information in this plot, but for now just notice the large amounts of motion!  This is three minutes of data with 4 ground positions recorded per second in real time, then sped up.

As always, if you do happen to live in an earthquake prone area, be sure to have a plan, have an emergency kit, and always be prepared for any natural disaster!


Mythbusting: Cooling a Drink with a Wet Paper Towel

While reading one of the many pages claiming to have "15 Amazing Life Hacks" or something similar, I found a claim about quickly cooling a drink that deserved some investigation.  The post claimed that to quickly cool your favorite drink you should wrap the bottle/can in a wet paper towel and put it in the freezer.  Supposedly this would quickly cool the drink, faster than just the freezer.  My guess is that the thought process says evaporative cooling is the culprit.  This is why we sweat, evaporating water does indeed cool the surface.  Would water evaporate into the cold, but dry freezer air? Below we'll look at a couple of experiments and decide if this idea works!

We will attack this problem with two approaches.  First I'll use two identical pint glasses filled with water and some temperature sensors, then we'll actually put glass bottles in and measure just the end result.  While the myth concerns bottles, I want to be able to monitor the temperature during the cooling cycle without opening the bottles.  For that we'll use the pint glasses.  

First I had to build the temperature sensors.  The sensors are thermistors from DigiKey since they are cheap and relatively accurate as well.  To make them fluid safe, I attached some three-lead wire and encapsulated the connections with hot-glue.  The entire assembly was then sealed up with heat-shrink tubing.  I modified code from an Adafruit tutorial on thermistors and calibrated the setup.  

To make sure that both sensors had a similar response time, we need to do a simple control test.  I placed both probes in a mug of hot water right beside each other.  We would expect to see the same cooling at points so close together, so any offset between the two should be constant.  We also expect the cooling to follow a logarithmic pattern.  This is because the rate of heat transfer is proportion to the temperature difference between the water and the environment (totally ignoring the mug and any radiative/convective transfer).  So when the water is much hotter than the air, it will cool quickly, but when it's only slightly hotter than the air it will take much longer to cool the same amount.  

Mug Cooling Photo

Plotting the data, we see exactly the expected result.  Both sensors quickly rise to the water temperature, then the water cools over a couple of hours.  The noisy segments of data about 0.25 hrs, 0.75 hrs, and 1.75 hrs in are likely interference from the building air conditioning system.  


If we plot the temperature difference between the sensors it should be constant since they are sensing the same thing.  These probes look to be about dead on after calibration.  Other than the noisy segment of data, they are always within 0.5 degrees of each other.  Now we can move on to the freezer test.


I used two identical pint glasses and made thermocouple supports with cardboard.  One glass was wrapped in tap water damped paper towel, the other left as a control.  Both were inserted into the freezer at the same time and the temperature monitored.  The water was initially the same temperature, but the readings quickly diverged.  The noisy data segments reappear at fixed intervals suggesting that the freezer was turning on and off.  The temperature difference between the sensors grew very quickly, meaning that the wrapped glass was cooling more slowly than the unwrapped glass.  This is the opposite of the myth! 



Next I placed two identical, room temperature bottles of soda in the freezer, again with one wrapped and one as a control.  After 30 minutes in the freezer, the results showed that the bottles and their contents were practically identical in temperature.  The wrapped bottle was slightly warmer, but it was within the resolution of the instruments (thermocouple and IR sensor).  I did this test multiple times and always got temperatures within 1 degree of each other, but not consistently favoring one bottle.

So what's happening here? Well, I think that the damp paper towel is actually acting as a jacket for the beverage.  Much like covering yourself when it's cold outside, the damp paper towel must be cooled, then the beverage can cool.  Adding that extra thermal mass and extra layer for the heat to diffuse through.  To provide another test of that hypothesis I again tested bottles with a control and a foam drink cooler around the base.  The foam cooler did indeed slow the cooling, the bottle being several degrees warmer than the control.

2014-08-13 17.56.28

The last question is why did the test with the glasses show such a pronounced difference, but the bottle test show no difference? My best guess is that the pint glass was totally wrapped vertically and that bottle had the neck exposed still.  Another difference could be the thickness of the towel layer and the water content of the towels.  

The Conclusion: BUSTED! Depending on how you wrap the paper towel it will either have no effect or slow down the cooling of your favorite drink.  

Let me know any other myths I should test! You can also keep up to date with projects and future posts by following me on twitter (@geo_leeman).

Arduino Code:

// which analog pin to connect
// resistance at 25 degrees C
// temp. for nominal resistance (almost always 25 C)
// how many samples to take and average, more takes longer
// but is more 'smooth'
#define NUMSAMPLES 15
// The beta coefficient of the thermistor (usually 3000-4000)
#define BCOEFFICIENT 3950
// the value of the 'other' resistor
#define SERIESRESISTOR1 9760
#define SERIESRESISTOR2 9790

int samples1[NUMSAMPLES];
int samples2[NUMSAMPLES];

void setup(void) {

void loop(void) {
uint8_t i;
float average1;
float average2;

// take N samples in a row, with a slight delay
for (i=0; i< NUMSAMPLES; i++) {
samples1[i] = analogRead(THERMISTOR1PIN);
samples2[i] = analogRead(THERMISTOR2PIN);

// average all the samples out
average1 = 0;
average2 = 0;
for (i=0; i< NUMSAMPLES; i++) {
average1 += samples1[i];
average2 += samples2[i];
average1 /= NUMSAMPLES;
average2 /= NUMSAMPLES;

//Serial.print("Average analog reading ");

// convert the value to resistance
average1 = 1023 / average1 - 1;
average1 = SERIESRESISTOR1 / average1;

average2 = 1023 / average2 - 1;
average2 = SERIESRESISTOR2 / average2;
//Serial.print("Thermistor resistance ");

float steinhart;
steinhart = average1 / THERMISTORNOMINAL; // (R/Ro)
steinhart = log(steinhart); // ln(R/Ro)
steinhart /= BCOEFFICIENT; // 1/B * ln(R/Ro)
steinhart += 1.0 / (TEMPERATURENOMINAL + 273.15); // + (1/To)
steinhart = 1.0 / steinhart; // Invert
steinhart -= 273.15; // convert to C


steinhart = average2 / THERMISTORNOMINAL; // (R/Ro)
steinhart = log(steinhart); // ln(R/Ro)
steinhart /= BCOEFFICIENT; // 1/B * ln(R/Ro)
steinhart += 1.0 / (TEMPERATURENOMINAL + 273.15); // + (1/To)
steinhart = 1.0 / steinhart; // Invert
steinhart -= 273.15; // convert to C(steinhart);

//Serial.println(" *C");


Are Rocks like Springs? A Video Demonstration

Today I was getting a demo in the lab ready for a tour group and decided to try shooting a quick, unscripted bit on rocks as springs.  There are a few generalized statements in here, but overall it is a first try at a public education video.  Comments welcome!

Exploring Scientific Computing at SciPy 2014

Texas Campus

This past week I've been in Austin, TX attending SciPy 2014, the scientific Python conference.  I came in 2010 for the first time, but hadn't been able to make it back again until this year.  I love this conference because it gives me the chance to step away from work on my PhD and distractions of hobby projections to focus on keeping up with the world of scientific computing with Python.  I try to walk the fine line between being a researcher, engineer, and programmer everyday.  That means that it is easy to fall behind the state of the art in any one of those, and conferences like this are my way to getting a chance to learn from the best.

SciPy consists of tutorials, the conference, and sprints:

The first two days were tutorials in which I got to learn about using interactive widgets in iPython notebooks, reproducible science, image processing, and Bayesian analysis.  I see lots of things that I can apply in my research and teaching workflows!  Interactive notebooks are one of the last things that I was wishing for from the Mathematica notebooks.

The next three days were talks in which we got to see the newest software developments and creative applications of Python to scientific problems.  I, of course, gravitated to the geophysics oriented talks and even ran into some people with common connections.  It was during the conference that I gave my poster presentation.  I knew that the poster focused more on the application of Python to earthquake science than any earth-shaking (pun-intended) software development.  There were a few on the software side that wondered why I was there (as expected), but the poster was generally very well received.  Again I had several chance encounters with people from Google and other companies that had similar backgrounds or were just very interested in earthquakes!

The final two days (I'm writing this on the last day) were sprints.  These are large pushes to further develop the software while a critical mass of experts are in one location.  I'm still new enough to these massive open-source projections (on the development side at least) that I wasn't incredibly useful, but the reception of the developers was great!  Everyone was excited if you wanted to help and would spend as much time as needed to get you up and running.  During the sprints I've been following a fix for an issue that has recently caused problems in my plotting.  I also fixed a tiny issue (with help) and had my first pull request accepted.  For software people these are tiny steps, but for someone coming from just developing in-house purpose-designed tools.... it was an hit of the open-source collaboration drug.

Lastly, I worked on a project of my own during the evenings.  During the 2010 conference I worked with a friend to make a filter remove the annoying vuvuzela sound from the World Cup audio.  This year I've been making a fun earthquake visualization tool.  You'll be seeing it here on the blog, and may have already seen it if you follow me on twitter.  I learned a lot during this year's SciPy 2014, got to spend time with other alums of OU Meteorology, and meet some new folks.  Next on the blog we'll be back to some radar or maybe a quick earthquake discussion!

Doppler Radar at Home: Experiments with a CW Radar Part 1

When you hear "radar", you probably think of weather radar and a policeman writing a ticket.  In reality there are many kinds of radar used for everything from detecting when to open automatic doors at shops to imaging cracks in concrete foundations.  I've always found radar and radar data fascinating.  Some time back I saw Dr. Gregory Charvat modify an old police radar on YouTube and look at the resulting signal.  I happened to see that model of radar (a 1970's Kustom Electronics) go by on EBay and managed to buy it.  I'm going to present several experiments with the radar over a few posts.  If you want to learn more about radar and the different types of radar I highly recommend Dr. Charvat's book Small and Short-Range Radar Systems.  I haven't bought a personal copy yet, but did manage to read a few chapters of a borrowed copy.

The doppler radar I purchased.  I'm not using the head unit.

The doppler radar I purchased. I'm not using the head unit.

The radar I have outputs the doppler shift of a signal that is transmitted, reflected, and received.  Doppler is familiar to all of us as we hear the tone of a train horn or ambulance change as it rushes past us.  Since there is relative motion of the transmitter (horn) and receiver (your ears), there is a shift in received frequency.  Let's say that the source emits sound at a constant number of cycles per second (frequency).  Now let's suppose that the distance between you and the source begins to close quickly as you move towards each other.  The apparent frequency will go up because the source is closer to you each emitted cycle and you are closer to the source!

The doppler effect of a moving source.  Image: Wikipedia

The doppler effect of a moving source. Image: Wikipedia

This particular radar transmits a signal at a frequency of 10.25 GHz.  This outgoing signal is continually transmitted and reflected/scattered off of objects in the environment.  If the object isn't moving, the signal returns to the radar at 10.25 GHz.  If the object is moving, the signal experiences a doppler shift and the returned frequency is higher or lower than 10.25 GHz (depending on the direction of travel).  This particular radar can be easily hacked and we can record the doppler frequency out of a device called a mixer.  The way this unit is designed, we can't tell if the frequency went up or down, just how much it changed.  This means we don't know if the targets (cars) are coming or going, just how fast they are traveling.  Maybe in a future set of posts, we'll build a more complex radar system such as the MIT Cantenna Radar.  Be sure to comment if that's something you are interested in.

Since we'll be measuring speeds that are "slow" compared to the speed of light, we can ignore relativistic effects and calculate the speed of the object knowing the frequency change from the mixer, and the frequency of the radar.

Simplified doppler velocity.

I took the radar out to the street and recorded several minutes of traffic going by, including city busses.  Making a plot of the data with time increasing as you travel left to right and doppler frequency (speed) increasing bottom to top, we get what's known as a spectrogram.  Color represents the intensity of the signal at a given frequency at a certain point in time.

Speeds of several cars on my street.  1000 Hz is about 33 mph and 500 Hz is about 16 mph.

Speeds of several cars on my street. 1000 Hz is about 33 mph and 500 Hz is about 16 mph.

The red lines are strong reflectors (the cars).  Most of the vehicles slow down and turn on a side street in front of the radar.  About 30 seconds in there are three vehicles, two slow down and turn, the third again accelerates on past.  Next I'll be lining up a video of these cars passing the radar with the data and you'll be able to hear the doppler signal.  To do that I'm learning how to use a video processing package (OpenCV) with Python.

In the next few installments, we'll look at videos synced with these data, radar signatures of people running, how radar works when used from a moving car, and any other good targets that you suggest!

Gravitational Tricks: Lagrange Points and Orbiting at Puzzling Speeds

The orbital path of ISEE3 from launch to near present.

The orbital path of ISEE3 from launch to near present.

Last time I talked about a team trying to capture and reuse the ISEE3 satellite (here).  The team has received lots of telemetry lately, determined the rotation speed of the satellite, and even had an amateur radio operator receive the satellite!  While all of this is going on, they must rapidly plan out what orbit they wish to enter.  The most discussed orbit is termed ESL1, the Earth-Sun system Lagrangian point #1.  Lagrange points an interesting phenomena that I thought worth a short discussion.

When we think of orbits, traditionally we consult Kepler's laws.  These "laws" are 3 simple rules that were written down between 1609 and 1619 by Johannes Kepler.  I won't discuss them at length, because there are already many great sources to learn about Kepler's Laws and their application.  The thing we want to draw from them is that an object orbiting closer to the Sun (say Venus), will have to travel faster to satisfy the laws of nature.  In doing so it will orbit the Sun more times than the Earth will in the same amount of time.  Venus will in fact orbit the sun 1.6 times during 1 orbit of the Earth!

Let's say we place a satellite far away from the Earth, between the Earth and sun.  the satellite will orbit slightly faster than the Earth.  Over a period of time it will be on the opposite side of the Sun and we won't be able to communicate.  Eventually it will come around and lap the Earth! This isn't desirable, but we can use Lagrange points to solve this problem.

The simple laws of orbital mechanics that we have considered thus far are only valid for a simple problem with two objects (Earth and Sun or Earth and Satellite).  We have we three bodies though, the Earth, the Sun, and the satellite! Three body problems are generally sticky to solve, but we have an advantage.  The mass of a satellite is small compared to the mass of the Earth and the mass of the Sun (unless it's the Death Star).   We can ignore the small mass of the satellite as solve what is known as the restricted three body problem.  There are a few interesting points in space, the Lagrange points, at which the gravitational pull from the Sun and Earth are superimposed on each other to give the satellite the same orbital speed as the Earth!

The L1 point is where ISEE3 may end up, so let's look at it.  The satellite will be above the Earth at an altitude of 1.5 million km (932,000 miles), towards the Sun.  At this point, the two body mechanics say that the satellite will orbit the Sun faster than the Earth.  Adding in the complications of the three body problem, we see that the gravitational tug of the Earth towards the Earth,  away from the Sun is canceling out just enough of the Sun's pull to make the satellite orbit at the same angular speed as the Earth.  How useful!

There are other Lagrangian points as well (L2-L5), but we won't discuss them here, other than to say that a similar explanation can be given for each.  L4 and L5 are particularly interesting because they are inherently stable and hence lots of objects get caught there.  There are objects in Earth-Sun L4/L5 and Earth-Moon L4/L5.

Lagrange Points of the Earth-Sun system (Image: Wikipedia)

Lagrange Points of the Earth-Sun system (Image: Wikipedia)

Generally satellites are placed in a small orbit around the L1 point for several reasons, including that it isn't inherently very stable.  The ISEE3 team will have to execute a rather complex series of maneuvers to get to L1 again, using the pull of the moon and making a very close pass that comes within 10's of km of the surface of the moon.  Time is of the essence, as the longer the wait the more they must change the speed of the craft (referred to as Delta V in the engineering jargon).  The ship only has about 150m/s of Delta V left before it runs out of fuel.  It'll take up to 1/3 of that to reposition the satellite, depending on how long the team must wait.

That's the quick and dirty view of Lagrangian points.  I hope this was interesting and helps you understand space exploration, or your addiction to Kerbal Space Program a little more!

Reviving a Piece of the 1970's: ISEE-3


There's been a decent buzz in the space and tech communities about the "ISEE-3 Reboot Project", so I thought it would be worth mentioning here and pointing out some of wonderful techniques they are using to revive a satellite from almost 40 years ago.

The ISEE-3 satellite is one of three satellites that made up the International Cometary Explorer (ICE) program.  There were some interesting orbital things done with this satellite after its launch in August of 1978.  It was also the first spacecraft to go through the tail of a comet!  As with all missions, this one came to an end and the satellite was not head from since 1998.  The equipment to talk to the satellite was removed and it was considered to be out of service.

ISEE-3 sits in a heliocentric orbit, meaning that orbits the sun, not the Earth.  We knew that ISEE-3 would make another stop by our planet in 2014 when it was parked in this orbit in 1986 (from what I can tell anyway).  A group of citizen scientists started the ISEE-3 Reboot project, crowd funded on the internet.  They got permission to take over the satellite and intend to use the Moon's gravity and a rocket burn to send it on another mission.  If the window of June is missed, the satellite will probably never be heard from again.

The team was able to contact ISEE-3 on May 29 using the Arecibo observatory radio telescope.   The craft was commanded to transmit engineering telemetry, basically a health screening of the systems.  The team is currently busy decoding the data (streaming in at 512 bits/sec) and planning how they will execute the rocket burn.

The team is running out of an old McDonalds at the NASA Ames Research Park, the makeshift mission control has been termed "McMoons" after hosting previous space based projects.



The part of this that I find amazing is the role that software defined radio is playing.  Software defined radio (SDR) is a way to use software to emulate radio equipment.  With a small USB stick I can receive many different kinds of radio signals and decode them, something that would have required racks of equipment a few years ago.  This team is using a radio termed the "USRP" that allows them to transmit and receive.  I've written about them before (here) and have used them in research.  They are amazing little units and provide a unique learning opportunity.  (Maybe I'll post something about a radar we made with one of them as a demo!)  A photo tweeted by the team shows 2 USRP units and laptops hooked into the giant dish antenna at Arecibo.

Screen Shot 2014-06-02 at 12.51.08 PM


That's all for now, but stay tuned to the team's website for updates and I'll be keeping up with the progress as well.  This is just another incredible example of how advanced hardware and software that has become relatively cheap can allow a group of savvy citizens to accomplish incredible feats!  Way to go folks!


Drawdio: Creating Music with Your Hands

Awhile back I saw a post from the folks at the MIT Media Lab on a little creation they called the "drawdio" (here).  This looked like a fun little project! It's an oscillator based on the classic 555 timer integrated circuit, but with a twist.  The twist is that you can control the frequency of the oscillation (tone of the note played by a speaker) by varying the resistance between two contacts.  These contacts seem to commonly be a pencil lead and your body, but as the MIT website demonstrates, almost anything can be used.



I decided it was time to build one of these, so I headed over the MAKE to get the plans.  I already had most of the parts (or good substitutes) on hand.  The battery holder and enclosure would have to come later.  I built the circuit with simple point-to-point wiring on perforated board.  The speaker is a salvaged part from a fax machine!

Drawdio No Case


I plugged the power supply in a touched the signal wires together.  The speaker let out a shrill tone and we were in business.  The next challenge was figuring out a case a final setup for the device.  I wanted this to be durable since lots of people at work and home would be playing with it.  The solution ended up being hot glue and a plastic crayon case.  I drilled holes in the case above the speaker for sound and added a power switch.  The final touch was terminal posts for the sense wires that control the pitch.

To make the sensor I just wrapped bare wire around a pencil body for one contact and inserted a push pin into the lead at the top for a second contact.  The goal is to complete that circuit and change the resistance between the two contacts.  The easiest way is to draw a graphite track on paper and make the circuit through your hands.  See the demo video below.

This is an incredibly fun project and can be very educational to the beginning electronics hobbyist or a way to get school children interested in STEM fields.  What are you waiting for? Go build a drawdio! (Kits available from Adafruit)

Why a Standing Desk Didn't Work for Me

Standing Desk Leeman

I spend a lot of time at work... probably more than is really healthy for me.  In an effort to mitigate any harmful effects that working has on my health, I decided to try the standing desk idea.  We've all heard about how sitting all day is very detrimental to your health (example).  Recently our department has been renovating offices and giving people the option of a small motorized adjustable height desk.  I was very excited about his until I found out that my office was not going to be renovated.  I looked at the standing desks that professors had purchased, such as the Geek Desk, but realized that those commercials desks are out of the graduate student budget.  I also had never used a standing desk before.... what if it didn't work for me?

After reading lots of articles online, I decided to build something like a standing desk on-top of my existing desk.  Following the advice over at "Only a Model", I made the IKEA pilgrimage and bought the required parts (a coffee table, a shelf, and two brackets).  I got back, cleaned off my desk, assembled the parts, and had my very own standing desk!  It was slightly shaky under the weight of two 27" monitors, but overall useable.  I thought my health problems had been successfully avoided.

I noticed that my feet began to get sore, walking down the hall at the end of the day was painful.  Reading more, it appeared that I needed a foot pad.  I bought the best that I could find, in fact it cost more than all of my standing desk parts!  The mat was incredibly comfortable and thick enough that I could take my shoes off and dig my toes in.  It still didn't solve the problem though.  I continued standing for weeks, brought in a stool to sit a few hours a day, but no gain.  Standing felt great, but not for 10-12 hours a day.

I noticed that doing tasks such as filling out paperwork that required focus, but not creativity were helped.  I wanted to get it done! Tasks like writing and coding suffered.  Not being able to lean back and think of the right words or the correct function call slowed me down.  Reading and absorbing papers was also difficult.  At the end of the day, it just wasn't working (another example).

Maybe if I only worked 8 hours a day, 5 days a week, things would have gone differently.  An adjustable height desk may have helped as well, but I doubt that I would take the time to change configurations more than once a day.  I ended up back at my sitting configuration with a new coffee table at home.

There are other options out there.  Several people in the department have recently purchased a FitDesk. These cycle desks look good for computer tasks, but are not intended to replace a full desk with their small surface area.  Probably the best option is to have multiple work spaces.  One standing position, one sitting position, and possibly something else as well.  That's possible if you have a larger office/cube, but a small office with 6 graduate students just doesn't have the room.

So what do I do? I've been trying to be better about getting up every hour or so and taking a short walk/refocusing my eyes at a long distance.  Maybe something like a foot roller would help as well.  What is your workspace setup like? Remember to make sure it is ergonomic!


Literature Inertia - Maintaining Stability or Discouraging Exploration?



Recently I've been thinking a lot about literature inertia and the best ways to accommodate and deal with it.  What is literature inertia? It is a phrase that a professor I had at Penn State used to describe the common theme in fields of research where things are done a certain way because that's the way they have always been done.  Everyone bases their analysis or technique on one "seminal" paper at some point in the past.  The methods in that paper are likely the first methods tried that succeeded, and everyone has used them ever since.

I can see some benefits to literature inertia.  For one, it provides a consistent way things are done or a "standard" analysis program that all scientists in the field use.  This kind of stability allows long term comparison and inter research group comparability.  That's fantastic! Maybe the method isn't exactly ideal, but it is the same everywhere and eliminates some of the variables that would otherwise be present.   Inertia of a field also means that the wheel isn't re-invented all of the time, which saves the researcher time and lets them pursue the research, not the methods.  But is that best for the advancement of science?

The downsides of literature inertia are just as significant as its advantages though.  The original methods or code that become the "standard" is likely one of the first that worked well when the research was in the discovery phase.  It is also, by necessity, a bit old.  There are likely better methods developed that could produce better results.  I also believe that the pressure to use a standard procedure is discouraging exploration.  Funding isn't commonly given to explore and test new ways of solving a solved problem! Literature inertia can also bias a field against an idea for decades.  There are some sub-disciplines that are considered to be very delicate research areas.  Working on these new and poorly understood areas runs the risk of having your career marked early as being a borderline crank.  Many reasonable ideas have been floated in these fields, but quickly shot down by those following the inertia.  Often these ideas are thrown out with little work done to legitimately check their validity.  Likewise, one true crank can make an entire area taboo for all researchers.

So what's the answer to this problem? Well, like so many things in science, it probably lies in the gray area in between.  While some stability is needed so that each researcher isn't approaching a problem from completely different directions, there should be less discouragement of exploration.  Standards are also temporary.  Nothing in research is truly permanent.  Standards will become out-dated and need replaced.  This process isn't easy, painless, or fun, but necessary if science is to remain current and relevant.

Computer data formats are one example I can think of to illustrate inertia. There are many great formats that will stick around for some time such as JSON, HDF5, NetCDF, etc.  Some labs still insist on having their own data format though! This is puzzling because the computer scientists have done a very good job of making a flexible data format that is supported by most major programming and scripting languages.  The labs using in-house formats must distribute readers (normally only in one or two languages) or share bulky text files to collaborate with others.  Why do these labs insist on their format? Because it is what they have been using for years and they don't want to invest the time and effort to change to a more open format.  Inertia, for those groups, is crippling their ability to use more recent tools.  That matters because if more tools are available to analyze data and they are easy to use, researchers will find it easier to explore their data.

Another example is inversion techniques commonly used to solve for things like earthquake location problems.  Some fields are using inversion techniques that came about in the 1950's.  These techniques work, in fact, they have been tuned over the years to work very well.  For operations on a day to day basis, that stability is important.  It is the job of researchers to try new techniques though and explore/improve.  Every technique has a weakness, and trying many is important!

I do think that many standard techniques will be challenged with a new group of researchers coming into the job market, but I am concerned about how going against literature inertia could damage long-term job prospects.  I've heard well respected traditional faculty say things like "This computer data management problem isn't a decision for you early career people or something you should be involved with."  Like wise I've also seen some excellent ideas get pushed out because it isn't the same way things have always been approached.  This attitude is likely propagated by the pressure to publish and the damping that puts on free exploration.  What do you think?