The next big activity of CERN is building LHC, an upgrade of the LEP apparatus. They differ in that LEP accelerates electrons (light) and LHC will accelerate hadrons (heavy). The construction is a vast civil engineering undertaking with all the obvious needs for computation. In a few years the new experiments themselves will require elaborate computing.
CERN is populated by permanent support people and itinerant physicists. The former are paid by CERN out of the money from the various European governments. CERN is a political bureaucracy. Permanent jobs are allocated roughly proportional to national contributions. Among the permanent staff, the Information Technology group runs the old-style glass-walled computer center. IT does all the campus-wide support for High Energy Physics. For example, they maintain CERNLIB, a collection of Fortran programs used by physicists. They also own a convenient place to store very large amounts of data.
The experiments have their own budgets and buy their own computing.
Typically each Digital engineer at CERN gets invited into an IT project or an experiment with the specific objective of increasing the effectiveness of Digital solutions. Often discounted hardware comes with the engineering help. The data storage technology (HPSS) is a joint project with various contributors including IBM and Digital.
The Joint Project originally reported to sales, but became a part of CTG about two years ago and is now managed by Mark Gantly (Galway).
In February, after much email and web preparation, I spent a week at CERN (report). At a decision meeting in CTG it was decided to send me back for six months. The default project assignment was called ROOT , a data mining application for very large physics data bases. In April my family spent a week in Geneva setting up living accomodations and contacting schools. By the time Digital got through the paperwork (late June), ROOT had fallen on hard times and its people exiled to site Prévessin (a 10 minute drive from the main campus).
My family and I relocated to Geneva in the middle of July 1997. One is supposed to leave the US with work permit in hand (see HR005-23 for all the details). Otherwise you cannot do anything that looks "permanent", for example shipping household goods or enrolling kids in school. Digital and Geneva had not yet managed to complete the work permit formalities and CERN was about to go on its August vacation. So we did too. In September the other Digital engineers at CERN introduced me to numerous CERN projects. The details of these meetings and other joint project housekeeping activities were recorded in weekly progress reports. The conclusion was that no CERN project wanted to put me to work unless I was going to be there for a year or more. By way of contrast, CW had been at CERN for nine years.
So in October I picked a project (The Alpha Magnetic Spectrometer) and did something for them. In late November I showed the result to AMS. They liked it enough to put in in their home page. My time in Geneva, however, was up. The headcount of the Joint Project is now 2.
The work permit was promised by Geneva in late August; it finally issued in mid December. I felt like an illegal alien most of my stay. The experience of living in Switzerland was unforgettable for me and for my family. Digital paid for housing and transportation directly. Other things, including school tuition, were reimbursed. Money lagged expenditure by 6 weeks so one needed a fairly big pool of ready cash to get started.
Well, that is the plan. The infrastructure is running. Some parts of LHC have begun to use it. Each subproject has to set up a data server and populate it with its own LHC engineering information. It is a lot of work but an enormous step forward from the mounds of paper it would otherwise require. It is the nicest real Java I have seen (Thanks to Tom Pettersson of CERN ISS).
CERNLIB is a 550 KLOC collection of HPTC Fortran codes. It is heavily used by physicists all over the world. CERNLIB is maintained in the IT division. Recently CERNLIB has been ported to NT and even more recently to Digital Visual Fortran.
I got peripherally involved in the NT Intel port. Dr. Valery Fine (Russia) was upset because CERNLIB did not pass the regression test when compiled with DVF on NT. Using me as liaison, Fine and the CTG team ironed out the bugs in a few days. There were only three. Two of them were in 20-year old Fortran code.
CERN is moving toward providing the CERNLIB functions in C++ and dropping some platforms from the Fortran CERNLIB maintenance list. THE Atlas project has a C++ style sheet which they hope will improved the quality of the C++ as it is written. The ROOT project is entirely in C++.
HPTC worldwide seems to be moving to C++. This is a reluctant move, with much footdragging by the Fortran-trained physicists. In some cases moving to C++ means using f2c then compiling with a C++ compiler. The HPTC C++ standard is g++. That is, they write using the GNU compiler and then try commercial compilers to see if they get better performance. But if their g++ code does not compile or run on the commercial compiler, they just use g++. They have a similar approach to unix. Linux is the baseline.
Many groups are experimenting with Java. Their question for Digital was performance. If they can solve their 1000x1000x1000 mesh differential equations in Java, they will switch. But not before. I told them Digital would be a performance leader in Java and to expect Fortran quality Java in two to five years. We will see.
I also discovered a chink in the Java armor. The runtime is not very portable. This is not really news, but the magnitude of the problem became apparent when I delivered an applet that needs to run world wide. Any useful Java calls a lot of methods in the API. There is no specification of the effect of the API calls, and only informal, anecdotal descriptions of how to use them. As a consequence, both the users and implementers must guess. When the guesses are different, trouble happens. For example, to get a GUI up and going there are a number of methods that must be provided by the developer to be called by the JVM and a number of methods provided by the API that must be called, in the proper order, by the application. It is easy to get a Java applet that runs well on Unix but fails on WIN95 and/or NT. The true mantra seems to be "Write once, test everywhere." This is a solvable problem, but it is going to take a lot of work and cooperation between the Java vendors.
I also had an opportunity to do a number of activities for Digital in Europe.