1 / 6

PROOF Reconstruction: input and output file handling

C.Cheshkov 30/09/09 Weekly Offline Meeting. PROOF Reconstruction: input and output file handling. Raw-data input. AliRoot now handles the following syntax of input raw-data files collection: “collection://XXX.xml” - collection file generate for example by alien find comand

cicely
Download Presentation

PROOF Reconstruction: input and output file handling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. C.Cheshkov 30/09/09 Weekly Offline Meeting PROOF Reconstruction: input and output file handling

  2. Raw-data input • AliRoot now handles the following syntax of input raw-data files collection: • “collection://XXX.xml” - collection file generate for example by alien find comand • “collection://XXX.root” - ROOT file with entry-list(s) generated for example by a tag analysis system • “collection://XXX” - text file generated by querying alien or any other means • In PROOF we usually use the last one: XXX file generated by a simple shell script, however other methods should also work

  3. Raw-data input: proposal • Allow simpler usage (for the shifter): • “???:///alice/data/2009/LHCXX/run#/raw/” • “raw://run#” (similar to OCDB syntax) • “run#@alien://...” • Other proposals?

  4. Output files • At the moment we have only AliESDs.root and Merged.Qa.Data.root as output files • The output location is controlled via AliReconstruction::SetOutput(“...”) • QA file follows the location of ESD file • The present interface is not flexible, doesn't allow storing of additional files

  5. Output files • We can have quite a lot of various combinations: • Store merged ESD [and QA] on the client machine (when SetOutput not used), needs xroot daemon running locally • Store merged ESD [and QA] on alien in user's folderSetOutput(“alien:///alice/cern.ch/user/x/xxxx/AliESDs.root”) • Stored merged ESD [and QA] on CAF scratch space? • Store ESDs [+other files: QA,RecPoints,...] in a folder with one subfolder per worker (local,alien), not needed? • Store ESDs in a registered dataset on CAF • Store ESDs [+ other files: QA,RecPoints,...] in a registered dataset on CAF • Only the first two ways are implemented now

  6. Output files: proposal • We need some simple and already established output files URI syntax (preferably an 'alien-like'): • “AliESDs.root,Merged.QA.Data.root” - on clien machine • “alien://..../AliESDs.root,alien://.../Merged.QA.Data.root” or “AliESDs.root,Merged.QA.Data.root@alien://....” - merged output files in alien • “AliESDs.root@dataset:MyRun” - ESDs in a registered dataset on CAF • “root_archive.zip:AliESDs.root,ITS.RecPoints,...@dataset:MyRun” - prepare root_archive.zip on the workers and registered the dataset containing all the requested files • Other proposals?

More Related