After the successfull restart of the LHC, the first collisions with two 3.5 TeV beams colliding at 7 TeV will take place on march 30th. From 8:30 till 18:00 (UTC+01) there will be a live webcast at
http://webcast.cern.ch/lhcfirstphysics/
The first collisions will probably take place between 9:00 and 11:00. The tentative schedule can be found here.
Update: An interesting page to watch the beam is the LHC Operations beam status page.
If you run a python script that imports GaudiPython (or any LHCb modules for that matter) inside gdb on any lxplus node, you will run into an error like this:
[lxplus223] ~ > gdb python
GNU gdb Red Hat Linux (6.3.0.0-1.162.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"
...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) set args test.py
(gdb) run
Starting program:
/afs/cern.ch/sw/lcg/external/Python/2.5.4p2/slc4_amd64_gcc34/bin/python test.py
[Thread debugging using libthread_db enabled]
[New Thread 182894205120 (LWP 11117)]
Traceback (most recent call last):
File "test.py", line 1, in
import GaudiPython
ImportError: No module named GaudiPython
Program exited with code 01.
(gdb)
This is due to our group-login script (including the “rc” one)
using LbLogin and that reshuffles the paths. When gdb starts
the process to be debugged and if a SHELL variable is present,
it is started with “$SHELL -c”.
When it is perfectly legal for bash (it only starts a new shell),
with (t)csh it starts a new *login* shell corrupting the already
setup paths (PATH, LD_LIBRARY_PATH, PYTHONPATH etc).
So in order to solve this you have to unset SHELL inside
gdb (maybe best to place that in .gdbinit):
unset environment SHELL
Dr. Stefano Redaelli from CERN will hold two lectures on an overview of what happens when the LHC is in running mode. The lectures should be suitable for everyone with a bachelor or Vordiplom in physics or electrical engineering.They will take place in the CERN main auditorium at
More information can be found in the official announcement. If you happen to not be at CERN during that time, there will be also a webcast! As additional information on the webcast becomes available, I will post it here!
Since today Google Streetview is available for Switzerland. It covers quite a few streets and among them is the road to CERN.
Here you can see the main entrance:
And here you can see the ATLAS building
… the CERN Globe:
LHCb Experiment:
A very usefull tool for working with source code within LHCb is
Lbglimpse
As a remark for people moving from BaBar to LHCb, this is the tool for cmt most closely bringing the ‘srtglimps’ features. The ‘Lbglimpse’ can be found in $LHCBRELEASES/scripts. It is used as following
Lbglimpse <string> [<project>] [<version>] [-v]
and you can run this LHCb glimpse on every paths of $CMTPATH to find all files containing <string>
if CMTPATH is not set but CMTPROJECTPATH is set then it will use <project> and <version> to built CMTPATH locally. As an example we could look for the string ‘nies’ in the Moore Trigger project to find all places where the author ‘nies’ is mentioned or what ever:
Lbglimpse nies Moore v6r0
Have fun hacking the LHCb software stack.
Here is how to run the head version of Moore (no guarantee it will always work):
You will need a version tag one revision higher than the current. So for
example if Moore v6r0 is current you would go for Moore v6r1.
cd
setenv User_release_area ${PWD}
setenv CMTPROJECTPATH=${User_release_area}:/afs/cern.ch/lhcb/software/nightlies/lhcb1/Mon:
/afs/cern.ch/lhcb/software/releases:${Gaudi_release_area}:${LCG_release_area}
mkdir -p Moore_<one_rev_higher_than_current e.g.: v6r1>/cmt
create a project.cmt file in this dir:
project Moore_v6r1; use HLT HLT_HEAD use PHYS PHYS_HEAD use LBCOM LBCOM_vXXrY #choose HEAD or some version use REC REC_vXXrY #for each package use ONLINE ONLINE_HEAD build_strategy with_installarea setup_strategy root
do the following:
setenvMoore v6r1 getpack -u Hlt/Moore head cd Hlt/Moore/cmt cmt config make source setup.sh cd .. ./options/Moore.py
This time we do the same minimal histogram example, but using python. Again we assume that the user provides a file example.dat, that contains integer values in ascii format seperated by newlines.
call:
python historam.py example.dat
source for “histogram.py”:
import ROOT, sys
def readDataToHist(fileName):
f = open(fileName);
x_min = 0;
x_max = 10;
histo = ROOT.TH1I("h1","Histogram Title", 100,x_min,x_max);
for line in f:
raw = line[:-1]
y = int(raw)
histo.Fill(y);
return histo;
def histogram(fileName):
ROOT.gROOT.Reset()
c1 = ROOT.TCanvas("c1","c1",800,800);
histo = readDataToHist(fileName);
c1.cd(1);
histo.Draw();
#c1.Update();
c1.Print("histogram.pdf","Portrait pdf");
if __name__ == "__main__" :
histogram(sys.argv[1])
Yesterday we played board games in the CERN restaurant. Talking about an official event on friday one of the guys said, that he probably won’t be invited to official events for some times, because of a recent dispute with the CERN management. Surely we wanted to know what he did and he told us, that in his blog he pointed to a talk given by CERN Director-General Robert Aymar where one of the topics was the status of the LHC. The interesting thing about the talk was, that it contains pictures from the LHC incident on September 19. In his blog he pointed to the slides of the talk which were publicly accesible, but hidden deep inside the CERN Web.
Shortly after he posted the link to the slides, the access to the slides was restricted. So he contacted the CERN Press Office, why this was done. The official reply from the CERN Press Office was, that they wanted to inform the CERN community first, before publishing the pictures to the general public.
The incident has happend quite a while ago and it’s good to finally see some pictures of it, even if many members of CERN criticize the lack of openness regarding this topic.
Since we all love the tcsh (at least thats CERN’s point of view) ,
let me remind you that reverse search in tcsh is done by pressing
ALT-p
or for reverse order
ALT-P
So after a long time I finally figured out today how to set alternative
compile options in CMT when using the LHCb framework.
First there are some additonal tags besides the well known tags
for production and debugging code
slc4_amd64_gcc34 slc4_amd64_gcc34_db
one is for code coverage the other for performance tests
tag slc3_ia32_gcc344_cov tag slc3_ia32_gcc344_pro
Most important is where all this stuff is set,
it’s in
GaudiPolicy/cmt/requirements
Problem with the XXX_cov and XXX_pro is that there are no
supported prebuild binaries by CERN. So it’s all or nothing either
you build everything on your own or you are stuck. You can work
around that with a little hack:
getpack the GaudiPolicy package to your local cmtuser directory
and just add your additional flags to a supported tag.
If you just want to alter the cppflags for one package you would
just add something like this to the package’s requirements file:
macro_append cppflags " -g "
or
macro_append cppflags "" Linux " -g " Windows " -foo -bar"
Where Linux and Windows would act as a switch for different
compilation setups.and the quoted strings would be the appended
options. Note the first empty qoutes in the second example it’s just
the empty standard case.
Update:
As Stefan Roiser pointed out to me over at the cmt mailing list,
one possibility would be to produce your own requirements file
/my/dir/to/cmt/requirements
put your macro_append etc into there and set an enviornment variable
CMTUSERCONTEXT=/my/dir/to/cmt
Then your requirements file should be processed last, thus changing
appending your compiler flags etc as a last step of the configuration before
executing the make.
Also on the cmt mailing list Grigory Rybkin explained, that if you ever wonder
why your cppflags or any other macro behave weird you could check with
cmt show macro cppflags
Example output for package Moore on a Linux machine:
# Package CMT v1r20p20070208 defines macro cppflags as '-pipe -ansi -pedantic -W -Wall -Wwrite-strings
-Wpointer-arith -Woverloaded-virtual ' for tag 'Linux'
# Package GaudiPolicy v8r5 defines macro cppflags as ' -fmessage-length=0 -Df2cFortran -fPIC -shared
-D_GNU_SOURCE -Dlinux -Dunix -pipe -ansi -Wall -Wextra -pthread ' for default tag
# Package GaudiConf v10r13 appends to macro cppflags : ' -DAPPNAME=\"${package}\"
-DAPPVERS=\"${version}\" ' for default tag
# Package RichKernel v7r17 appends to macro cppflags : ' -DRICHDEBUG ' for tag 'Linux&debug'
# Package LHCbKernel v9r2 remove from macro cppflags : '-DGOD_NOALLOC' for default tag
#
# Selection :
cppflags=' -fmessage-length=0 -Df2cFortran -fPIC -shared -D_GNU_SOURCE -Dlinux -Dunix -pipe -ansi
-Wall -Wextra -pthread -DAPPNAME=\"${package}\" -DAPPVERS=\"${version}\" -DRICHDEBUG '
And then use the “-e” option of make via brodcast, like:
cppflags=MYFLAGS cmt br make -e
it orders make to give environment precedence over variables from makefiles.