Prof. Benjamin Monreal
Department of Physics
5123 Broida Hall
University of California, Santa Barbara
Santa Barbara, CA 93106-9530

805-893-3440
bmonreal@physics.ucsb.edu

Physics project ideas

I've lost count of how many times I've said to myself, "Hey, I bet it's possible to do X---that'd make a neat project for a undergrad." For the most part I've been letting these ideas evaporate into thin air---most of them aren't in any research field in which I'm active, they're not things I have money (or lab space) to support or supervise. But I also recognize that there are lots of UCSB undergrads wanting to work on something research-related, just for fun, or as a route towards learning Matlab, or before finding their way into a senior thesis lab project. Please contact me if you're interested in tackling one of these projects.
  1. Analysis of wind conditions from ocean images On a windy day, otherwise-flat parts of the ocean pick up a lot of small riffles. In principle, it would seem that you could figure out how strongly the wind is blowing by measuring the size of these riffles---even in a still photograph. In particular, I would guess that a photo of a windy ocean has lots of detail at high spatial frequencies.

    Project: take a series of beach photos, all in the same location (angle, camera, time of day, etc.) and under various wind conditions. Run these photos through a Fourier transform to measure their high-spatial-frequency components. See if there's a robust correlation between something in the spectral data and the wind speed. Turn this into a prototype auto-wind-speed-measurement algorithm. If that looks promising: see if it's robust under different conditions---does the analysis that works facing the sun from Coal Oil Point still work on Ledbetter Beach on a cloudy day? If not, look for an algorithm that does.

    Skills required: I suspect Matlab or Mathematica can do the whole thing. You'll need to read up on Fourier transforms and hunt around for an image-analysis tool or software package that can run them for you.

  2. Pelican surfing One often sees pelicans "surfing" up the beach ahead of the crest of a wave---gliding very near the water without flapping their wings. I think that the wave is mechanically displacing some air upwards, and they use this updraft to keep them aloft without flapping their wings. Alternatively, perhaps they're using the wind---not the air pushed upwards by the wave, but a horizontal surface wind that has to deflect upwards to get over the wave (the same way it would when hitting the stationary bluffs). I have no idea whether either of these hypotheses is true, and I can find no published literature on the topic.

    Project: Figure it out. Dig through the literature and figure out if the answer is already known. If it isn't, learn a bit of old-fashioned aerodynamics and calculate the wind pattern in the vicinity of a surfing pelican.

    Skills required: This is a serious mathematical project, and may turn out to be hard---or maybe not! You'll need to have mastered vector calculus, to the point that you can look at the Navier Stokes equation and not be afraid. Good project for someone who has taken Mech E. 110.

  3. Fireworks as sonar There are two aspects of a 4th of July fireworks show that I find really neat: the chemistry of the various sparks and whatnot, and the echos of the reports. You hear the 'crack' of a big shell, followed by a series of distinct 'thuds' (which I think are the echos of the report off of each large nearby objects) and a longer 'rumble' (which I think is the blending-together of the echos off of increasing numbers of further-away objects.) The time between the initial report and each "thud" should be related to the distance to that echo-source. You ought to be able to interpret the echo-pattern as a passive sonar map of the area around you.

    Project: Do it---use the 4th of July fireworks reports as a collection of sonar "pings", and use them to build a map of the area. First, collect the data---you'll need to record the fireworks show from at least two, ideally three, distinct locations 10 or more meters apart. Bring the three recording streams together and analyze them using sound-travel times. First you can figure out exactly where the firework sound came from, then you can work out the geometry of the echos.

    Skills required: Nothing in particular. I'd love to see the first pass at this analysis done with pen and paper---use some (basic) waveform-viewing software to measure the time delays between different sounds, use that to calculate a geometric constraint on where the sound could have bounced, and trace out that constraint on paper. Secondarily, you could enter the hand-identified time delays into Mathematica or Matlab and program it to plug through the geometries for you.

  4. Locally linear embedding for HEP There is a really neat data-analysis technique called "Locally Linear Embedding" (Google for it) which I wish was readily available for high-energy and nuclear physics data analysis. If someone could translate the basic algorithm into a C++ class, it'd be very easy to contribute it to ROOT and thereby make it available to this community.

    Skills needed: Basic C++ or Java experience to build the LLE class; some fancier C++ abstractions to make it ROOT-compatible. ("Fancier" is a relative term when you're talking to a physicist. Our actual computer science training ranges from "scattershot" to "can usually hack something together".)

  5. GGobi statistical package for HEP The high-energy physics community tends to write most of its own software, especially for statistical analysis of data. In most cases this is the right thing to do, but in some cases it means that other scientists can develop very neat data-analysis tools and techniques and HEP people might never notice. One such instance is a package called GGobi, which I find extremely useful for getting oriented in multi-dimensional data sets. All of my data tends to be in formats specific to ROOT, the HEP data analysis package. It'd be neat to be able to pipe data directly from a TTree (an important ROOT class) into GGobi.

    Skills needed: Software "project" experience. You'll need to be able to pick your way through the GGobi API and communicate with its developers; an open-source-software hobbyist or similar coder might do well on this project.

  6. Evolution visualizer. Evolution, like astronomy, is hard to understand sometimes because of the huge scales involved. In astronomy you have these billion-billion mile distances; in evolution, you have the 300,000 generations (or whatever) of descent between us and Lucy the australopithecine. There are some neat Web-based ways to help visualize astro distances---see, for example, this page---and I'd love to do something comparable for evolution---at least for human evolution. You know sort of what the hominid phylogenetic tree looks like; a tree with various branches, most of which break off and die out (the Neanderthals, homo floriensis, etc.) and one of which survives to the present as Homo sapiens. You know what a family tree looks like---male symbol, female symbol, they mate a line shows the offspring. Finally, you know what Minard's chart of Napoleon's campaign into Russia looks like (here), where the width of the line represents the number of people in the army.

    OK, so imagine a hominid phylogeny chart where, like Minard's chart, the width of the line represents the number of individuals alive at that time. (It's 6 billion units wide at the bottom, representing the present; it's narrowed down to 10,000 units wide at the Toba bottleneck, etc.) But here's the fun part: when you zoom into the chart, Google Maps style, you can see that it's made up of zillions of individual family trees. That's a single chart on which you can see the scale of ultra-rapid human population growth; you can see how the evolutionary timescale is much greater than the generation timescale. It'd be neat.

    The project: Do it. Do the basic textbook/journal searches to figure out some ballpark population sizes at various times; use some artistic license to figure out what the tree needs to look like when zoomed out (e.g. make it into a Minard chart); write some software that can simulate a family-tree-like pseudo-genealogy that fills the entire tree, maybe with a bit more book research and a bit of artistic license (e.g.: maybe Neanderthal generations are short; maybe Ardipithecus family trees had an only-the-alpha-male-reproduces structure; etc.) to put interesting features into the generations and to smoothly vary them over evolutionary time. Most important: the tree itself will be a multi-gigabyte dollop of data. Can you adapt some sort of GIS server software to let users zoom in and out of it, scroll, etc., via the Web. Skills needed: A bit of programming, a bit of art/graphics interest, a bit of web-server-hacking and software-manual-reading. If you're interested in tackling this project I can probably find some funding for it.

  7. Your ideas I'm happy to help UCSB students turn their own mini-project-ideas, or fragments of ideas, or whatever, into real projects.