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