Hi Shawn, Thanks for your message. Here are the answers to your questions. If this is not sufficient, please let me know. Also yesterday Dave Adams has already send you his answer about the your questions 1), 2) and 3). > 1) In Dave's design, chunks have the ability to generate their own data. > Is this a requirement? Or is it a feature that some think would be a > good idea? My answer: We have not come to a consensus yet that if a generator/algorithm used to construct a collection of data should be an intrinsic part of the collection of data (chunk). An external reconstructors may reduce a lot of physical couplings, but to be able to generate the chunk as needed within the model could be more convenient for users, although most of time this function may not be necessary. > 2) Can multiple instances of a particular chunk type exist in a given > event? Can multiple "versions" of a particular chunk type exist in a > given event? That is, how does a particular reconstructor object or > generator specify what data (chunks) it needs as input to it's > algorithms? For example, suppose that a reconstructor with type reconA Z depends on raw data for it's input and that a reconstructor with type > reconB depends on the output from a reconA type. > > reconA "asks" for raw data chunks from event > reconA processes data and puts an AChunk into the event > reconB "asks" for ? > > Does the reconB object simply ask for the latest AChunk that was added > to the event? (The sanity of the system would depend on a properly > written script control file along with good automatic "type and version" > checking possible at start-up time). Does the reconB object ask for an > AChunk with particular parameters? (This could allow for multiple pairs > of reconA and reconB objects working separately...I'm not sure how this > would be useful). Does the reconB object ask for an AChunk with a > particular version? (This would allow for different versions of > algorithms and chunks to coexist in the same event). My answer: Yes, we need to be able to have multiple versions of a particular chunk type exist in a given event. These different versions of chunk may be from different algorithms. > 3) I was under the assumption that the check for whether or not the > executable was built with all the necessary code just be done at > start-up time at the latest. Is this correct? My answer: It is necessary for Level3. > 4) Would it be possible to firm up the requirements of an error > handling/reporting mechanism. I have the document (from the talk on the > second day of my visit - sorry I forgot the person's name) on some > Level3 requirements. The requirements seem to be at a system level and > I would like a more software architecture/programming level requirement. > A web page or postscript document would be nice. We have some ideas but > don't know if this would fit your needs. Answer from Amber Boehnlein (who did the presentation on Level3 requirements during your visit here): For error handling, I think we want a new version of ERRMSG. The documentation for ERRMSG is in D0$ERRMSG_UTIL$ROOT:[DOCS]ERRMSG_UTIL.RNO. All levels of D0 software will need a facility like this. From the particular point of view of level 3, the following cases would need to be handled in addition to routine warnings 1) A software filter finds a hardware error or corrupt hardware data. The error must be reported through the alarm system and the raw event data saved either by default or on request. The total number of these messages should be displayed as well as multiple occurances might indicate a problem serious enough to halt data taking. 2) Processing an event has resulted in running out of memory or time. In run I, we saved events without a trigger decision if the processing time exceeded a maximum. In this case, we will also wish to save events that could not be processed due to a lack of memory. These events should marked in some fashion as not having a trigger decision and an error message should appear on the alarm system. If exception handling is used, events that result in a some sort of exception should be treated similarily 3) Processing an event results in a crash. The raw event data and any processed data added to the event should be extracted by the shifter for debugging. The crash presumably will be noted by the program monitoring the level 3 nodes. > 5) We are interested/concerned as to how you will be using the D0OM > preprocessor. In the D0OM User Guide it says that it borrowed from the > ROOT system. I checked out the ROOT web site and found this: > > However, we preferred the approach of a programmer selectively > deciding which data members should be written to disk. Data members > caching some state of an object that can easily be reconstructed in > the Streamer method do not have to be transferred to disk. Another > example is when variables can be compacted into short words or even > single bits (booleans). To aid the programmer we provide a tool to > generate automatically a default Streamer method. > > I know that your preprocessor is, or is based on, cint but it seems > that it would be beneficial to have the power to decide what is and what > is not written to disk within a class. The need for automatically > generating dictionary files should somehow be balanced with the need to > selectively stream what the class designer wants to. Perhaps the > solution will decide how and when you use your smart references. This > topic is probably a whole large issue in and of itself but I was just > curious... Answer from Scott Snyder and Herb Greenlee (data persistency group): There is a mechanism implemented to mark individual class members as non-persistent. This is done putting a comment starting with `//!' following the member declaration (ROOT does the same thing). We have followed the ODMG standard in including in d0_Object the methods, "activate" and "deactivate." These are intended to be called when a class is instantiated in or removed from memory. A class designer can use these methods to reconstruct or destroy the transient parts of his class.