VUB-RECOIL Archives

Vub measurement using recoil of fully reconstructed Bs

VUB-RECOIL@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Urs Langenegger <[log in to unmask]>
Reply To:
Date:
15 Apr 2004 15:16:46 +0200Thu, 15 Apr 2004 15:16:46 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (81 lines)

Hoi Thorsten,

maybe you two should subscribe to this mailing list. 

 > Even though that may be technically possible, it may give you the wrong answer :
 > Not that "CM2-converted" data is not really a conversion, it is a re-processing
 > starting with the release-12 mini, but using a lot of new reconstruction
 > algorithms. Especially for the muon-id, the extrapolation of tracks through
 > the IFR is very different in CM2-converted data (or MC). So
 > 
 >                   "SP5-Objy != CM2-converted SP5"


Apparently there was a discussion about this at the PAC meeting and it
seems that  "they" considered it OK  for analyses to use  OBJY SP5. Is
there a solution to this? (Apart from dropping muons? :-)


 > What has been the strategy so far ? One run per file ?
 > 
 > In CM2, there are usually many runs per collection, and so far I did not manage
 > to squeeze out tcl files which process single runs (or a self-defined run range)
 > from a given collection. Does anybody know how to do this ?

Even in the old setup long runs were too CPU-intensive to fit into one
job. The solution was to split the jobs, running only over n events in
the first tcl, while skipping the first n events in the second job. It
has been advertised that BbkDatasetTcl  can generate tcl files to cope
with that problem. We have not validated anything, so far.  Henning is
working on this.

 > Also, it seems that in it's current state, BbkDataSetTcl delivers somewhat
 > unordered tcl-files, in the sense that subsequent "input add" lines do
 > not contain collections which are subsequent in terms of run numbers.

As long as  we don't double-count, loose event  or cross RUN-{1,2,3,4}
boundaries in one tcl file, there  is no problem if the events are not
time (or run) ordered.


 > >         + The  size of  the tcl  files needs to  be optimized  for the
 > >           queue length. (kanga?)
 > 
 > You should contact the experts about that. In our PID-tuple production, the
 > only reasonnable queue was "bfobjy", which we were told was "illegal". However,
 > kanga and xlong had too few machines assigned at that time. Maybe it has changed
 > in the meanwhile ???

I think  the official policy for  SP5 OBJY would still  be bfobjy, and
CM2 would  be non-bfobjy.  I am  sure they'll tell  us when  we commit
crimes.

 > >         the  unskimmed SP5  OBJY  (700/fb!) on  a relatively(?)  short
 > >         timescale.
 > 
 > One more comment about "unskimmed" data. If you have collections which are
 > the output of a "Release12 -> CM2" conversion, you should be aware that
 > the tag-part of the data has NOT been converted. So raw "converted CM2"
 > data
 > still contains the tag-bits as they were in release-12. No re-computation
 > of the tag bits is done during conversion. This is why we are supposed to
 > use the skims. In the skims (including the "AllEvents" - Skim), the tag
 > bits are correct.

Good to know! The  plan is run on skimmed CM2. At  least the data. Not
sure yet about SP6.


 > BTW, how are people using these ntuples ? Are analyses run directly from these
 > ntuples, or does each analysis have its own set of "reduced ntuples" which
 > are extracted from these "event-store" ntuples ?

I don't know of anybody who does not produce reduced ntuples. 

Cheers,
--U.




ATOM RSS1 RSS2