----------------------------------------------------------------------- Minutes of MICAC reco framework subcommittee meeting - 6th Dec 2005 ----------------------------------------------------------------------- Attendees: Nathaniel, Robert, Brett, Sue, Jim, Jon, Rustem, Sergei, Caius, George, Chris Action items from the previous meeting: > (a) Rustem and Sergei will draft a list of requirements/use cases that > their framework is aiming to support. > > (b) Committee members will also try to identify what requirements/use > cases would factor into a decision to move forward with the new > framework. > > (c) Rustem and Sergei will clarify some of the questions about the > philosophy and function behind the reconstruction objects as > implemented via the ABCs. (1) Sergei had prepared a webpage to address action item (c) above. It was argued that using ABCs and thereby limiting all access to reco objects to be via a base class interface would improve transparency and guarantee that analysis code will work with any concrete implementation. It was pointed out by Robert and acknowledged by Sergei that this feature can also be obtained with the current framework. Sergei then addressed the fact that adding a new data member was a big deal in this model. A discussion followed which high-lighted the fact that adding new data members to inherited classes is why the current framework is not transparent, and that the ABC's do not specifically address this - the key is to demand that new algorithms conform to the existing implemented base class or ABC. Addendum from Brett: ------------------- Strictly speaking it is the addition of a new *method* to the ABC that is a big deal. The ABC has no data and subclasses are free to change their own data members willy-nilly as long as they keep their methods unchanged. This is the whole point of designing with interfaces/ABC's. However, the point stands that changing the interface means changing all implementations. It was brought up (by Nathaniel?) that we could put some default implementation that either aborts with a stack trace, prints a message or keeps statistics on how often the default was called. This would help track down what implementations need to be updated after an interface change. Of course all this applies to the current candidates as well. (2) The discussion then moved onto the I/O The continued ability to use the ROOT TTree::Draw() feature was strongly encouraged by some members of the committee. This is possible with current candidates but would not be possible in the new framework. (Nathanial: Strictly speaking, it's not actually possible, but you can do something similar: you can make a TTree of copies of CandDigits, for instance, and make plots from it. Very useful for low-level data checks.) This led to a disucssion of possible alternatives/solutions including: + Writing scripts or ROOT functions to reproduce the Draw() functionality for the new candidates + Standardization of candidate -> ntuple data members (for ABCs this would mean a one-to-one correspondance between a ntuple data member and a ABC Get method) + Store candidates in ntuple-style format The issue of I/O speed arose with regards to writing the candidates in the ntuple style format. Sergei stated that I/O speed increased by a factor of 10 when using structures. Sue suggested that this information should be submitted to the ROOT team to understand why. The discussion then moved onto the actual structure of the data records. Nathaniel suggested a rigid event-centric structure with handles to associated reco objects being held. People generally agreed, the specific problem with the current framework being that candidates are too generic, for example only have a single daughterlist each. The snarl-centric structures however were also agreed to be useful for some studies. (3) The subject of the translator code for producing the new style candidates from existing files then arose. This turned quickly into a discussion of manpower and the acceptable timeframe for developing the new framework. For Rustem and Sergei to produce the translator code, the best case would be by the Oxford meeting; and both Rustem and Sergei have other time/effort constraints. It was decided that to push forward with this would require volunteers to write some code. This would also give new people a chance become familiar with the new framework. Regarding the timeframe for producing the new framework, Jon relayed a comment from Stan: At what point does our doubling time make it not worth continuing to take data? In the worst case this may be 3 years away, and so needs to be factor in this decision. Jim suggested that the new framework should be ready by the summer for the benefits to outweigh the effort. This was not contested. (4) At this point George pointed out that action item (b) from the last meeting had not been addressed: the need requirements of the new framework had not been outlined. Generally people agreed that requirements was the wrong word, since what we currently have "works". So the committee members are now asked to define the improvements that the new framework should have over the old. Sergei suggested that this come in the form of an ordered wishlist which can be addressed item-by-item. ------------------------------------------------------ Action Items: ------------ (a) Each committee member makes a wishlist of the improvements that they would like to see in the new framework. These will be compiled by Chris. (b) Jon will attempt to find volunteers so that work on the translator code can be completed in a timely manner. (c) Sergei will continue to pursue the I/O issue regarding data storage and will ask the ROOT team for advice. (d) Sergei and Rustem are asked to consider the discussion of the ABC design. Did this produce any change in thinking? ------------------------------------------------------- The next meeting is planned for 15th December at 11.00am CST.