(For the record...)


QUESTION:  Are there DATES / TIME STAMP INFO in the VRDC PRDF files?

ANSWER:    NO.

This info is supposed to go into an event header packet.  The reason that no
timestamp info was readily put into the event header packet at that time was
that the required fields in the EventHeader class DID NOT EXIST.  (There WAS
already then the integer run number in that class.)  Since we had just completed
a code freeze and were already behind schedule to start the response chain jobs
for the VRDC PRDF production, we decided to push on, rather than wait for
another freeze/test/rebuild cycle.

The timestamp info may well now be in the EventHeader class; I have not
looked.  IF IT IS NOT, we should certainly bring this up as an issue right
away... No further PRDFs should be generated without this!

The run number (an integer) in the event header packet was also to be left
blank (zero), but there's more to that story...

  [I'm going to insert the "references" for all this... you
  should skip over those unless you want more detail.]

....................................................................................

QUESTION:  Well then is there at least some kind of unique index?

ANSWER:    YES, there is a STANDARD RUN NUMBER, of sorts...

It is equal to the sum of a certain offset (more in a moment) plus the
"integer part" (right-most 5 characters, which are all digits) of the
9-character "RUN#" field (a string) of the so-called "Standard Part"
of a file name.

  [The present naming scheme documentation, such as it is, can be found in

https://www.phenix.bnl.gov:8080/phenix/WWW/p/lists/phenix-off-l/msg01488.html

   with one supplemental document (example of use) at

http://www.phenix.bnl.gov/phenix/WWW/publish/tlthomas/04.gif

   and background material (really painful to read, even for an expert) at

https://www.phenix.bnl.gov:8080/phenix/WWW/p/lists/phenix-spin-l/msg00560.html

  These documents have a few "bugs" and are part of a larger document, in prep,
  that I will finish sometime "soon".  The naming convention itself is still a
  work in progress; we've learned some thing from VRDC that need to be changed
  or added, etc.]

Concerning the offset:   for the VRDC, we didn't want to make a global
"run # server", so I came up with a scheme which made the RUN# field unique
by basically using part of it to store the initials of the creator of the
file (and some other info; again, see above refs for details.)

But trouble began when it became apparent that the date and timestamp info
WOULD be needed but would not be available, as explained above.

  [A day-long thread on this began with

https://www.phenix.bnl.gov:8080/phenix/WWW/p/lists/phenix-off-l/msg01555.html

  ]

Finally, it was realized that enough "timestamp" info could be encoded in the
integer run number field of the event header packet, if only it would just
contain a unique run number of some sort (i.e., something more useful than zero.)

So we needed a mapping to go from the unique string-type RUN# field of the file
name to a unique integer run number for use in the event header packet.

  [See:

https://www.phenix.bnl.gov:8080/phenix/WWW/p/lists/phenix-off-l/msg01595.html
 ( 2nd E-mail referred to in there should be
   https://www.phenix.bnl.gov:8080/phenix/WWW/p/lists/phenix-off-l/msg01583.html )

  and Charlie's reminder of the range limit of integers:

https://www.phenix.bnl.gov:8080/phenix/WWW/p/lists/phenix-off-l/msg01597.html


  ] 

I suggested that the producers of the PRDF files come up - among themselves - with
a set of integer offsets that would basically correspond somehow to the "initials"
they'd placed in the first part of the string RUN# field of the file name.

  [After a few exchanges with people, we settled on a standard:

https://www.phenix.bnl.gov:8080/phenix/WWW/p/lists/phenix-off-l/msg01624.html

  ]

Then, each of the PRDF producers just added their offset to the numeric part
of the RUN# field (in the name of the file they were about to produce) to
get the unique integer run number that went into the event header packet
(that in turn went into the file they were about to produce) via an last-
minute-added extra parameter in the response chain root macros.

-------

NOW:  While there may be some utility to a unique run number in the header packet
for every VRDC file, the silly thing about all of this in retrospect is that we
COULD HAVE just assigned a SINGLE integer run number for the ENTIRE VRDC Monte
Carlo set... what difference would it make to any future analysis routines?
The "calibration" of these files is ALL THE SAME; you only fetch it once anyway.
(This is true because all the VRDC files were made with frozen code.  No channel
maps or anything was changed in the libraries used for their production while
they were being produced.)

I think, however, that it is actually a good thing that we tagged them like
this because:  (A) They were generated at different places and by different
people, so if someone screwed up something, the run number effectively
distinguishes a sort of "calibration" for those runs;  and  (B) this will
give us a nice way (well, maybe not as nice as the timestamps directly)
to test data base accessing functions:  we can just define various ranges
of run numbers to correspond to various calibration eras, even though in
reality they are (probably) all the same.

- TLT