Pages: pp. 2-3
Lately, I've been pondering a question that I find curious: why don't physicists, specifically experimentalists, use numerical simulations to help solve their research problems more often than their counterparts in other science and engineering fields?
Of course, this question might be my own conceit. It's based on my personal recollections of work experiences in several different engineering and other-than-physics science fields. But it's also based on what I've gleaned from various professional sources—employment surveys, research papers, conferences, and so forth. So my question's premise about experimentalists, although not justified by systematic research, isn't completely anecdotal.
My thinking was rekindled recently by an article that appears in this issue, "Modeling Spin-Polarized Electron Transport in Semiconductors for Spintronics Applications," by Šimon Kos and his colleagues. I personally solicited this manuscript after hearing a seminar by Scott Crooker, one of the article's coauthors. What impressed me was the "novelty" of their use of numerical modeling. Scott confessed that the modeling played a critical role in understanding their experimental results. I don't mean to claim that their computational methodology or algorithms were novel, but that their approach featured numerical modeling in an important, arguably indispensable, role. In my experience this is relatively rare in physics.
By way of contrast, another article in this issue, "Hydraulic Splines: A Hybrid Approach to Modeling River Channel Geometries," illustrates the use of numerical modeling in an experimental science—geophysics—where it's much more common. This article provides a counterpoint to the previous one, congenial to my argument that numerical modeling is common outside of physics.
Getting back to the premise underlying my opening question, what are likely antecedents and what might be some possible consequences? This is a "chicken and egg" problem: cause and effect are entangled in a way that defies making an orderly, logical argument. I'll try anyway, though.
I've spent considerable time during the past two years engaging a varying cast of science and engineering academicians—physics, other sciences, and engineering professors—in a conversation about their curricular program and the roles that computing plays in them. This extended dialogue has convinced me that the relative disconnect in physics between experimental practice and numerical modeling correlates with a deficiency in the presence of computation in physics education. I feel secure commenting about the situation in physics, both because I am a physicist and because the picture of how education relates to workplace practices is well documented in physics. For this we have the American Institute of Physics to thank for operating its Statistical Research Center ( www.aip.org/statistics/), which does excellent work on a broad variety of such topics.
The AIP's research results in general indicate that a sizeable plurality, if not a majority, of those with at least one level of physics degree are employed outside of physics (mostly in other science and engineering professions). Moreover, these graduates spend a significant portion of their time on modeling and computing. Although they report that their overall physics training is very valuable, a majority cite computation as an area that was seriously lacking in their physics educational preparation. But can we lay the "blame" for this lack on experimentalists?
Well, the AIP data also indicate that universities award physics PhDs for experimental theses at twice the rate of those for theoretical theses. We can surmise then, that this ratio of experimentalists to theoreticians is representative of that for teaching faculty in physics departments, especially at the undergraduate level. This suggests that the presence (or absence) of computation in undergraduate physics curricula might mirror the use of computation by experimentalists in their work.
The results of a recent CiSE-sponsored survey (see our Sept./Oct. 2006 issue) confirm that computation isn't well integrated into undergraduate curricula—an assertion that's consistent with the AIP employment survey's results. Additionally, the CiSE survey suggests that what computation actually does exist is as a laboratory tool, presumably for controlling data collection and reducing experimental data. In undergraduate labs, as in experimental physics research labs, numerical modeling is usually confined to curve fitting and data visualization.
There's a flourishing field of computational physics—you might ask then, where's the influence of these physicists on curricula? My experience is that computational physicists are overwhelmingly educated as theorists. So maybe they're simply sorely outnumbered in physics departments, especially those that have little or no graduate programs. I will leave it as an exercise for the reader to determine what the reason(s) may be. It seems that the bottom line is for physicists to re-conceive the way they think about physics in the face of modern computing.
I suppose, after all, that this article isn't really about metaphysics, except in the sense of a pun. But it is a meta-analysis that I'd like to extend. Do you agree my assertions are valid? Can you offer examples or counterexamples from your own experiences? What might be a helpful role for CiSE to play in this discussion? Might another survey on computation in education, engineering, or workplace practices be a good idea? If you have any feedback, drop me a line at firstname.lastname@example.org.
Massimo DiPierro is an assistant professor in the School of Computer Science at DePaul University. His research interests include computational methods in science and finance, lattice quantum chromodynamics (QCD), and FermiQCD, a software library for fast development of parallel mesh-based algorithms optimized for lattice QCD computations. DiPierro has a PhD in physics from the University of Southmapont in the UK. For a look at his full CV, please visit http://web.mac.com/mdipierro/iWeb/Site/Welcome.html.