Re: [Brahms-dev-l] global tracking scripts

Hi Djamel

Hope you had a good trip.


Thanks for your observations. This is likely true, since the scriupts are
being setup and have note been
done fully. Since I assume you are responsible for the 63 GeV, and we should
do these first this should
be done and have talked to Pawel on the 200 gev.

I have taken responsibility for the pp scripts ltr, gtr and dst - and why
dont you do this for the
63 gev.
Then we can just copy the scripts to 200., which will be a longer process to
get done due to the pure magnitue f the dset (we cannot have all files on
disk at the same time toghet with older files.)
As far I know the gtr's are not done (in terms of being in the filecatalog)
 I am sure you have your own sets-
as is there is no simple way to put into catalog with re-running,
maybe we (you) should just do this, so the production can be done with
official scripts all the way through ltr-gtr- and dst with the F.C. and get
rid of the files generated otherwise. I think this is the only way to avoid
profilation of multiple files
and discussion where files are.

a few more comments below inlined



> Hello,
>
> Back from Holland, I'm now looking into getting production DSTs for the
> whole 63 GeV run. I looked at the bramreco scripts GlobalTracking and
> TrackOffset and noticed the following things :
>
> the run04 200 GeV and 63 GeV scripts are different. As far as I know, they
> should not, at least for AuAu. But maybe I am wrong.



>
> The BrMainModule::InitSetup() and SetupDone() are not there. I remember
> Flemming wrote something about that (to avoid crash in some cases).

This is just a convenience preventing jobs from running if they fail in
setup phase.
The should be added

>
> Now, more important : the method BrMOduleMatchTrack::SetOldFiducialCuts()
> is explicitely called for all FS tracking modules. The "fiducial point"
> saving I introduced becomes useless in this case because it is evaluated
> in BrMagnet::GetSwimStatus(...), which is the _new_ way to apply fiducial
> cuts.
>
> The MA module methods SetThreshold{Energy,Factor} are still there.

should be done.

>
> If root 4.00/08 is problematic, how about downgrading to 3.10 ?  Although
> it seems that root 4 is to be the pro version, I'm asking because I don't
> think root should be a major obstacle to getting proper DSTs soon, or is
> it ?
>

Kris and I have talked today - the problem is with the TInetAddress class in
root, and some fixes have been made already to the root cvs version. We
decided NOT to downgrade i) the fix for reading old files will definetely
work, and new files can be read, particular for dst's there is no issue at
all since those files do not have the BrFileTag member.

>
> One last request : can you Hiro or Flemming eventually run the ltr condor
> scripts for runs 11301,302 and 303 ? Thanks.
>


Will do (Hiro is at a workshop in NM)

flemming
> Djam
>
>
>
> -- 
> Djamel Ouerdane ------------------------------------------o
> |  Niels Bohr Institute      |  Home:                     |
> |  Blegdamsvej 17, DK-2100 Ø |  Jagtvej 141 2D,           |
> |  Fax: +45 35 32 50 16      |  DK-2200 Copenhagen N      |
> |  Tel: +45 35 32 52 69      |  +45 35 86 19 74           |
> |                  http://www.nbi.dk/~ouerdane            |
> |                  ouerdane@nbi.dk                        |
> o---------------------------------------------------------o
>
>
> _______________________________________________
> Brahms-dev-l mailing list
> Brahms-dev-l@lists.bnl.gov
> http://lists.bnl.gov/mailman/listinfo/brahms-dev-l
>


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