4 ms·
None of it is easy. I haven't read this particular paper, but I have worked on similar experiments. First, you have to create muons and then isolate them in the
by nagrom 14y ago
None of it is easy. I haven't read this particular paper, but I have worked on similar experiments. First, you have to create muons and then isolate them in the particle beam and this costs quite some money (typically fire accelerated protons at a target and allow the pions and other decay products to be dumped in some dumb absorber that the muons pass through). Then you have to capture the muons into orbits around protons that come from hydrogen that needs to be disassociated and ionised. Then you have to pulse the hydrogen with a laser and excite the muon into a new energy state and accurately measure the energy of the photons that come off in the decay. You almost certainly need subnanosecond accuracy in your timing at this point. Of course, you can never be absolutely certain what you're measuring in any particular event so you sum over millions of events and average. And you have to simulate the whole thing (typically using a C++ framework called GEANT running on massive processor farms analysed with a horror-show of an analysis toolkit called ROOT) to see what could go wrong and determine the possible sources of error and uncertainty in your measurement.
To get the money to do this, you have to apply for government grants that may take up to a year to get approved. And no government wants to fund it so you need an 'in' with the lab, because they'll be the ones that sponsor your application for it to have a chance of success, and you'll need to know people from a whole load of other countries to collaborate with and prove your bona fides. And the people writing all these grant applications and doing most of the middle management are distracted by teaching literally hundreds of students every week during term time, so they can't even work full-time on it.
There are other experimental ways of doing this (e.g. measure correlated form factors and parton distribution functions from elastic scattering and extrapolate to zero momentum transfer), but they're all harder. They'll probably be done within the next 30 years. Probably. This particular effort is likely the work of 30-50 PhDs working for five or more years (at 50% of the salary they'd earn working for commercial companies), discounting any of the commercially available technology like electronics developed by CAEN or detector components developed by the likes of ElJen or Hamamatsu. And I would be surprised if they didn't mint another 10-15 PhDs during the effort. And I haven't covered the highly trained technicians and electronic engineers that are usually needed to build a lot of the custom experimental equipment.
- deltasquared 14y agoWhat do you have against ROOT ?
- nagrom 14y agoI dislike the fact that the library is forever expanding its feature set while a lot of the core code is badly written or buggy (see the method for calculating the angle between two T3vectors, for example). This is crazy when development is not under commercial competitive pressure. I dislike the use of global pointers to control the behaviour of the library and I find the design decisions in particular regarding histograms and the lack of separation between data and presentation bewildering (e.g. a graph is a subtype of a histogram, which should contain it so that it can be plotted. A plot frame is a type of histogram object, which makes no sense that I can understand, etc.). The library makes no use of a lot of core C++ features; it really is C-with-classes, where the use of exceptions could really improve the code base and potential usage. I feel quite strongly that a numeric calculation should not return a number if something went wrong, for example. I dislike that it has a strong feeling of not-invented-here syndrome where it could include dependencies on well tested code, e.g. the gnu scientific library, but instead rewrites everything. And up until about 6 months ago the default plot styles were damned ugly, although this has gotten a lot better. There seem to be three different math libraries that each implement some subset of mathematical functions independently and a lot of the graphics stuff makes little sense to me (take a look at how to ensure platform-independent type face size in a plot, for example). The CINT interface almost seemed designed to ensure that when students were learning, they learned ROOT and not C or C++, which is great for productivity in the short term, and incredibly sucky in the medium to long term. I understand that a lot of this is legacy cruft (and even made sense at the time!) and that I could contribute patches for it, but I'm busy doing my actual job. I'm impressed that a lot of my objections are being worked on too - I was heavily dependent on the framework for my PhD about 5 years ago and a lot of my frustration stems from then. It often feels like the ROOT team learn-by-doing; they want to understand something, so they make it in ROOT. Which is a fine way to learn, but not the best way to develop stable code that should be used by thousands and thousands of people. In some senses ROOT is an amazing achievement and I still find myself using it on occasion. But I've now mostly replaced what I use it for with matplotlib and the GSL and my life is easier. breathes I also dislike the way that it seems partially to have enabled physics to go in a direction where we pump out PhDs who don't understand code or physics, but act as worker-drones for the large collaborations. But that's not really ROOT's fault, and is a whole 'nother topic.