Like most other large particle physics experiments, CMS has a lot of management structure, physicists who effectively are just managers. As you can see these organizational charts are usually represented with a lot of inter-connected boxes. Which is why positions like this are sometimes referred to as boxes. Most of the important boxes, like the spokesman, our representative to the rest of the world, are elected by the collaboration. In the case of mere lower convenors, a team of wise senior physicists typically just finds you worthy, then nominates you and if you accept you have the job. Particularly for post-doctoral researchers these positions are quite coveted, as it proves (if you do your job well) that you have some form of leadership capabilities, one of the alleged requirements for a tenure track job.
Today is a special day for me, as I have accepted to help run the CMS pixel detector software group for a year (at least). I find this all highly exciting, as I suspect I will be learning a lot in this time, not only about our detector but also about how particle physics experiments, or at least CMS, are run behind the scenes. I even have a title, as I now am a Detector Performance Group convenor for the CMS pixel offline software. My own acronym and a box to put it on, whoo whoo! Essentially the title means that I have to make sure the software that is used to analyze and reconstruct pixel data is in a good state. And that means keeping track of all different actitivities that go on in the development, making sure things stay up to date, etc. And that means… guess what: meetings.
So, I got my little (and yes this really is quite a minute) box. I wonder what’s next. I suspect many more meetings.
Tags: CMS, collaboration, culture, pixel
Well that depends on what we need and want. A good state typically means that the code runs relatively fast (think in the order of a second or so per event) over many collision events while still being able to reconstruct as much information contained in the raw data as possible. Also it is probably necessary to read and write to databases, collect information from various sources and write out the information, which becomes an actual technical problem if you produce about the content of an (old style) iPod per minute. Yes that sounds vague but that also has to do with the fact that at the moment we can only use mathematical models to simulate what we are going to see, so until we see real collisions that is the benchmark. Once collisions start arriving we will probably have to rewrite a significant part of all code.
In CMS most analysis code is in C++ with some python wrappers, but I am personally much more interested in what our software does, not what language it’s in. Getting everything to work together is a non-trivial job, we have several hundred physicists developing code, which we test in twelve-hourly integration builds (typically also for a multitude of code branches). For each of those branches we release a stable release every week or so, and about once per two months we start a new release branch.
I think that was a very short answer on your question. Which is good as I have to go sleep. Yet another meeting in 7 hours!
If somthing is wrong and your standing on your small box and looking over the next size bigger box, be careful it might get kicked out from underneath you.