at the moment I see the following:
- overlap calculation seems to be fine for tracks
- many times the overlap fails for gammas
1) we count 3 gammas using the overlap instead of 4 (2 pi0's) counting
directly from the breco side. Probably this is related either with
the merged pi0's or with the fact that we have the same photon
in the pi0 from the D and the one from the B.
2) in breco modes with a pi0 both in the seed and in the X system (for
instance B->Dcpipi0 with Dc->kspipi0) in the recoil we often count
one pi0 less (2 photons instead of 4). Probably when we reconstruct
the B we use twice that pi0 (in the D meson reconstruction and in
B reconstruction).
I think Riccardo already know about these behaviours.
- in one event we can have two B0's with the same seed!!!! this should be
avoided since the idea was to have one B per seed maximum.
Daniele
On Mon, 5 Aug 2002, Daniele del Re wrote:
>
> 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.
> > >
> >
> >
>
>
