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