Hello. Regarding the file catalog database, I am planning to write a info mail after I finish making most of tools we need. But, here is the little clarification (some are done and other part is far from finished.) 1. Production version is not the same as the Version number. 2. The production version number for given data type (ltr, gtr, dst, etc..) and run period (1, 2, 3, 4 ..) is incremented only when a user decides to change it. 3. The production version is not the part of the filename. 4. The version number is incremented automatically. And, it is the part of the file name. 5. The directory and filename formats were previously agreed as data/runRunPeriod/Specie/Energy/rRunNumber/dataType/dataTypeXXXXXXseqYYYvVersionNumber.root (Random selection of directory is highly prohibited!!!) 6. The RunPeriod, Specie and Energy is automatically picked up from database (Runs table from RUNDB). 7. By default, a user uses the file with the highest version number for a given Production version. (This is meant to avoid a situation like. Someone analyze certain data files which he/she just found in the disks without knowing how they were made. And, he/she spent one week (or more) trying to understand what it really does not make sense. Then, somebody else tells him/her that he/she should not be analyzing those files. This seems to happen quite often.) 8. Database will keep track of the location of files. A user only needs to know what Production version and Run number. Right now, this is done by the script. But, we can also include in brat. For example, we can modify AddFileSet with arguments of Production Version and Run Number (and Optional Version number ). 9. Database will also keeps track whether a file is deleted from the directory. (This also facilitates removal of old files.) 10. Database will also keeps track whether a file is in HPSS. (This intents to facilitates the use of HPSS. Again, a user does not need to know if a file is in disk or HPSS.) That's it for now. Hiro (Note: After writing this, this file catalog sounds like a dictator. Maybe, we should call it FileDictator instead of file catalog. :) ) Djamel Ouerdane wrote: >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 > > _______________________________________________ Brahms-dev-l mailing list Brahms-dev-l@lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/brahms-dev-lReceived on Wed Jun 2 07:50:42 2004
This archive was generated by hypermail 2.1.8 : Wed Jun 02 2004 - 07:50:58 EDT