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