LISTSERV mailing list manager LISTSERV 16.5

Help for VUB-RECOIL Archives


VUB-RECOIL Archives

VUB-RECOIL Archives


VUB-RECOIL@LISTSERV.SLAC.STANFORD.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

VUB-RECOIL Home

VUB-RECOIL Home

VUB-RECOIL  February 2007

VUB-RECOIL February 2007

Subject:

Re: b->sgamma pseudo truth matching

From:

Kerstin Tackmann <[log in to unmask]>

Date:

4 Feb 2007 10:32:20 -0800 (PST)Sun, 4 Feb 2007 10:32:20 -0800 (PST)

Content-Type:

TEXT/PLAIN

Parts/Attachments:

Parts/Attachments

TEXT/PLAIN (116 lines)


Hi Francesca,

-- I'll put this one to the vub-recoil list, too, so others can contribute
if they wish... --

> > > as I mentioned at today's meeting, I just want to bring up how we did the
> > > truth-match in the b->sgamma analysis (that we call indeed pseudo
> > > truth-matching).
> > >
> > > The details are on BAD 768, v16, section 7.6. We distinguish between the
> > > fully truth matched events (for which all the daughters are truth matched
> > > to the B), and the onces which are not fully truth
> > > matched (where the reconstructed track have an associated GHit, and the
> > I am not sure I understand what you mean (I also read the part in BAD
> > 786). I assume you mean you do not require every track to be truth
> > matched using the standard truth matching (I think there a track is called
> > truth matched if the true track caused the majority of the hits that
> > are making up the reco track.). I guess you do *not* mean that your first
> > category leaves out tracks once they have a single hit that is not
> > truth matched to the right particle. Is this correct?
> > The "have an associated GHit" is the formulation that is confusing me...
>
> yes, you are right. We say in the BAD 'associated GHit', but we actually
> mean truthmatched track, with whatever is the number of GHits required.
>
> >
> > > reconstructed final state is the same than the true final state), and for
> > > which the reconstructed hadronic mass is within 50(25) MeV away from the
> > > true one.
> > > The sum of all the events makes the whole of the pseudo truth matched
> > > events.
> > >
> > > In our case, this method worked well. Could it be feasible for the
> > > semileptonic events? Do you see any drawback?
> >
> > Requiring the modes of the true and the reco'd B was actually our
> > previous truth matching and we found this too strict for the
> > 2 PDF mES fit, we need to be looser than this.
> >
>
> What actually we had in b2sgamma are:
> -fully truth-matched events: the tracks are truthmatched and asked to come
> from the true B
> - "pseudo-truthmatched" events: the tracks are truthmatched, the recoed
> final states is asked to be identical to the true B final state (we do
> not ask that the tracks come from the true B), a cut on
> mX is applied. The events which fail the cut are our cross-feed
> background, which mainly means a peaking background.
>
> We take all the events which pass at least one of the two criteria.
>
> We had at most 4 particles in the final state plus the gamma.
>
> > Concerning looking at the reco'd mass:
> > So in our case we would look at the difference of the generated and
> > reco'd mES if we wanted to follow this method as closely as possible?
> > I guess we could try that, however, I wonder if it is a good idea.
> > Loosely, this would mean to restrict the truth matching to about the
> > mES signal region. While this would probably allow us to get a truth
> > matching that looks nicer (I did look at this in December), we loose
> > the mES tail for telling us how well we really do.
> >
> > Does this seem to make sense?
>
> I think one needs to look at the difference between the true and the
> reconstructed mass and see how close there are. It could be that one
> doesn't really lose the tails of the events if the cut is wide enough. BTW, the
> cut should be dependent on the number of particles of the hadronic system.
>
> However, I really have the suspicion that if one applies this method will
> necessarily have a peaking background, so most likely will need to go back
> to the 3D PDF.

Yes, probably. However, from the studies Antonio showed earlier this
year we concluded that even on the high statistics samples the 3 PDF fit
was unstable and if I am not mistaken we decided that we were going to
abandon this approach...

I think it makes more sense if we first fix our fit strategy and then
find the best possible truth matching and not vice versa...


> Kerstin: where can I find your study regarding the mass cut?

Unfortunately, there is nothing I can point to. I just played with
this a little and did not keep the results... sorry. While it looked
nicer, it did not seem very sensible, since by just cutting at mES
I was free to do whatever I wanted and it seemed too arbitrary to
me. Your cut on the difference makes more sense to me, so we should
rather try that I think.

> > But I do think that an improvement of the current truth matching
> > is more than welcome!
> >
> > Maybe it would be useful to move this discussion to the vub-recoil
> > list to allow other people to contribute/follow.
>
> OK, I will forward all the emails to the mailing list.
>
> Unfortunately I will have another meeting starting at 8:00 on Tuesday so I
> am not sure I will manage to attend the vub-recoil meeting.
> If not possible, can I just call you and/or whoelse is interested
> to have a chat on Tuesday after the meeting? I guess I would be
> free only around 10:00-10:30.

I have time until 11:00am. So we could do it until 11:00am, if we
think that's enough time to start or we can do it on Wednesday or
another day this week.

Cheers,
Kerstin



Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

March 2010
December 2009
August 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001

ATOM RSS1 RSS2



LISTSERV.SLAC.STANFORD.EDU

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager

Privacy Notice, Security Notice and Terms of Use