- jkadkins's home page
- Posts
- 2018
- 2017
- 2016
- 2015
- 2014
- December (3)
- November (2)
- October (4)
- September (7)
- August (2)
- July (3)
- June (1)
- May (4)
- March (4)
- February (3)
- 2013
- December (2)
- November (3)
- October (3)
- September (4)
- August (2)
- July (3)
- June (1)
- May (2)
- January (1)
- 2012
- My blog
- Post new blog entry
- All blogs
Complete BEMC Status/Pedestal Table Docs
This blog will serve as documentation for the BEMC status/pedestal pre-production task that should be completed by the BEMC coordinator and their assistant for this task. This task must wait for the end of the run to make status/pedestal tables for each fill, but should be completed before production begins.
There is some documentation prepared previously by Alice Ohlson that will get the user up and going. It tells what needs to be updated yearly and how to run the code from the terminal, and that really doesn't change across the three different variations of the code (see below). It can be found here:
- Status/Ped Code Startup Procedure
- Status/Ped Table QA Procedure
It should be noted, though, that there are three versions of this code currently for various reasons. So the startup procedure should be followed exactly, but by choosing the appropriate "previous version" of the code. For instance, the example uses 2012 as the code to copy over and set up for the new run, but the following three codes may instead be used depending on the amount of L2 output available for the current run. Let me elaborate on all three versions, and what for what scenarios they are useful (note this assumes the user has access to the onlXX machines).
1.) Status/Pedestals via L2 pedestal files: This is the most common method which takes an input file (L2 pedestal log file) and uses the information in it to create status and pedestal tables. If there is L2 pedestal output for every fill, then this version should be used. The most recent version of this code is found on the onlXX nodes in /ldaphome/onlmon/emcstatus2014/AuAu200/l2status.py (an the supplemental codes noted in above documentation.
Note: This version of the code for run14 suffered from a mapping problem found in the BEMC. Because of this, if this code is used in the future, the function __softIdSwap(self,softid) should be removed as well as any reference to it in the body of the code. This mapping problem was fixed after run14.
2.) A version of the code that takes in "hist.root" files that were created from emc-check daq files. The emc-check runs should be taken yearly, and give a good view of the BEMC at the start of each fill. In 2013 this was used because L2 failed to produce adequate events (assumed to be caused by too many triggers in the mix), so we used the emc-check runs. Mike Skoby produced the hist.root files from the DAQ files. Documentation for that procedure was written up by Mike, and is linked here:
Mike Skoby's DAQ Reader Documentation
Note that the emc-check method for statuses and pedestals may be found on the onlXX nodes in /ldaphome/onlmon/emcstatus2013/pp500/bemcStatus.py (and associated codes mentioned in above documentation - note the name change of the python code, this was purely to avoid future confusion, the body is the same form as with L2)
It was for this method that some further QA and preparation/running documents were prepared. They are attached to this blog post. Note: This documentation also greatly applies to all methods, it would be useful for anyone to have a look that will be working with status/ped tables.
3.) A version of the code that takes in "hist.root" files created from MuDst files. This method should be used as an absolute last resort (no L2 and no emc-check runs, as in 2014), because MuDst files apply gain tables, which mask out some towers. This version of the code may be found on the onlXX nodes in /ldaphome/onlmon/emcstatus2014/AuAu15/l2status.py (This DOES NOT use L2, but it was not renamed in 2014). Note: See the above note in 1.) about the mapping, this note applies here too! The hist.root files were created by me for this procedure, and the code for it can be found on RCF in the directory /star/u/jkadkins/bemcStatus2014/. The procedure for creating files from MuDsts on an RCF node follows. If one doesn't have a list of MuDst filenames, they would have to make further changes to the xml file to read from the file catalog.
1.) Copy over the contents of /star/u/jkadkins/bemcStatus2014/ to a place that you like.
2.) Compile with "cons"
3.) In the submitdir/ directory, change the location of the RunBemcAdcMaker.C and .sl64_gcc47 (or the name of the compile directory).
4.) In the submitdir/directory, change the location of the output files in the last four lines of the XML.
5.) In the submitdir/directory, change the name of the file list in the submitFromList.py script (You should also copy your file list to this directory)
6.) If all of the changes are correct, run the submit script with "nohup submitFromList.py >& report.txt &"
Once all of the hist.root files are complete, you'll need to scp them to the online machine you're working on into the histoFiles/ directory (which lives in the same directory as the status code).
Thats it! These three methods for status and pedestal tables should cover all cases. This documentation will be expanded as necessary.
- jkadkins's blog
- Login or register to post comments