Present: David Wren, Heather Kelly, JJ Russell, Joanne Bogart, Mike Huffer, Navid Golpayegani, Ric Claus, Richard Dubois
This has flipped back and forth in various versions; there is no guarantee that it won't change again. Latest version of EBF library (hence also ebfdump program) counts in cells. For the time being this is "right" and EbfWriter should be modified accordingly. Ric has provided the following prescription:
Once EBFwriter has been corrected to work in units of cells, prepend events generated by it with the 32 bit typeId value (=0x101f0010) and increment the event length (lower 16 bits of the next longword) by 4. This result can then be passed to a class derived EBFeventIterator that provides the process() virtual method and decoded correctly.
A form of versioning, which can be used to isolate application code from this kind of small format difference, has been implemented in the current version of the EBF library, though not by EbfWriter. However, the only legitimate client of EbfWriter is the filter code. All that matters for this exercise (getting filter code to run in Offline environment) is that EbfWriter and filter code agree. In fact, when the filter code runs in the flight environment, its input would not include the ID-type field. It's not necessary since its input is always newly-made, guaranteed compatible. More generally, the lesson is that input to filter and input to (Online) EBF library are logically distinct and only happen to be closely related.
Cyberdocs documents are essentially guaranteed to be out of date and should be taken with several grains of salt, if consulted at all. For Online EBF, the code in the EBF library and information to be found on the I & T website are the best sources. See e.g. http://www-glast.slac.stanford.edu/IntegrationTest/ONLINE/docs/TEM.pdf. See also the documents on the AEM and on inter-module communications in the same directory. For format of filter input, see filter code and EbfWriter code.
The filter code, as a crucial component of Flight Software, must be owned by JJ, even if it is also incorporated into Offline. Ideally, EbfWriter should be split into an input piece (which is heavily dependent on Offline, in particular on the structure of digitized events in the TDS) and an output piece, independent of Offline but closely tied to the filter code. The two pieces communicate via a representation of the data which is relatively stable. Might want the output side to support different options (e.g., standard uncompressed output, compression level 1, compression level 2) someday. JJ will discuss implementation of this split with David and Navid.
There were a couple for David and Navid:
Last modified: