A long time ago, all you needed to think about and record the data you were interested in was a pen and some vellum, and maybe a few candles and a trusty manservant. Somewhere along the line, the chart recorder got invented, and when combined with the oscilloscope and those awful scope cameras, a whole new world of data recording and storage was available. Having one's own ENIAC was pretty helpful, too, especially once manservants (and really, all of bored-noble-of-means science) became gauche.
These days we're a little bit more sophisticated. Computers are indispensable parts of every physics lab, and there's various pieces of software that have become somewhat ubiquitous. If I ever have the blessing or curse of grad students, here's what I'd want them to be able to use, and what I try to be useful with myself:
Labview. This venerable suite is ridiculously dominant in the small-lab physics world, and it's easy to see why. It interfaces with hardware well, has an intuitive feel that is easy to pick up quickly, even as a youngster, and is well-supported and documented. I use it to run experiments, connecting with and programming various analog-to-digital converters, pulse generators, and any number of GPIB devices. Its main drawback is a general sense of aesthetic unpleasantness.
Mathematica. Stephen Wolfram's squalling baby has become the default tool for so many of my physics needs that despite its steep learning curve it remains second-to-none. It's a bit more suited to symbolic theoretical analysis and visualization than data processing, which is why for raw data I like to use other packages, like:
Matlab. Great for anything involving numbers, and arrays of numbers. For theoretical work I don't really know how I'd use it, since it's not really a symbolic package, but I really like the intuitive way in which it handles arrays. I've also been loyal ever since I spent a few months at my pre-PhD job converting old Fortran nested loops into Matlab array operations.
Unfortunately, the culture of my current lab favors another package, Igor, which I initially loathed but have come to at least tolerate. I don't think anyone out there will start using it from my recommendation, and those of you in the Igor cult are already converted, so I won't say any more.
For an idea of how it's all put together, I typically do calculations and modeling (before and after taking data!) for an experiment in Mathematica, take the data using LabView, which sends the raw data to Igor or Matlab to be played with and analyzed; fun times are had by all.
Please commence arcane software flamewars now. Before you tell me, though, I'm fully aware that Mathematica has near-infinite capabilities, and that Python can fully replace the very, very expensive Matlab. Just don't tell me to use Maple or MathCad.
- Log in to post comments
I've used Mathematica, Maple and Matlab. Matlab for the array behaviour (and also it turned out to be used for constructing arrays from permutations of a set of rows) and Mathematica and Maple for the same sorts of stuff. I'm more of a programmer, though, than a user of nice GUIed packages (although I like a decent IDE as much as the next programmer, oh yes). I do like me some python (and C# is surprisingly pleasant to write, not to mention that Visual Studio is a fantastic IDE).
I think that experimenters and observers are going to become much more aware of SQL and databasing in general (some are already there of course), as the datasets they generate become larger; additionally, as they increasingly need to share large amounts of data they'll need decent web programming for database-backed sites.
Octave is free software similar to Matlab. Chemistry Dept at Wisconsin came up with it as I recall. Scilab is another free package that I have seen in use. The other package that I have used is R, the free software (Gnu) version of the S Statistical package. I think R might be taking over that space. These are all more calculational engines as opposed to an algebraic system like half of Mathematica, the other half being a nice high precision arithmetic and graphing system.
Of course the real most used experimantal software is really Excel and the other big spreadsheets - OO and gnumeric for example. Everybody in industry uses these plus something else...
I have only had occasion to play with Mathematica and Maple, but otherwise the Labview to Matlab route is familiar. (And, yes, Igor among chemists in companies I've worked with.)
Both of these have the advantages with ability to interface with C-code and be compiled to result in unified user packages, inhouse or for early product generations. (And, yes, the resulting GUI tends to be Labview and somewhat tacky.) So while being initially expensive you get ROI IMO.
For multiphysics modeling I would use Comsol Multiphysics. It has a really intuitive interface build on physical modeling - you quickly specify (or import) the geometry, PDE's, the boundary conditions and methods such as weak solution et cetera. Probably the fastest way to a solution on Earth.
[And I'm not saying this as a swede - oh, who am I kidding. Of course I am, that and having a Matlab package is how I got to know the product in the first place. It was derived from Matlab before being entirely rewritten in C so it is probably still easy to interface with.]
I feel bad whenever I watch a scientist running analysis and numbers in Excel (and I was surprised, even at Caltech, to see how common it was, although not in physics). It looks so, so painful to me.
Scilab is good, as is Octave. Neither is perfect, though. Octave is very nicely compatible with Matlab; enough so that people in my project use either and can interchange code without any issues cropping up. Where Octave really falls down is the primitive graphing capabilities. It got stuck with a bad interface to Gnuplot a long time ago and is in dire need of a modern graphing package.
Scilab is much better in this regard, and does nifty things like distributed computing if you need it, but the main drawback can be that the language isn't the same as Matlab, so cooperation can becoem a big issue. If you don't need Matlab compatibility, Scilab certainly seems the better tool.
R is reportedly very good for statistics (I don't do statistics enough to have tried it myself).
Gnumeric is a very good spreadsheet (Excel compatible; so much so that you have separate functions in some cases emulating bugs in Excel calculations). I prefer Gnumeric both over Excel (which is tied to one OS only) and OpenOffice Calc, which I find rather clunky. Don't diss spreadsheets too much; it can be an excellent tool for some applications and occupies a usability sweet-spot on the complexity/power scale.
Also, don't diss dynamic languages out of hand either. Perl, Python or Ruby - which you pick up doesn't really matter (they're pretty much at parity for all but language purists), but having a tool at the end of the complexity/flexibility scale can be immensely beneficial. Just ask people doing computational biology, who have sometimes extremely complex data sets to crunch and have taken to dynamic languages with abandon. They're much, much easier to get stuff done in than a tool like Java or C++, which in many situations is rather important, as the development time typically dwarfs the actual code execution time - it doesn't matter if Java or C++ are two or three or five times faster if most of the time will be spent writing code rather than running it.
ROOT is a vital part of any high energy physics analysis. I consider it a custom software development environment rather than an application such as matlab or mathematica. If you're not doing tremendous amounts of data processing with very specific software needs (millions of events with hundreds of simultaneous measurements each), then ROOT is too much overhead. ROOT is more powerful when complemented with dynamic languages such as perl/shell scripts.
I feel terribly inadequate, I'm an experimental atomic physics postdoc, but have never used LabView, and have only a passing knowledge of Mathematica, which makes it very painful to use on the odd occasions it is warranted. Matlab, however, I couldn't live without - I use it for pretty much everything. Octave's also good, as I can't afford my own personal copy of Matlab for home use.
I'm an atmospheric scientist. We have a lot of code (radiative transfer models, numerical weather prediction models, land surface models) written in Fortran. Do other fields still use Fortran? I know my engineering friends have mostly abandoned it.
For graphics (usually visualizing 2d and 3d geophysical data on a map) I mostly use IDL but I'm open to something better (more intuitive). I just switched to a Mac for my desktop and I plan to play around with Ocatve.
My field (space physics) has plenty of legacy code written in Fortran, and some new development in that language--it appears to still be the language of choice for anything, such as global models, which requires high performance computing. We're also locked in to IDL for any serious data analysis, thanks to some decisions made back in the early 1990s. Database software is becoming increasingly important with our multi-terabyte data sets. Mathematica and Maple are largely limited to the theoreticians; I've never used either.
I liked IDL; I remember using it as a junior and senior undergrad in radio and optical astronomy labs and internships. It was basically matlab-like, with just fortran- rather than c-like conventions...or is it the other way 'round?
What's that one package that's always advertised on the back of Physics Today? Does anybody use that?
We too are currently locked into IDL because of decisions made way back when. Our lab is currently trying to convert over to python. I highly recommend learning python. They have a library, matplotlib that has a very similar interface to matlab. (plus it's free...can never argue with that!)
There's plenty of Fortran around here. I often think that it's pretty cruel to drive grad students into Fortran; given that many of them won't be physics researchers all their lives, it might be beneficial to get them using languages and tools that are likely to help them in their other careers. Sure, there's a hell of a lot of inertia when there's a lot of code written but think of the grad students. Why, oh why, will no one think of the grad students?
Another vote for python. Useful starting points:
http://www.scipy.org
http://matplotlib.sourceforge.net
http://ipython.scipy.org/moin/Documentation
and the IEEE Computing in Science and Engineering special issue:
May/June 2007 (Vol. 9, No. 3)
http://tinyurl.com/yq39y6
Python is great as a Matlab replacement. Although in a few ways it's not quite as easy and integrated as Matlab, the programmer language itself is better designed. And of course its free.
As for doing data analysis, though, I've found a separate program like Igor to be far more useful. When I do numerical simulations in Python and want to analyze my results it's a lot easier to use a GUI program to do curve fitting and so forth.
Back of Physics Today?. Origin. I used it a bit in undergrad, tried to convert our lab from Igor. It is, more or less, just Excel with more, prettier, plots.
I'm down with all three of your big progs, Nathan. One thing I'd like to learn is Python. And I'm sooo bad at C... eugh.
Igor is very popular with physiologists.
As someone who has, during over 40 years in software, and consulting with elders such as John Mauchley (who owned the patent on the stored program digital electronic computer), programmed in well over 30 languages (including weird ones such as Jovial for USAF, CMS-2 for Navy, and Hal/S for Galileo and Space Shuttle), and taught a dozen in grad school:
(1) It doesn't matter what language you learn first; what matters is that you are the master of the machine, and not the slave;
(2) It doesn't matter what language you learn next, but now, with binocular vision, you begin to see what the limits are of one syntax and semantics, versus what can be done differently;
(3) The more languages and packages you learn, the easier it gets, until you can (as I have) learn a new one on the plane flight to where I had to accomplish something immediately on landing (this was in pre-laptop days, lugging printed manuals);
(4) No language or OS or application is a panacea;
(5) In the long run, you will find that you can program any application in any language under any operating system on any computer, with difficulty ranging from brain-burning to effortless;
(6) The deeper problems are: how does a group of people decide what problem to solve, and how to solve it on time and within budget;
(7) To ask "what is your favorite language" is little more than the Geek equivalent of "what is your astrological sign?" Once you've broken the ice, you can find a win-win in the conversation.
octave? graphics?
Check them out:
octaviz.sourceforge.net, www.math.mcgill.ca/loisel/octave-workshop/
My vote is for the ROOT ...