Privacy and Security Notice

a) DIRECTORIES:

~oscar/replay:

The main directory of the replay universe. This directory contains the input files used by the engine, and is usually where the engine is run.

~oscar/replay/PARAM:

There is a lookup table that tells the engine what parameters to use for a given run. The parameter files are all kept here, to keep replay clean ('The Odd Couple' was wrong, Oscar was the neat freak).

~oscar/replay/MAPS:

There is a lookup table that tells the engine what parameters to use for a given run. The map files are all kept here, to keep replay clean.

~oscar/replay/DBASE:

There is a lookup table that tells the engine what parameters to use for a given run. The pointers to the parameter files are all kept here, to keep replay clean. (What was life like before cut and paste?).

~oscar/replay/paw:

This is where I (I mean 'Oscar') puts the histogram output files generated by the engine. You may want to do otherwise. If so, 'rmdir paw' is the protest method of choice.

~oscar/replay/scalers:

This is where I (I mean 'Oscar') puts the scaler report output files generated by the engine. You may want to do otherwise. If so, 'rmdir scalers' is the protest method of choice. (come cut and paste with me).

~oscar/replay/peds:

This is where I (I mean 'Oscar') puts the pedestal output files generated by the engine. These output files are mainly used when taking data (the threshold files are used to program the ADC thresholds for data sparsification). When replaying, these can be used to check to see if the pedestals changed centroid or width.

~oscar/replay/???:

If there are any other directories generated, oscar sure doesn't know about it. You may want to store your input parameter files, or output files in another directory. To do so, just create the appropriate directory and change the path given in REPLAY.PARM for the files you move. Note that the environmental variable ENGINE_CONFIG_FILE is the pointer to REPLAY.PARM. You must change this pointer if you wish to move REPLAY.PARM. The file dosetupreplay has the definitions for the environmental variables used by the engine. If you need more detail on how to create directories or move files, running the engine probably isn't for you.

 

 

b) FILES: ('##' indicated that you must modify the file, '*' means important)

*REPLAY.PARM:

This file tells the engine where all of the input files it needs are located, and also what file names to use for output. From here you pick the run to analyze, and the test, histogram, and parameter files to use. If the engine has a brain, this must be it.

*jan99.hist:

This file defines the histograms to be filled by the engine. There are uhist blocks (filled by the user with specific calls in the engine source code) and hist blocks (which are filled automatically after each event). If the variable to be histogrammed is registered, you can add a histogram by adding another line in one of the 'hist' blocks (or adding a new block). The format is as follows: '[histname],[data_source],numbins,lobin,hibin,test' - test is optional. The other hist files here are '#include'd into the main hist file. NOTE: all histogram and test blocks SHOULD REALLY HAVE the 'group=' flag, which determines when the test/histogram block should be evaluated. The standard group names (hms,sos,both) correspond to the hardware trigger types (hms,sos,coin). In order to fill a histogram for ALL hms events, you need 'group=hms group=both' in the begin line.

jan99.database:

This is the lookup table telling what parameter files are appropriate for a given run. This contains pointers to parameter files which select the appropriate positions/calibrations for the run. These usually change only between runs, or when there is a hardware change.

jan99.kinematics:

This is the lookup table for quantities which vary run to run. Spectrometer angles, momenta, beam energy, and other such quantities are set here. We do not yet have a system for automatically determining who is at fault when a run is useless, you must check logbook entries by hand when passing out the red hat (Bates reference that probably no one will get. Don't worry, you're not missing anything good). Note that the engine gets the kinematics from several source. First, it takes the values in the run information event (entered when the run began). Next, it overrides these with any values in the .kinematics file. Therefore, you don't need to have entries in the kinematics file for a run unless there was an error in the information typed in at the beginning of the run (or for information not included in the beginning of run info event). Finally, any command line parameters are applied, overriding everything else.

*jan99.test:

This file defines the tests used in the histograms. The syntax is to complicated for Oscar to understand, so if you can't figure out how to define a new test you need, go pester Steve Wood (or look in the CTP manual). See jan99.hist for notes on assigning groups to the test blocks.

hms(sos)_recon_coeff.dat:

HMS (SOS) reconstruction matrix elements.

h(s,g)report.template:

Oscar underestimates the importance of this file, and therefore it isn't marked '*'. It is very useful for outputting end of run variables. The three files dump hardware and software scalars, and lots of other useful information. One for the HMS, one for SOS, and one general summary file.

*replay:

It looks like a file, it smells like a file, and it swims (i.e. sinks) like a file, but it isn't a file. Replay is a symbolic link to the engine executable file that will exist in the SRC subdirectory after 'make' is run. The link always points to where the executable is supposed to be and it stays behind if you delete the executble. If you do delete the link and want to recreate it, The command goes something like this........

'ln -s ~oscar/replay/SRC/engine_replay ~oscar/replay/replay'

