Summary of PMCS part of Algorithm's Meeting, 10/29/99 An agenda was presented for dicussion which included the following points : - We want to form a (wider) group of developers A. People to provide development advice B. People to provide code ( Currently from FMC++ : Roger Moore, Rick Genik; would like input from CMS : Chip Brock, ID groups : Serban, John Womersley, Dave Adams, John Hobbs - A series of regular meetings will be scheduled A. Focussed PMCS working group (off week Mondays) B. Regular progeress reports in Algorithms and MC meetings C. Regular summaries (like this) to d0-pmcs@fnal.gov - Greg will produce a draft technical specifications and requirements document that the PMCS working group will chew over at bi-weekly meetings and electronic discussion groups. A. Come to a consensus on requirements and major implementation issues. B. First draft by first meeting, 11/1 C. Milestones to be discussed Went into more detail on these points, and a more detailed discussion arose. - Do we take existing pmcs (essentially) and simply break it up into "cvs packages" to aid development or do we break up pmcs further into "framework packages". Pros and cons were discussed at length. "cvs packages" involves tightly developed code which may have the greatest control over timing and modelling, but the "framework packages" option has distinct advantages in flexibility and maintainability. Since the modelling problem has been solved by D0RECO already, *that* was not considered an issue. John Womersley pointed out that it would be nice to know for sure if timing were an issue. Greg will take existing pmcs and break it up into framework packages this weekend (somehow) and try to measure performance. ( I do not consider this test a measure of the final product timing ; but we should do something to measure the timing in the "framework" option short of building the finished product ... ) We hope to show that timing is not an issue, and Greg will hopes to get his green-belt in "Chunk Kung-Fu" this weekend. - The class structure of pmcs physics objects was presented. Dave Adams and Serban offered advice on how to refactor the classes to make the design more flexible. Namely, it was argued that the algorithms that do the smearing should be divorced from the data in the smeared classes. Greg argued that this was done in spirit if not in code; but agrees that a refactored class design could be used to better enforce this. Also, this will become more important in a multi-developer environment. - Milestones : We would like to set two major milestones at this time A. Documents : A draft document of technical specifications and requirements will be presented on Monday to the pmcs working group. We hope to chew on this document through two meeting cycles and produce a finished document to D0 by week of 11/29/99. B. We would like to have a "production release" in the spirit of d0gstar and RECO to coincide with MCC Phase III. We tentatively set a date of April, 2000 for this milestone to coincide roughly with RECO. C. Intermediate milestones will be debated during the PMCS working group meetings. Harry Melanson and John Hobbs pointed out that whatever product is released in April, we should take care that it is extendable and maintainable. We should have a design which does not paint PMCS into a corner, ie- does not preclude other tasks. - Conclusion : The most technical details of implementation will be further debated at the Monday PMCS working group meeting. Further comments : A meeting time has been fixed for the 9th circle, Mondays 1-3 PM bi-weekly, starting 11/1/99. ( I tried for mornings, but both video rooms were booked. ) Thank you again for your comments. -Greg Graham PS - If I have left out anything very important or misrepresented your comments, please drop me a line. (I will collate and send out a correction.)