From HallCWiki
Jump to: navigation, search

Hall C Software Documentation

  • Purpose: The goal of these pages is to document the data analysis software currently in use in the Experimental Hall C @ Jefferson Lab (JLab) and to identify (chart) a path for upgrading this software in view of the JLab 12 GeV energy upgrade.
  • Justification: The data analysis software for the Experimental Hall C at Jefferson Lab was developed in the late eighties/early nineties. The first electron beam in Hall C was delivered in the mid- nineties. The detectors and the analysis software associated with them have operated ever since (so some 15-odd years by now (03/30/2010)).
  • Upgrade: (the case for) As Jefferson Lab enters a new era by upgrading its energy to 12 GeV, and as new detectors that will take advantage of this energy are being built (in all halls, not just Hall C), it is perhaps time to upgrade/rewrite the analysis software too.
  • Author: (the I in most of the following pages) 8-) Dr. Gabriel Niculescu, Assistant Professor of Physics, Department of Physics and Astronomy, James Madison University. For the record, GN, was part of the first group of graduate students that got their PhD dissertation experimental data in Hall C in '95-'96, co-wrote some parts of the original data analysis software, and extensively tested the whole analysis package.

This effort is organized as follows: for each major part of the analysis software I will try to provide:

  • General bookkeeping info
    • date for the first version of the software
    • original author
    • number of revisions to date
  • A logic block diagram/flowchart
  • A commons list. As the software is mostly written in Fortran, common blocks are usually used to share information among various functions and subroutines
  • A program (function/subroutine) description. What this part of the program tries to do.
  • An algorithm description (when appropriate). Certain parts of the code are math- or physics- (or both) heavy. I will try to document the algorithms that these functions implement and how.
  • 8-) GN's points. My personal assessment of this part of the program, specifically looking to assess if:
    • the code is adequate for the task it supposed to perform
    • the code is solid (as in robust) with few (if any) awkward/dangerous spots.
    • the code is tidy
    • the ease with which the code can be rewritten in a C++ framework

NOTE: Throughout all of this I shall refrain from quoting whole functions/routines as the original code is readily available to Hall C members. I will however quote parts of the code stressing what I consider to be important points.

NOTE: As much as possible I will try to keep up a summary page with general ideas, notes, observation about the whole code.

Below you'll find a table from which you can quickly jump to various parts of the code:

Synopsis List of files Stats.
ESCAN, F1TRIGGER, SANE, SEM - all empty Makefile