Frontier

We are using a CDF-specific branch of frontier. We should try to get this into the main line so we don't have to worry about support long term.

Zoom

The Jet corrections (package JetUser) uses HepLorentzVector from the CLHEP package. This package requires a patch from Exceptions and ZMUtilities, as described here: http://www-cdf.fnal.gov/internal/physics/top/jets/how-to-apply.html Checking out these two libraries from the zoom repository and building them is the cause of several common errors.

However since the use of this object in JetUser is actually trivial, it can be removed; there is a make flag which removes it, and then the patch does not need to be applied. Any modern top code built as described here: http://www-cdf.fnal.gov/~cplager/internal/Analysis/Tools/TopAnalysisTools/tools.html has this flag set, so it does not need the patch. Simona - this is probably your case.

Unfortunately, this page: http://www-cdf.fnal.gov/internal/physics/top/topcode.shtml effectively recommends building the patch. I will ask to have it improved.

Ray

If you are build JetUser yourself then you can do

gmake JetUser.lib LINK_SHARED_ROOT=yes __NO_CDFSOFT__=true

Unfortunately the trivial place that the HepLorentzVector is used is in the interface, so if your analysis code uses this interface method, you will have to modify it to use the scalar accessor, or, of course, continue to use the patch.

FYI - if you follow your instructions using a migration release, you won't see this problem. You only have this problem if you are using one of the older frozen releases.

Lynn

When zoom was migrated from cdfcvs to cdcvs, the path for anonymous checkout changed. That change is about 2 years old.

gfortran is supplanting g77. There are incompatibilities.

It looks like the gcc 4.4 and gcc4.3 compilers in RHEL 5.4 and RHEL 5.3 respectively are not defaults in SL5.4 and SL5.3: 4.1.2 is instead. May be code breakage with the later compilers: I'm testing that now (30-Apr).

How many stand-alone utilities can be built 64-bit? sam utilities, neurobayes, etc?

We do not have a "manager" established for all the CDF libraries.

We do not have a "manager" established for all the products we use.

We have not verified that our code is always properly initialized. This can be checked with compilation flags with optimization turned on, but searching through the log files and comparing with the code is time intensive.

    override CXXFLAGS += -O2 -Wuninitialized -Wall
    override CCFLAGS += -O2 -Wuninitialized -Wall

There are many "false positives" which appear at instantiation time. If the order of initialization of internal variables from the arguments differs from the order of arguments, the compiler will complain. In all cases I've looked at so far, the internal variables are simple doubles or ints and the order doesn't matter at all, but if a more complex quantity were being initialized there might be a conflict. In any event, this seriously muddies the water when trying to track down problems.

In addition we have a lot of warnings, most of them harmless. When we a priori know that a double is going to be in the normal range for an int, there ought to be some way of telling the compiler that we know exactly what we're doing.

And to make matters muddier, root and clhep and trybos include warning-able code in the headers that get included all over the place.