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.
> >
>
>
|