ScienceTools: Seth presented the report.
FSSC Report: (Eric) The FSSC version of ScienceTools tag v9r8p2 has been ported successfully to several unices in addition to RHEL4 and RHEL5 (32-bit versions of Ubunt, CentOS and OpenSUSE). Debian, Fedora and others should follow in short order.
Tom Stephens has left (but is still available for emergency maintenance). John will be taking over the data-server. Other responsibilities will be shouldered by John Horner and by Eric
(Heather) What is the best way to get access to HEAdas software? Do we want to use the Kipac distribution, which is more than we need? (Jim) Stuart thought we could just rsync; this should be ok and we would avoid dealing with the extra items (e.g. ciao, astroroot) in Kipac. We can just mirror all of HEAsoft if it's not too big.
GlastRelease: (Richard)
Overlay (Heather) All overlay tags are in v17r2p1. v17r3 will have latest tags from Leon: HepRepSvc, astro and AnalysisNtuple.
(Tracy) One last problem cropped up: OnboardFilter is getting trigger bits from the wrong source because EbfWriter overwrites them at an inconvenient time. (Philippe) Johann had asked me to check the first 1000 files. Then Tracy confirms that v17r2 overlay has this TriggerAlg/EbfWriter problem. So I sent an email to the thread saying that the obvious decision was to stop the big production.
Disk space:
Documentation: (Chuck) sends this report:
There is no 'new' news from WB World this morning. I'm continuing to work on the ACD, TKR, CAL overview and, while progress is slow, there is progress.
Pipeline concerns: (Anders) One event crashed in Recon after having processed a billion events with that tag of GR. The problem is in GcrSelectTool. For more details see JIRA CAL-18. The GCR problem has been understood and Johann has provided a bug-fixed version. There is still a problem in that the CalCluster energy is 'nan' in the event that crashed. Under investigation.
When do we get the new LDF in GlastRelease? (Heather) Since GR v15 we have had the new LDF external library included in GR. However, we still need to flag the TEM bug by providing both a data member on the TDS and one in digi ROOT. Heather sees what to do and now needs to do it, before Anders feels the need to motivate her.
(Anders) We need a way to ensure that the right version of packages common to GR and ST is picked up for any particular application. The problem was discovered when we mistakenly used the GR version of astro, which does not have the leap second correction. That can be fixed; the more difficult problem is that there is code like ft2Utils which depends on both GR and ST. (Jim) Using a static library will take care of it. It would only be necessary to use a static library for one of GR and ST. (Heather) proposes we make it static in GR if there are no objections.
Skimmer and Reprocessing: (Heather) The upcoming merit-only reprocessing is intended to use a current GR that uses ROOT v5.20.00-gl1. This will mean that the merit files will be written using 5.20, while the original digi, recon, relation ROOT files will have been written using ROOT 5.18.00c-gl1. In principle this should be fine. However there are conflicting reports as to whether one can read merit ntuples written by ROOT 5.20 using 5.18. In addition, there are questions to be answered for the skimmer. The web-based skimmer only deals with merit files and in talking to Tony, it seems our best policy is to make the skimmer built against the latest Fermi supported version of ROOT the default. Users could then utilize the advanced options to modify the version of ROOT used. The command line version of the skimmer allows one to skim/merge both merit as well as the full (digi, recon, relation) ROOT files. By default, the version of the XXXRootData libraries used to read the full ROOT files is determined by the header in those files, in that case, we may mistakenly pick up libraries compiled against an older version of ROOT, when we are running a skimmer built against a newer version of ROOT. Some testing needs to be done, and then our needs communicated to David Chamont.
RM and friends (Navid) reports:
I have put in place a build cleaning system for SCons. It removes files from the build that aren't necessary for running a build. Currently it's enabled for ScienceTools LATEST builds only and it keeps the latest 2 builds fully while all other builds are erased so they only include files necessary for running.
I've also been working on windows build submissions and have made some progress. Builds are now getting submitted to windows correctly but I still need to store mysql passwords on the disk somehow so the RM programs can log into mysql. In linux this is simply done by storing a config file in the .ssh directory which is secure. On windows I have asked the windows admin folks for suggestion on how to do this. One idea might be to store it in the registry.
(Jim) Are there any usable Mac builds? (Navid) thinks a couple of LATEST builds made it all the way through.
SCons & Windows (Joanne) The last couple problems with building and running on Windows with SCons have been addressed, thanks to help from Heather and Navid. See latest entries in the log for more detail. However, my development environment — Express edition of Visual Studio 9.0 rather than Professional and vs_revamp branch of SCons rather than any production release — is not easily reproducible or very friendly for typical users. The non-standard SCons is the bigger problem. Gossip in the SCons developer mailing list is that the next production release of SCons, 1.3.0, will have the new Windows support.
ROOT Mac build (Emmanuel) reports:
I have ROOT v5.20.00 installed, and now I am testing it. Problems encountered during testing:
- Python could not find the ROOT module
- Solution: Copied ROOT.py over to <PYTHONROOT>lib/python2.5/site-packages. In principle, pointing the PYTHONPATH variable to the location of ROOT.py should also work
- Python could not find the libPyROOT module
- Solution: ROOT needs to be built with the "--enable-python" configure flag set; then libPyROOT.so will be built.
There were additional stumbling blocks:
- In order to build libPyROOT.so, I had to add an additional option to the configure script, "--enable-python." Adding, "--enable-python," to the configure script caused the configure script to fail because it could not locate libpython2.5.a The reason being that the configure script computes the python version based on the python binary it finds in the system "PATH" variable.
- I had to prepend the path to the python (2.5.1-gl1) binary to the "PATH" environment variable so the configure script would use the appropriate python executable to compute its version.
previous | minutes index | next |