Data Monitoring Procedures
- 1 Master List of File / Database / Webpage Locations
- 2 SciComp Job Links
- 3 Saving Online Monitoring Data
- 4 Offline Monitoring: Running Over Archived Data
- 5 Explanation of Scripts
- 6 Running Over Data As It Comes In
- 7 Post-Processing Procedures
- 8 Data Versions
Master List of File / Database / Webpage Locations
- Online Run-by-run condition files (B-field, current, etc.): /work/halld/online_monitoring/conditions/
- Offline monitoring run conditions (software versions, jana config): /group/halld/data_monitoring/run_conditions/
- Run Info vers. 1
- Run Info vers. 2
Monitoring Output Files
- Run Periods 201Y-MM is for example 2015-03, launch ver verVV is for example ver15
- Online monitoring histograms: /work/halld/online_monitoring/root/
- Offline monitoring histogram ROOT files (merged): /work/halld/data_monitoring/RunPeriod-201Y-MM/verVV/rootfiles
- individual files for each job (ROOT, REST, log, etc.): /volatile/halld/offline_monitoring/RunPeriod-201Y-MM/verVV/
- Accessing monitoring database (on ifarm): mysql -u datmon -h hallddb.jlab.org data_monitoring
SciComp Job Links
Saving Online Monitoring Data
The procedure for writing the data out is given in, e.g., Raid-to-Silo Transfer Strategy.
Once the DAQ writes out the data to the raid disk, cron jobs will copy the file to tape, and within ~20 min., we will have access to the file on tape at /mss/halld/$RUN_PERIOD/rawdata/RunXXXXXX.
All online monitoring plugins will be run as data is taken. They will be accessible within the counting house via RootSpy, and for each run and file, a ROOT file containing the histograms will be saved within a subdirectory for each run.
For immediate access to these files, the raid disk files may be accessed directly from the counting house, or the tape files will be available within ~20 min. of the file being written out.
Offline Monitoring: Running Over Archived Data
Once files are written to tape we run the online plugins on these files to confirm what we were seeing in the online monitoring, and also to update the results from the latest calibration and software. Manual scripts and cron jobs are set up to look for new data and run the plugins over a sample of files.
Every other Friday (usually the Friday before the offline meetings) jobs will be started to run the newest software on all previous runs,and allows everybody to see improvements in each detector. For each launch, independent builds of hdds, sim-recon, the monitoring plugins, and an sqlite file will be generated.
Below the procedures are described for
- Preparing the software for the launch
- Starting the launch (using hdswif)
- Post-analysis of statistics of the launch
Processing the results and making them available to the collaboration is handled in the section Post-Processing Procedures below.
General Information on Procedures
Since we may want to simultaneously run offline monitoring for different run periods that require different environment variables, the scripts are set up so that a generic user can download the scripts and run them from anywhere. Most output directories for offline monitoring are created with group read/write permissions so that any Hall D group user has access to the contents, but there are some cases where use of the account that created the launch is necessary.
The accounts used for offline monitoring are the gxprojN accounts created and maintained by Mark Ito (see here for how each account is used). As of October 2015, the following are used:
- gxproj1 for running over incoming experimental data (as it hits the tape)
- gxproj5 for running over previous experimental data (biweekly launches)
For offline monitoring, the hdswif system that Kei developed is used for launching the jobs, and a new cross analysis system based on MySQL and Python is maintained.
The scripts for the monitoring are maintained in svn:
Preparing the software for the launch
1. Update the environment, using the latest desired versions of JANA, the CCDB, etc. Also, the launch software will create new tags of the HDDS and sim-recon repositories, so update the version*.xml file referenced in the environment file to use the soon-to-be-created tags. The new environment file is at:
~/env_monitoring_launch2. Setup the environment. This will override the HDDS and sim-recon in the version*.xml file and will instead use the monitoring launch working-area builds. Call:
3. Updating & building hdds:
cd $HDDS_HOME git pull # Get latest software scons -c install # Clean out the old install: EXTREMELY IMPORTANT for cleaning out stale headers scons install -j4 # Rebuild and re-install with 4 threads
4. Updating & building sim-recon:
cd $HALLD_HOME/src git pull # Get latest software scons -c install # Clean out the old install: EXTREMELY IMPORTANT for cleaning out stale headers scons install -j4 # Rebuild and re-install with 4 threads
5. Create a new sqlite file containing the very latest calibration constants. Original documentation on creating sqlite files are here.
cd $GLUEX_MYTOP/../sqlite/ $CCDB_HOME/scripts/mysql2sqlite/mysql2sqlite.sh -hhallddb.jlab.org -uccdb_user ccdb | sqlite3 ccdb.sqlite mv ccdb.sqlite ccdb_monitoring_launch.sqlite #replacing the old file
6. Note that the above steps must be done BEFORE launch project creation. This is because we will track the revisions of the libraries used, and this is done by extracting the svn information in each directory. Also, note that the system assumes that we have the topmost build directory (usually called GLUEX_TOP) to be $HOME/builds . Such an assumption is necessary to be able to extract information about the library locations automatically.
Create the appropriate project(s) and submit the jobs using hdswif, as detailed in the section below.
Starting the Launch and Submitting Jobs
1. Download the hdswif directory from svn. For the gxprojN accounts, use the directory ~/monitoring/hdswif.
svn co https://halldsvn.jlab.org/repos/trunk/scripts/monitoring/hdswif cd hdswif
2. Edit the job config file, input.config, which is used to register jobs in hdswif. A typical config file will look this:
PROJECT gluex TRACK reconstruction OS centos65 NCORES 6 DISK 40 RAM 8 TIMELIMIT 8 JOBNAMEBASE offmon_ RUNPERIOD 2015-03 VERSION 15 OUTPUT_TOPDIR /volatile/halld/offline_monitoring/RunPeriod-[RUNPERIOD]/ver[VERSION] # Example of other variables included in variable SCRIPTFILE /home/gxproj5/monitoring/hdswif/script.sh # Must specify full path ENVFILE /home/gxproj5/env_monitoring_launch # Must specify full path
3. Creating the workflow: Within SWIF jobs are registered into workflows. For offline monitoring, the workflow names are of the form offline_monitoring_RunPeriod20YY_MM_verVV_hd_rawdata with suitable replacements for the run period year YY, month BB, and the version number VV (with leading zeroes). The command "swif list" will list all existing workflows. Also, for most simple SWIF commands hdswif also provides a wrapper.
For creation of workflows for offline monitoring the command:
hdswif.py create [workflow] -c input.config
should be used. When a config file (here: input.config) is passed in, hdswif will automatically create files that record the configuration of the current launch. These files are stored as for example:
/group/halld/data_monitoring/run_conditions/RunPeriod-2015-03/jana_rawdata_comm_2015_03_ver15.conf /group/halld/data_monitoring/run_conditions/RunPeriod-2015-03/soft_comm_2015_03_ver15.xmlThe software packages stored in git (sim-recon and hdds) can have git tags applied to them, which makes it easier to find versions of the software than a SHA-1 hash. hdswif will ask if you would like to create a tag, and execute the following sequence:
git tag -a offmon-201Y_MM-verVV -m "Used for offline monitoring 201Y-MM verVV started on 201y/mm/dd"
git push offmon-201Y_MM-verVVThis will only be invoked when the user name is gxprojN, and for the configuration files, the output directory will be /group/halld/data_monitoring/run_conditions/ for gxprojN accounts while it will be the current directory for other users.
- To use the git-tagged software versions do for example
git checkout offmon-2015_03-ver15
4. Registering jobs in the workflow: To register jobs within the workflow, hdswif provides the use of config files. Jobs can be registered by specifying the workflow, config file (-c), run (-r) and file (-f) numbers if necessary. Note: Job configuration parameters can be set differently for jobs within the same workflow if necessary.Jobs can be added via
hdswif.py add [workflow] -c input.config
By default, hdswif will add all files found within the directory /mss/halld/RunPeriod-201Y-MM/rawdata/ where 201Y-MM is specified by the RUNPERIOD parameter in the config file. If only some of the runs or files are needed, these can be specified for example with
hdswif.py add [workflow] -c input.config -r 3180 -f '00[0-4]'
to specify to register running only over run 3180 files 000 - 004 (Unix-style brackets and wildcards can be used).
5. Running the workflow: To run the workflow, simply use the hdswif wrapper:
hdswif.py run [workflow]
It is recommended that some jobs be tested to make sure that everything is working rather than fail thousands of jobs.
Check the configuration setup when creating a workflow, and what is in script.sh. Also check the following:
- Check stderr files. Are they small (<kB)?
- Check stdout files. Are they very large (>MB)?
- Check output ROOT files. Are they larger than several MB?
- Check output REST files. Are they larger than several tens of MB?
For this purpose, hdswif will take an additional parameter to run which limits the number of jobs to submit:
hdswif.py run [workflow] 10
in which case only 10 jobs will be submitted.To submit all jobs after checking the results, do
hdswif.py run [workflow]
Checking the Status and Resubmitting1. The status of jobs can be checked on the terminal with
jobstat -u gxprojNFor the status of jobs on Auger see http://scicomp.jlab.org/scicomp/#/auger/jobs and for SWIF use
swif listor for more information,
swif status [workflow] -summaryNote that "swif status" tends to be out of date sometimes, so don't panic if your workflow/jobs aren't showing up right away. Also see the Auger job website. 2. For failed jobs, SWIF can resubmit jobs based on the problem. For resubmission for failed jobs with the same resources,
swif retry-jobs [workflow] -problems [problem name]can be used, and for jobs to be submitted with more resources, e.g., use
swif modify-jobs [workflow] -ram add 2gb -problems AUGER-OVER_RLIMIT
This only re-stages the jobs, be sure to resubmit them with:
swif run -workflow [workflow] -errorlimit nonehdswif has a wrapper for both of these:
hdswif.py resubmit [workflow] [problem]In this case [problem] can be one of SYSTEM, TIMEOUT, RLIMIT. If SYSTEM is specified, the jobs will be retried. For TIMEOUT and RLIMIT, the jobs will be modified by default with 2 additional hours or GB of RAM. If one more number is added as an option, then that many hours or GB of RAM will be added., e.g.,
hdswif.py resubmit [workflow] TIMEOUT 5will add 5 hours of processing time. You can wait until almost all jobs finish before resubmitting failed jobs since the number should be relatively small. Even if jobs are resubmitted for one type of failure, jobs that later fail with that failure will not be automatically resubmitted.
3. For information on swif, use the "swif help" commands and for hdswif see the attached documentaion in https://halldsvn.jlab.org/repos/trunk/scripts/monitoring/hdswif/manual_hdswif.pdf
4. Below is a table describing the various errors that can occur.
|ERROR NAME||Description||Resolution||hdswif command|
SWIF’s attempt to submit jobs to Auger failed. Includes server-side problems as well as user failing to provide valid job parameters (e.g. incorrect project name, too many resources, etc.)
If requested resources are known to be correct resubmit. Otherwise modify job resources using swif directly.
hdswif.py resubmit [workflow] SYSTEM
Auger reports the job FAILED with no specific details.
Resubmit jobs. If problem persists, contact Chris Larrieu or SciComp.
hdswif.py resubmit [workflow] SYSTEM
Failure to copy one or more output files.Can be due to permission problem, quota problem, system error, etc.
Check if output files will exist after job execution and that output directory exists, resubmit jobs. If problem persists, contact Chris Larrieu or SciComp.
hdswif.py resubmit [workflow] SYSTEM
Auger failed to copy one or more of the requested input files, similar to output failures. Can also happen if tape file is unavailable (e.g. missing/damaged tape)
Check if input file exists, resubmit jobs. If problem persists, contact Chris Larrieu or SciComp.
hdswif.py resubmit [workflow] SYSTEM
Job timed out.
If more time is needed for job add more resources. Default is to add 2 hrs of processing time. Also check whether code is hanging.
hdswif.py resubmit [workflow] TIMEOUT
Not enough resources, RAM or disk space.
Add more resources for job.
hdswif.py resubmit [workflow] RLIMIT
Output file specified by user was not found.
Check if output file exists at end of job.
User script exited with non-zero status code.
Your script exited with non-zero status. Check the code you are running.
Job failed owing to a problem with swif (e.g. network connection timeout)
Resubmit jobs. If problem persists, contact Chris Larrieu or SciComp.
hdswif.py resubmit [workflow] SYSTEM
Post-analysis of statistics of the launch
After jobs have been submitted, it will usually take a few days for all of the jobs to be processed. The next step is to check the resource usage for the current launch and publish the results online.
- Create summary XML, HTML files
The status and results of jobs are saved within the SWIF internal server, and are available via the command
swif status [workflow] -summary -runswhere the arguments -summary and -runs show summary statistics and statistics for individual jobs, respectively. hdswif has a command that takes this output in XML output and creates an HTML webpage showing results of the launch. To do this, do
hdswif.py summary [workflow]This will create the XML output file from SWIF called swif_output_[workflow].xml and create a webpage containing png figure files. If the XML file already exists, hdswif will ask whether to overwrite the existing file.
- Publish output files online
At this stage the html output and figure files are created and ready to be put online. The html output capabilities of hdswif is useful for any user using SWIF, but since publication of the html output is specific to the offline monitoring, the script to do this is contained in the cross_analysis scripts directory at https://halldsvn.jlab.org/repos/trunk/scripts/monitoring/cross_analysis. For the gxprojN accounts this directory should exist as ~/monitoring/cross_analysis. To publish the results online do for example
python ~/monitoring/cross_analysis/publish_offmon_results.py 2015_03 18The script copies the html output and corresponding figures to /group/halld/www/halldweb/html/data_monitoring/launch_analysis/ and also creates a link to it in the html page.
- Editing the summary HTML page
The top page for is offline monitoring https://halldweb.jlab.org/data_monitoring/launch_analysis/index.html and has links to the summary page for each run period. The summary files are
/group/halld/www/halldweb/html/data_monitoring/launch_analysis/[run period]/[run period].htmlEdit the file to:
- Add a new line to the first table which contains the version number, date, and comments for the current launch
- Create a link to the webpage for the current launch. Simply copy and paste, modify the previous launch's link to have the correct launch ver.
- Freezing SWIF tables
Since we are now finished with the SWIF workflow that we used, the workflow should be "frozen" so that it cannot be mistakenly altered or modified. Do
swif freeze [workflow]
- Backing up SWIF output
With the workflow frozen we should be able to reproduce the XML output from SWIF, but we will backup the XML output just in case. Do
cp ~/monitoring/hdswif/xml/swif_output_[workflow].xml /group/halld/data_monitoring/swif_xml_backup/
Cross Analysis of Launches
The purpose of the cross analysis is to correlate how resource usage changed for the same files across different launches. To do this it is useful to create MySQL tables that contain information on each launch, and do queries across tables.
- The scripts to do this are maintained in the svn directory https://halldsvn.jlab.org/repos/trunk/scripts/monitoring/cross_analysis Do
svn co https://halldsvn.jlab.org/repos/trunk/scripts/monitoring/cross_analysisFor the gxprojN accounts used for offline monitoring the directory should be ~/monitoring/cross_analysis
- The main script is run_cross_analysis.sh, which can be run with
./run_cross_analysis.sh [RUNPERIOD] [VERSION], where e.g. [RUNPERIOD] = 2015_03 and [VERSION] = 22. However, it is strongly recommended that the commands in this script be run by hand to catch any errors.
- Enter the python commands that are in run_cross_analysis.sh . Below are the steps and explanations:
- Create a table for the current launch using
./create_cross_analysis_table.sh [RUNPERIOD] [VERSION]. The table will be created from the file template_table_schema.sql and contain columns id, run, file, timeChange, cpu_sec, wall_sec, mem_kb, vmem_kb, nevents, input_copy_sec, plugin_sec, final_state, problems
python fill_cross_analysis_entries.py [RUNPERIOD] [VERSION]The script will gather all of the necessary information either from SWIF output or the stdout files for the jobs
python create_stats_table_row.py [RUNPERIOD] [VERSION]This will loop over the jobs in the current launch and create a row in an HTML table that summarizes the statistics for the final state and problems for the jobs. This table row is then inserted into the main HTML webpage for the run period.
python create_stats_for_each_file.py [RUNPERIOD] [MINVERSION] [VERSION]This creates a comparison table of the final state and problems for each file between launches [MINVERSION] and [VERSION]. In the run_cross_analysis.sh script, the default is to set MINVERSION to be 15 for run period 2015_03, but as long as SWIF was used for all previous launches, any number will work.
python create_resource_correlation_plots.py [RUNPERIOD] [CMPMINVERSION] [VERSION]This creates correlation plots of resource use between launches between CMPMINVERSION and VERSION. By default CMPMINVERSION is 5 launches earlier.
- Create a table for the current launch using
Starting a new run period
When a new run period is started, it is best to make sure all top-level directories are created with the right permissions. This can save headaches later on when a different gxprojN account is used for offline monitoring.
- Create top-level directories
- Make sure other gxprojN users can write in with chmod g+w [dir name]. Check that permissions match those from previous run periods.
- Since the publish-to-web scripts are webpage-update scripts, you need to have pre-existing, template versions of a few files for the new run period. It also expects to find comment hooks that include the new run period name, so make sure those are edited in the new template files.
Explanation of Scripts
Below are explanations of each script used in the offline monitoring system and a breif explanation of how they work.
Summary: hdswif.py is the main script that calls the other utility scripts. For the utility scripts, they can be run standalone by giving the appropriate parameters. Visual graphics are made using the PyROOT extension of ROOT. To use this, the environment variable PYTHONPATH must include ROOTSYS. If ROOTSYS has been set, adding it to PYTHONPATH will be done by the script, but if ROOTSYS is not set, then the scripts will abort.
Main script to control the behavior of SWIF. Most commands follow the form hdswif.py [command] [workflow] (options)
Called within hdswif.py to create html output from SWIF results.
cross_analysis scriptsSummary: The script run_cross_analysis.sh is the main script. In principle, running this with
./run_cross_analysis.sh [RUNPERIOD] [VERSION]should work, but it is recommended that the commands within the script
be run by hand to catch any errors.
Running Over Data As It Comes In
A special user gxproj1 will have a cron job set up to run the plugins as new data appears on /mss. During the week, gxproj1 will submit offline plugin jobs with the same setup as the weekly jobs run the previous Friday. The procedure for this is shown below.
Running the cron job
IMPORTANT: The cron job should not be running while you are manually submitting jobs using the jproj.pl script for the same project, or else you will probably multiply-submit a job.
- Go to the cron job directory:
- The cron_plugins file is the cronjob that will be executed. During execution, it runs the exec.sh command in the same folder. This command takes two arguments: the project name, and the maximum file number for each run. These fields should be updated in the cron_plugins file before running.
- The exec.sh command updates the job management database table with any data that has arrived on tape since it was last updated, ignoring file numbers greater than the maximum file number. It then submits jobs for these files.
- To start the cron job, run:
- To check whether the cron job is running, do
- To remove the cron job do
To visualize the monitoring data, we save images of selected histograms and store time series of selected quantities in a database, which are then displayed on the monitoring web pages. The results from different raw data files in a run are also combined in to single ROOT and REST files. This section describes how to generate the monitoring images and database information.
The post-processing scripts generally perform the following steps for each run:
- Summarize monitoring information from each EVIO file, store this information in a database
- Merge the monitoring ROOT files into a single file for the run
- Generate summary monitoring information for the run and store it in a database
- Generate summary monitoring plots and store these in a web-accessible location
- Merge the REST files generated by the monitoring jobs into a single file for each run
The scripts used to generate this summary data are primarily run from /home/gxprojN/monitoring/process i.e. the same account from which the monitoring launch was performed. If you want a new copy of the scripts, e.g., for a new monitoring run, you should check the scripts out from SVN:
svn co https://halldsvn.jlab.org/repos/trunk/scripts/monitoring/process
Note that these scripts depend on standard GlueX environment definitions to load the python modules needed to access MySQL databases.
There are two primary scripts for running over the monitoring data generated by the online system and offline reconstruction. The online script can be run with either of the following commands:
/home/gluex/halld/monitoring/process/check_new_runs.py OR /home/gluex/halld/monitoring/process/check_new_runs.csh
The shell script sets up the environment properly to run the python script. To connect to the monitoring database on the JLab CUE, modules included in the local installation of python >= 2.7 are needed. The shell script is appropriate to use in a cron job. The cronjob is currently run under the "gluex" account.
The online monitoring system copies a ROOT file containing the results of the online monitoring, and other configuration files into a directory accessible outside the counting house. This python script automatically checks for new ROOT files, which it will then automatically process. It contains several configuration variables that must be correctly set, which contains the location of input/output directories, etc...
After the data is run over, the results should be processed, so that summary data is entered into the monitoring database and plots are made for the monitoring webpages. Currently, this processing is controlled by a cronjob that runs the following script:
This script checks for new ROOT files, and only runs over those it hasn't processed yet. Since one monitoring ROOT file is produced for each EVIO file, whenever a new file is produced, the plots for the corresponding run are recreated and all the ROOT files for a run are combined into one file. Information is stored in the database on a per-file basis.
Plots for the monitoring web page can be made from single histograms or multiple histograms using RootSpy macros. If you want to change the list of plots made, you must modify one of the following files:
- histograms_to_monitor - specify either the name of the histogram or its the full ROOT path
- macros_to_monitor - specify the full path to the RootSpy macro .C file
When a new monitoring run is started, or the conditions are changed, the following steps should be taken to process the new files:
- Add a new data version, as described below:
- Change the following parameters in check_monitoring_data.csh:
- JOBDATE should correspond to the ouptut date used by the job submission script
- OUTPUTDIR should correspond to the directory corresponding to the run period and revision corresponding to the new version you just submitted. Presumably, this directory will be empty at the beginning.
- Once you create a new data version as defined below, you should pass the needed information as a command line option. Currently this is done by the ARGS variable. For example, the argument "-v RunPeriod-2014-10,8" tells the monitoring scripts to look up the version corresponding to revision 8 of RunPeriod-2014-10 in the monitoring DB and to use to store the results.
Example configuration parameters: set JOBDATE=2015-01-09 set INPUTDIR=/volatile/halld/RunPeriod-2014-10/offline_monitoring set OUTPUTDIR=/w/halld-scifs1a/data_monitoring/RunPeriod-2014-10/ver08 set ARGS=" -v RunPeriod-2014-10,8 "
If you want to process the results manually, the data is processed using the following script:
./process_new_offline_data.py <input directory> <output directory> EXAMPLE: ./process_new_offline_data.py 2014-11-14 /volatile/halld/RunPeriod-2014-10/offline_monitoring/ /w/halld-scifs1a/data_monitoring/RunPeriod-2014-10/ver02
The python script takes several options to enable/disable various steps in the processing, run process_new_offline_data.py with the "-h" switch to see all of them. Of notable interest is the "--force" option, which will run over all monitoring ROOT files, whether or not they've been previously identified.
Every time a new reconstruction pass is performed, a new version number must be generated. To do this, prepare a version file as described below. Then run the register_new_version.py script to store the information in the database. The script will return a version number, which then should be set by hand in process_new_offline_data.py - future versions of the script will streamline this part of the procedure. An example of how to generate a new version is:
./register_new_version.py add /home/gxproj1/halld/monitoring/process/versions/vers_RunPeriod-2014-10_pass1.txt
If you are running the offline monitoring by checking out the files in trunk/scripts/monitoring/jproj/projects/ of the svn repository, and created a project with
create_project.sh [project name] hd_rawdata
Then go to the directory [project name]/processing/ and execute
which will run register_new_version.py as well as check_monitoring_data.csh for that project.
Step-by-Step Instructions For Processing a New Monitoring Run
The monitoring runs are current run out of the gxproj1 and gxproj5 accounts. After an offline monitoring run has been successfully started on the batch farm, the following steps should be followed to setup the post-processing for these runs.
- The post-processing scripts are stored in $HOME/halld/monitoring/process and are automatically run by cron.
- Run "svn update" to bring any changes in. Be sure that the list of histograms and macros to plot are current.
- Add a new data version
- Edit check_monitoring_data.csh to point to the current revisions/directories
- Note that the environment depends on a standard script - $HOME/setup_jlab.csh
- Update files in the web directory, so that the results are displayed on the web pages: /group/halld/www/halldweb/html/data_monitoring/textdata
- Copy the REST files to more permanent locations:
- cp -a /volatile/halld/offline_monitoring/RunPeriod-YYYY-MM/verVV/REST /work/halld/data_monitoring/RunPeriod-YYYY-MM/REST/verVV
- cp -a /volatile/halld/offline_monitoring/RunPeriod-YYYY-MM/verVV/REST /cache/halld/RunPeriod-YYYY-MM/REST/verVV [under testing]
Check log files in $HOME/halld/monitoring/process/log for more information on how each run went. If there are problems, check log files, and modify check_monitoring_data.csh to vary the verbosity of the output.
To document the conditions of the monitoring data that is created, for the sake of reproducability and further analysis we save several pieces of information. The format is intended to be comprehensive enough to document not just monitoring data, but versions of raw and reconstructed data, so that this database table can be used for the event database as well.
We store one record per pass through one run period, with the following structure:
|data_type||The level of data we are processing. For the purposes of monitoring, "rawdata" is the online monitoring, "recon" is the offline monitoring|
|run_period||The run period of the data|
|revision||An integer specifying which pass through the run period this data corresponds to|
|software_version||The name of the XML file that specifies the different software versions used|
|jana_config||The name of the text file that specifies which JANA options were passed to the reconstruction program|
|ccdb_context||The value of JANA_CALIB_CONTEXT, which specifies the version of calibration constants that were used|
|production_time||The data at which monitoring/reconstruction began|
|dataVersionString||A convenient string for identifying this version of the data|
An example file used as as input to ./register_new_version.py is:
data_type = recon run_period = RunPeriod-2014-10 revision = 1 software_version = soft_comm_2014_11_06.xml jana_config = jana_rawdata_comm_2014_11_06.conf ccdb_context = calibtime=2014-11-10 production_time = 2014-11-10 dataVersionString = recon_RunPeriod-2014-10_20141110_ver01