Your environmental variable ENGINE_CONFIG_FILE tells replay what file (usually REPLAY.PARM) has the information about the input and output files to use. These can be overridden at the command line. You can set any CTP variable (i.e. anything in one of the fortran common blocks) at the command line in the following manner:

'replay ctp_variable_name={value}' (no spaces allowed before or after '=')

the following equivilences have been put in the code in order to make life easier for passing command line arguments:

grun == gen_run_number           ;run number
gstart == gen_run_starting_event ;starting physics event #
gstop == gen_run_stopping_event  ;# of physics events to analyze
gtrig(1-4) == gen_run_enable(1-4);1=hms,2=sos,3=coin,4=ped triggers.
                                 ;gtrig1=0 disables hms triggers,
                                 ;gtrig1=1 enables triggers (enabled by default).

In addition, kinematics, parameters, and run-time switches can be set at the command line. For example:

'replay grun=4000 gstart=3000 gstop=10000 gtrig2=0 hpcentral=1.5 hdebugdumptof=1'

will analyze run 4000, starting at PHYSICS event 3000, ending after 10000 ANALYZED events, with sos triggers ignored (but not coincidence). In addition, it will set the HMS central momentum (hpcentral) to 1.5 GeV, and turn on time of flight output (hdebugdumptof=1). Command line parameters override values read from the data file or parameter files.

*MAPS/jan99.map.*:

map file which tells the engine how to map from fastbus addresses to software variables. Very complicated stuff. The name indicated which map should be used for each run. The changes are due to cabling changes in the Ginsu (TM) cheese grater/meat dicer/egg slicer/drift chamber. (only $19.95, and comes for a limited time with the Popeil potato masher/garlic press/Lead-glass calorimeter.

*

"Created test result test.ctrig"

 This is a CTP error. The test 'ctrig' was not declared before being used. You can define a test without declaring it first, but you might have trouble with the variable type.

"thTest: Unregistered variable {varibale_name} - Test booking error in line 3"

 This is another CTP error. A test was defined using a variable that does not exist. e.g. the test 'goodxy = goodx && goody' will give an error if goodx or goody are not defined. This leads to the unregistered variable and test booking error. This can occur when defining histograms as well as tests. The line number is the line within the test or hist block. The error message will eventually be modified to give the name of the unregistered variable and/or the block name.

*"Warning! Danger Will Robinson! Inconsistant Thresholds approaching!"

 This means that the engine has found a 'large' difference between the pedesal values for the ADCs and the sparsification threshold that was programmed into the ADC. This is a sign that new thresholds may be needed. The file ~cdaq/coda/hms(sos)_thresholds.dat contains the values that are programmed into the ADCs whenever you 'prestart' a run. When you analyze a run, the file ~/replay/PEDS/hms(sos)_thresholds.{runno} is created with the analyzer's idea of good thresholds.

"RZCDIR. Unknown directory //RAWH:"

This is one of those error messages you get when nothing is wrong. Think of it as a status message telling you if you are dumping ntuples or not. No error message = not saving ntuples. Error message = Ntuples being written.

"event# 15003 F"

 Just a progress report. Dumps the event number every 5000 physics events. The 'F' means that the ABORT variable is .false., though if it were .true., the engine would abort, and you wouldn't get the message.

"Finished dumping histograms/scalers for first 10232 events"

 The histograms and scaler reports are dumped every once in a while. This way you don't have to finish the run in order to start looking at the results, and you don't lose everything if you interrupt the replay. The ntuples do NOT get closed properly until the end of the run.

**"roc 1 has no data for event 4420 scanmask= A0828A"

 The roc had one or more modules that did not have data. This could be a hardware failure or a readout/syncronization problem. The scanmask is just a bit mask, telling you which modules had data to be read out. For examble, the last two bytes (8A) give a bitmask '10001010'. This corresponds to slots 1, 3, and 7 having data to be read out (since the last bit corresponds to slot 0). Notify shift leader or data aquisition person.

**"ERROR: BAD FB value evfrag({nnn})={nnnnnn} ROC={n} event={n} "

 The code has found a bad fastbus word. THIS IS BAD. Notify shift leader or data aquisition person.

**"SHIT:misidentified real data word as a header "

 Also bad, as you might have guessed. Notify shift leader and/or data aquisition person.

**"g_decode_fb_detector: Max exceeded, did={n}, max={n}: event {nnnn}"

 A detector had too many hits to be decoded fully. The did number is the detector ID. You can look at the MAP file in order to determine which detector had the problem. If it was the wire chambers, it is probably OK as long as it only occurs once. The other detectors should not be able to get too many hits. Notify someone of the problem.

"skipping outoforder scaler event:... "

 Just a status message. Sometimes the scalers are not read out in time order (they get buffered and read out several events at a time, but not in the order they were taken). In order to avoid false scaler roll-over, we skip scaler events that to not come in order.