Some notes on making a coda event file from "munged" data.

							S.A.Wood
							27.04.2000

Munged data input format to to munged2coda

A series of ASCII lines.  Each line contains 9 numbers.  The first
number number is the scaler channel number for the first scaler
value.  The second through 9th numbers are the first through eigth
scaler values.

There is apparantly no delimeter between events.  A channel number of
1 designates a new event.  Presumably some kind of helicity
information will need to be added to these events.

I assume that eventually the munged data file will have some kind of
header that will give information about the pedigree of the munged
data.

The munged data represents Monte Carlo data from the North American
octants.  This amount of data will require two VME crates, thus will
end up in two CODA ROC banks.  Now is as good a time as any to define
the ROC numbers to be used in the G0 DAQ.

CPU name   Component	ROC ID	Function

g0vmets	    TS0		  ?	  Trigger supervisor, Beam info scalers
g0vme1      ROC1	  1	  North American
g0vme2      ROC2	  2	  North American
g0vme3      ROC3	  3	  French Electronics
g0vme4      ROC4	  4	  Spare
g0fb1	    ROC5	  5	  Fastbus


Details on conversion of munged data.

The NA VME crates will contain a number of scalers.  Each scaler
contains 32 channels (16?).  This requires 27 scalers.  If we exactly
split the channels between the two crates, then we need 28 scalers, 14
per crate with 28 spare channels per crate.

Do we read these spare channels if there is nothing plugged into them?
Good question, but we will make the data self describing enough so
that the analysis knows how many channels were read from each scaler
module.

In the hall C spectrometer DAQ, we insert a header word in front of
the scaler values for each scaler module.  This header word is of the
form (hex) AAAACCCC, where CCCC is the number of words read from the
module, and AAAA is the address in the array where the scaler values
will be copied to by the event unpacker.  We will call AAAA/16, the
"ID" of the scaler.  Since, the scalers we will use will have 32
values per module, this  ID will always be even.

A note about the scaler ID.  In Fastbus or CAMAC, we identify modules
words by the slot that they reside it.  (Geographic Addressing).  This
is not done in VME.  Instead, each module is given an address in VME
address space.  This address is set by jumpers or small rotary
switches.  The ID of a scaler will either be the VME address of the
scaler or simply related to it.  (To be more clear, the ID is not a
property of the scaler, but rather a value that we assign to it
through a convention of our choosing.)  We will write this ID on the
front panel of each scaler.  If a broken scaler is replaced, we will
set its VME address and write the ID label to match the the module
being replaced.

[
Get some sample VME readout list code.  (See my web page).
Get scaler analysis code.  Illustrate ID->channel mapping.
]

Mapping of munged data to coda data after unpacking.

Original channels

  1 - 420			  1 - 420

421 - 840			449 - 868

We could choose not to read unused channels.  I would prefer not to do
this since it will make the readout code more complicated.  Since my
present scheme has more than 32 unused channels, we may choose to save
a scaler and reduce the unused number of channels.  (The two VME
crates will then have unequal numbers of scalers.)


Running the coda event generator:

The syntax is 

munged2coda munged_data_filename coda_filename [Run number]

munged2coda will read ASCII events from munged_data_filename and write
a coda compatible file.  If a third argument is supplied, it will use
it for the run number.


To run the sample data, type

munged2coda sample_data sample_data_coda_5.log 5