Re: [Brahms-dev-l] new brat version and global tracking stuff

Hi Djamel,

Please, read my comment below.

Djamel Ouerdane wrote:

>Hello,
>
>I have updated brat to version 2.17.8, tag BRAT-2-17-8.
>
>I basically added an option to BrModuleMatchTrack, namely the possibility 
>to evaluate matching offsets at Finish(), save them to an ascii file and 
>read the latter at Init in a second pass.
>
>Technically:
>
>1st pass
>BrModuleMatchTrack::SetFitOffset(kTRUE); // false by default
>BrModuleMatchTrack::SetOffsetFile("<some file">); 
>
>
>2nd pass
>BrModuleMatchTrack::SetReadOffset(kTRUE); // false by default
>BrModuleMatchTrack::SetOffsetFile("<some file">); 
>
>An exemple of how this can be used (and hopefully in an official way) can 
>be found in 
>
>~ouerdane/ana/run04/gtr
>
>I have there two bratmain scripts (TrackOffset.C and GlobalTracking.C) 
>and a bash script for LSFjob submission.
>
>Now, the neat thing is the following :
>
>This bash script goes in two step:
>step 1: matching offsets by group of 2 sequences
>step 2: global tracking using tmp offset files from step1
>  
>
This is very good, but remember that high field runs might require more 
than 2 sequences to
obtain a reasonable statistics to make a fit. I would sugest to add 
criterium related to the number of tracks (track's combinations).
More general question: how do you fit if the matching peak seats
on the large combinatorial background?

Cheers
Pawel.

>trick: all jobs are launched together (offset and global tracking) BUT the
>generated glb track scripts check every 5s that the offset file exist
>before bratmain is launched. That's neat because it does not depend on the
>whole bunch of sequences but only on the specific sequence that is
>processed!
>
>
>In clear: when the offset job is done for e.g.  seq 0-1 (I grouped offset
>jobs by two sequences), the corresponding offset file is produced. The
>global track jobs (for seq 0 and independently 1) are then launched
>automatically right after the file has been produced. The advantage is 
>that if some parameters fluctuate a bit within the same run, this would 
>catch it :)
>
>Now, there will be no more mess about which offset files were used since
>offsets are generated quasi "on the fly". The other advantage is to get
>rid of some ugly hack, namely the old BrMatchingOffsetModule...
>
>
>One drawback: if an offset job crashes for a reason (who knows ?), the 
>corresponding global track job will wait forever since the tmp offset file 
>could not be produced. But this should only happen if we're "unlucky" :)
>and bkill 0 is easy to type :)
>
>The last thing: the bash script respects the file catalog convention, 
>namely : picks up the latest version of the local track files and produces 
>the highest  gtr file version number possible (0 if no other version 
>exists already in the official dir - data07 for those who don't know yet).
>
>One can also specify the production number, user's decision (p = 1 by 
>default). By the way, it would be nice to know more about the file catalog 
>soon.
>
>
>Oh yes: in my bratmain scripts, I used Flemming's modified geometry. 
>Hopefully, this will make its way to the geom DB.
>
>That's it.
>
>Enjoy
>Djam
>
>
>
>  
>



_______________________________________________
Brahms-dev-l mailing list
Brahms-dev-l@lists.bnl.gov
http://lists.bnl.gov/mailman/listinfo/brahms-dev-l