[Brahms-dev-l] Re: new 63 GeV files

Hi Flemming,

> a new set of 63 GeV local tracking files has been made. These are as far
> I know optimized for a) DC database calibrations b) bad pads in tpc's c)
> good Vdrift for all.

great :)

> 
> The are recorded in the filecatalog which more information will be
> forthcoming from Hiro. They are stored in the filesystem
> /brahms/data19/data/run04/auau/63/ltr (note not seq!) There are also
> named according to the official naming i.e
> ltr<run>seq<seq>v<version>.root

ok.

> 
> The are NOT produced by the masterreduction scripts but rather a set of
> new python scripts that submits to the new crs system. The naming of the
> <version> number is automatic being incremented when tracking is
> succesfully redone. This means that the <version> number can be
> different for different run's and still belong to the same production
> version. The concept of production version is also introduced. All files
> created now are of production version=1.
> 

if <version> can be != from <production>, where is the <production>
number? I can also see a drawback in the automatic incrementation:  since
jobs are submitted in a sequence basis, if for a given run, some jobs
failed, you might end up with sequence files of different version number
if you had already older ones.


> The scripts that produces global tracks have to be modified to pickup
> likewise 

> i) the newest (highest version no) for a given production ltr names

now you're talking about <production> and not <version>, is that correct ?

> ii) get the proper gtr name and version 

it's not only a question of composing the right file name string but
picking up the adequate (highest) <version> of a given <production>, right?
Then, should the gtr <version> be equal to the ltr <version> ? or should 
the gtr <version> be independent from the ltr <version> and have its own 
incrementation ?

> iii) The gtr files should reside on a different file system e.g. data07
> for au 63 GeV to minimize i/o on a given sun-server.


ok. 

> The geometry is done - even though not committed to the DB the modified
> geom is done in
> ~videbaek/brahms_app/fv_app/reco/run04/auau/globalTracking.C 

you mean 

~videbaek/brahms_app/fv_app/reco/run04/GlobalTracking.C 

Will the numbers that I could see in this file be submitted soon ?

> This does of course not work because the 'matching files now are no good
> any more. 

I guess so.

> - since these are found by running the same data, could one
> not then run the tasks by a) run matching alone -> determine matching
> offset for a given sequence b) run the same data once more within the
> same script having data in a local temp file. This avoids the DB for the
> matching which I think is good because the value dependes on
> calibrations of TPC, geometry, so whenever these changes the matching
> cuts changes.

I am aware of the DB issue. Let's see what we can do...

> 
> stay tuned. More to come


Djam


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