The high number of events with IERR < 0 came from a different definition of overlap we have now in our root files. now track belongs only to the first B -> bit word = 1 before track belongs only to the first B -> bit word = 2 same shift if the track belongs to the second one (now 2, before 4) may anyone confirm what I see? Daniele > > The first look at the job run by Urs with the breco overlap fix in is not > good. > > I got ~4% of IERR < 0 events (usually they are of the order of the 0.2%). > This is a clear sign that something is screwed up in the overlap flag. > > > Daniele > > > > > > Hoi, > > > > 1. PidKilling was still running with the old PidKilling setup. This is > > fixed by sourcing the correct tcl in IbuIsl.tcl: > > > > #old sourceFoundFile BetaMicro/BetaMicroSmear.tcl > > sourceFoundFile BetaMicro/BetaMicroPidKilling.tcl > > > > 2. PidKilling crashes in MuonMicroKillDispatch::BtaMicroMapCreator.cc. > > No solution to that yet. I think we use the output of the dispatch > > module when filling the ntuple. > > > > 3. Our low-level tcl is (imvho) a bit suspect: We get the PidBuildEnv > > from the Roo implementation and not the Bta version. This is most > > probably not what we want (though it might not hurt). I guess this > > happens maybe at the islNew.tcl level (or in the initial > > reading-setup tcl sourced by that tcl file). This was discovered > > by cleaning up things, in particular doing > > > > mod disable RooBuildPidEnv > > > > We are missing printouts like > > > > BtaBuildPidEnv::AbsEnv.cc(334):Overriding BtaEnv object in global environment. > > DchBuildEnv:mapconfig = dch_dtag > > DchBuildEnv:mapfile = DchMaps/dch_dtag.map > > DchBuildEnv: Configuration database disabled for channel maps > > DchBuildEnv: Configuration database disabled for MapBrowsers... > > SvtBuildEnv:BdbCondPathSingleton::loadFromConfigFile() -- info. > > A configuration file describing a revision/owner path was not found. > > Assuming the default behavior of BdbDatabase::fetch() interface -- > > the most recent version of the condition data will always be > > fetched from the database. > > SvtBuildEnv: Pulse height ratio cut is 1.1 > > > > > > I have heard that other people have successfully implemented the > > recipes for PidKilling. Given the problems in the BuildPidEnv, I tend > > to suspect that our low-level job setup is maybe at the source of the > > problems. > > > > > > A few jobs are running on data, they'll end up in > > > > ~ursl/output/sx-080202/. > > > > These are with the RooBuildPidEnv, but should be sufficient to test > > the breco overlap business. > > > > > > Cheers, > > --U. > > > >