This page gives a brief overview of the code Frank Simon developed to create SMD Status Tables from MuDSTs.

Some features and limitiations of the code:

• Create one status table per fill for each SMD plane (if enough statistics are available)
• all triggers are used to maximize statistics (this can be a potential problem if there are hot trigger towers)
• pedestals are taken from the data base (MuDST SMD data are zero-suppressed)
• db-readable status tables can be created. Currently there are only to status flags implemented: good and bad. Adding more "variety" is straigth forward
• can be used with the STAR scheduler, no specific ordering of the input files required (although some structure in the job submission is recommended, see below)

Basic ideas behind the code:

• based on Daves tower status code, but: there are some very important differences
• One job runs over several MuDST files, when a new fill number is encountered, a new output file is opened. That way, the jobs can be run with the STAR scheduler and they can use files on distributed storage, since no particular ordering of the input files is needed
• for each fill, a file with 18000 channel TH2Fs storing amplitude information for each SMD channel is created (this method of dealing with random file order is a bit disk space hungry, so make sure enough space is available (~ 10 GB for 2005 pp); this can be deleted after the next step), other information such as time stamps and pedestals are stored in text files
• As a next step, the large number of files created by jobs on MuDSTs is consolidated into one file per fill
• Status tables are created from each of those files (one per fill, if statistics are sufficient, otherwise no status table for that fill is created)
• db readable files are produced from these status tables

Running the code

• Copy and compile the code in StRoot/StBSMDStatusMaker
• Copy the macro that runs the code: RunStatus.C
• Create scheduler scripts to submit your jobs. For pp2005, 50 jobs per job seems to give jobs with useful runtimes. In order to not get a totally randomized fill distribution in your jobs, submit them by day. A macro that creates a .csh that you can use to submit jobs by day is CreateSubmitScript.C, a template job describtion (you have to modify tha paths to suit your needs) is pp2005Template.xml
• Submit your jobs
• Once all jobs are done, create a list of all output files via ls * > FileList.list in the directory where your output ended up
• Consolidate data using the file list: run macro DoAdding.C after compiling AddHistograms.C (via .L AddHistograms.C++), this macro takes the directory where the files are located and the file list as arguments. This creates three files per fill: Fill*.root containing the histograms, Fill*.ped containing pedestal db information and Fill*.time containing the (approximate) start time of the fill
• Create a list of root files via ls Fill*.root > FileList.list and convert it into a list of fill numbers using the macro GetListOfFills.C. This maco takes the file list and a file name for the fill number list as argument
• Perform the status table creation. For that, compile the shared library StatusTools.C (via .L StatusTools.C++), then run the macro ProcessList.C, with arguments RunList (created previously) and the directory where the Fill* files are located. The output of this is a number of files per fill (root file, flag file and time stamp file). The flag and the time stamp file are needed to create the db readable status table, the root file contains histograms created during the analysis process.
• Create db readable status tables. This is done by running the macro WriteStatusFiles.C. This takes the directory where the flag and timestamp files are located as an argument. Two important notes:
  • This macro needs the full STAR environment (all other steps above except the running of jobs can be done on standalone machines)
  • The order in which the flag and time files are written (created) is crucial, since gSystem->GetDirEntry() is used to loop over all files. So care has to be taken if the files are copied from somewhere else
• Copy the db readable files to the database location in StarDb, and test them! Use TestStatusFiles.C for example.

For questions, please don't hesitate to contact me at fsimon@mit.edu!