1. is a problem. I am surprised.
2. vertex is defined with WC tracks. by say the electron. If there is no WC
track, one can use target center, but that is a +-10cm vertex resolution as
opposed to +-2.5cm right now. Since TB spotted a problem in Blast_Param which
screws up proton momentum reconstruction, maybe with the correct environment
setting, we can do better than +-2.5cm in data already.
Quoting vitaliy ziskin <vziskin@MIT.EDU>:
> Chi,
> The problem right now is that lrn does not fill the dst for the MC
> data. I agree that dst is a perfect venue to analyze blastmc tracks, if
> only they were filled into the dst. The reason I think the dst is not
> filled is because I got a total number of entries 0 when I did
>
> TFile f("dst-***.root","r")
> TChain *ch = new TChain("dst")
> ch->Add("dst-***.root")
> ch->GetEntries()
> I get zero. The dst is not filled.
>
> Cheers, Vitaliy
>
> P.S. I have one more problem. When I turn of newton, fast fit and
> Pid I get now neutral track information. Is there a way to turn off
> swimming but still have neutral/detector tracks?
>
>
> Chi Zhang wrote:
>
> >Hi all
> >
> >1. I just did this in blast account:
> >
> >
> >
> >>root dst.C 6992
> >>
> >>
> >[] epics->Draw("fEics_Beam:fTime")
> >[] dst->Draw("fTracks.fP", "fTracks.fP<1&&fTracks.fP>0")
> >[] scaler->Draw("fBG_Rate[1]:fTime") // trigger type 1 rate
> >[] scaler->Draw("inhib_charge_p.fElement[0]:fTime") // charge on helicity+
> >
> >they drew reasonable spectra. The catch is that libBlast.so needs to be in
> >current dir or the load path. there will be some complains about missing
> >branches when a later version of library is used. but you have to give
> credit
> >to ROOT people for the "automatic schema evolution" which figures out the
> >missing entries in earlier versions and skip them without screwing up all
> other
> >entries.
> >
> >the entry names are made such that they are self explaining. do:
> >[] epics->Print()
> >[] scaler->Print()
> >[] dst->Print()
> >[] chg->Print() // some per fill information
> >
> >to see what are in the Trees. But this makes the names long and typing them
> on
> >command line a bit of a pain. Filter macros which creating reduced ntuples
> from
> >DST are probably life savers on this issue.
> >
> >There are some more "exotic" information which require the indexing like
> the
> >"fElement" for TMatrix stored.
> >
> >2. the problem Vitaliy had is because there is not charge tree in DST from
> MC. I
> >remember fixing it, but maybe I did not. I ll check.
> >
> >3. If I just checked in a macro called buf.C to BlastLib2 which shows how
> to
> >process epics info from DST. Also there are probably now a handful macros
> in
> >BlastLib2 by Eugene and Chris that handle physics events and pull out
> tracks
> >and hits.
> >
> >It does not work without a gliche yet but it can already do a fair amount.
> >
> >In reply to Taylan,
> >
> >1. I think DST now contains all and more information in any of the
> >sub"-data-structures. In principle, we can scratch flr, and ep_skim,
> generate
> >them from DST. lr is a different story as it constains no-track events.
> >Including those events into DST would explode the file size( probably not
> as
> >bad now that we have second level trigger).
> >
> >2. All the extra files are produces because they do not require
> significantly
> >more CPU time and other resource, and they keeps our backward compatibility
> >with only two grad student working days for the coding, which is negligible
> >amouunt of work. :)
> >
> >3. Documentation is lagging behind. I hate write documentations so a lot
> of
> >times I wait till it is LOOOOONG over due. like I said there are a handful
> >macros. One of the bare-bone I checked in is called dst_kfac.C. the
> function
> >Fill() in there shows how to open files one by one and get informations on
> >tracks out. Note neutral tracks are treated the same as WC tracks. with the
> >newly checked in buf.C, they show how to access both epics and physics
> events.
> >Some of the macros, like dst_viewer.C need to be updated as they do not
> reflect
> >the better way to do things implemented later. I will do this as soon as
> >possible.
> >
> >4. I claim no expertise in TTrees and TFiles, I personally hate them. I have
> yet
> >to figure out how to split DST files in a recrunch. but they get the things
> >done without having to rewrite 100k lines of codes.
> >
> >
> >Chi
> >
> >Quoting vitaliy ziskin <vziskin@MIT.EDU>:
> >
> >
> >
> >>Does the dst work will blastmc? I can't seem to open it. The problem
> >>is that unlike simple lr ntuple dst is virtually impossible to debug.
> >>So if there is a problem, like the one I have right now it very hard to
> >>just load the root file manually and look at it.
> >>
> >> Cheers, Vitaliy
> >>
> >>P.S.: Here is what I get when I try to run dst.C on blastmc generated
> >>and lrn rectrunched dst:
> >>
> >>n1=1001
> >>n1=1001, n2=1001
> >>/net/data/5/scratch/vziskin/data//dst-1001.root
> >>summary: nsets=0, runlist=1001,
> >>
> >>warning: dataset 0 has no data
> >>parameters:
> >> nsets 0
> >> nevents 1000000000
> >> runlist:
> >> title:
> >> legend: 0
> >> normalize: 0
> >> scale_hist: 0
> >>
> >>Error: Symbol chg is not defined in current scope
> >>FILE:/net/data/5/scratch/vziskin/BLAST/exp/analysis/utils/dst.C LINE:15
> >>Error: Failed to evaluate chg->SetBranchAddress("Fills",&flhd)Possible
> >>candidates are...
> >>filename line:size busy function type and name
> >>*** Interpreter error recovered ***
> >>
> >>
> >>Chris Crawford wrote:
> >>
> >>
> >>
> >>>hi vitaliy,
> >>> i'ts called the dst. the lr-ntuples are not intended to be the
> >>>principle data-structure from the recrunch. if you want the
> >>>possibility of a variable number of tracks, you have to live with a
> >>>tree structure. you probably want to create you own ntuple with some
> >>>(e,e'n)-specific structure from the dst. if you haven't already done
> >>>this, chi has some examples that can help you out. and if needed, it
> >>>can be added to the list out output ntuples from lrn/lrd.
> >>>--chris
> >>>
> >>>vitaliy ziskin wrote:
> >>>
> >>>
> >>>
> >>>>People,
> >>>>Is there a way that we can move away from this archaic left-right
> >>>>ntuple system. I find it very limiting for what I'm trying to do.
> >>>>Let's face it left-right ntuple was fine for e-p elastic , but when
> >>>>you have more then two particles possible in your acceptance, it
> >>>>becomes a liability. Is there a way to move from sector based
> >>>>information to particle/pid based information?
> >>>> Just a thought, Vitaliy
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST