Physics Hacker

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

We needed to create a histogram from some output of a python program. Therefore I wrote a minimal root program to read in the data from a file and save the histogram as a pdf.

The datafile should contain one entry per row. Save the following source code as e.g. histogram.c and then start root with

root -b -q 'histogram.C("filename")'

Here is the sourcecode:

#include <TCanvas.h>
#include <TH1.h>
#include <iostream.h>
#include <Riostream.h>
#include "Math/PdfFuncMathCore.h"

int main(){
  histogram("test")
}

void histogram(char* fileName) {

  gROOT->Reset();
  TCanvas *c1 = new TCanvas("c1","c1",800,800);
  TH1I *histo = readDataToHist(fileName);
  c1->cd(1);
  histo->Draw();
  c1->Update();
  c1->Print("histogram.pdf","Portrait pdf");
}

TH1I* readDataToHist(char* fileName)
{
  ifstream in;
  in.open(fileName);
  Double_t bin;
  Int_t nlines = 0;

  Int_t x_min = 0;
  Int_t x_max = 10;
  TH1I *histo = new TH1I("h1","Histogram Title", 100,x_min,x_max);

  while(1)
  {
    in >> bin;
    if (!in.good()) break;
    //cout << "bin: " << bin << '\n';
    histo->Fill(bin);
    nlines++;
  }
  in.close();
  return histo;
}

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.

We currently update the LHCb interface to the event generator Sherpa, called LbSherpa, to Sherpa’s latest version 1.1.1. In that effort we had to learn some of the details on how to set up the Sherpa Framework properly:

ATOOLS::exh
Sherpa uses it’s ATOOLS::Exception_Handler in a singleton fashion to handle Exceptions. It makes use of this instance throughout the framework by providing the pointer ATOOLS::exh. It has to be initialized by calling ATOOLS::exh->init(). You can see an example of it’s use at Sherpa’s Main.C:

# /SHERPA/Run/Main.C lines 12 and following
using namespace SHERPA;

#ifdef F77_MAIN
extern "C" int F77_MAIN(int argc,char* argv[])
#else
int main(int argc,char* argv[])
#endif
{
  ATOOLS::exh->Init();

This calls Init() as defined in Exception_Handler.C:

# file /ATOOLS/Org/Exception_Handler.C lines 28-30
using namespace ATOOLS;

ATOOLS::Exception_Handler *ATOOLS::exh(NULL);

# file /ATOOLS/Org/Exception_Handler.C lines 38-45
void Exception_Handler::Init()
{
  static bool init(false);
  if (!init) {
    exh = new Exception_Handler();
    init=true;
  }
}

ATOOLS::msg
The use of Sherpa’s Message system for printing output and errors is handled by it’s Message class in a similar fashion through the pointer ATOOLS::msg. But you probably shouldn’t use it directly but rather by the macros defined in Message.h:

# file /ATOOLS/Org/Message.H lines 189-200
#define msg_LevelIsEvents() ATOOLS::msg->LevelIsEvents()
#define msg_LevelIsInfo() ATOOLS::msg->LevelIsInfo()
#define msg_LevelIsTracking() ATOOLS::msg->LevelIsTracking()
#define msg_LevelIsDebugging() ATOOLS::msg->LevelIsDebugging()

#define msg_Error() ATOOLS::msg->Error()
#define msg_Out() ATOOLS::msg->Out()
#define msg_LogFile() ATOOLS::msg->LogFile()
#define msg_Events() if (msg_LevelIsEvents()) ATOOLS::msg->Out()
#define msg_Info() if (msg_LevelIsInfo()) ATOOLS::msg->Out()
#define msg_Tracking() if (msg_LevelIsTracking()) ATOOLS::msg->Out()
#define msg_Debugging() if (msg_LevelIsDebugging()) ATOOLS::msg->Out()

ATOOLS::msg also has to be initalized:

# file /ATOOLS/Org/Message.H lines 8-10
namespace ATOOLS {
  Message *msg(new Message());
}

# file /ATOOLS/Org/Message.H lines 116-123
void Message::Init(const int level,const std::string &logfile)
{
  m_level = level;
  if (m_level&16) {
    InitLogFile(logfile);
    Out()<<"Initialize output module Message. Level "<<m_level<<std::endl;
  }
}

There will be more parts as we learn more about Sherpa’s inner workings.