Minutes of MICAC reco framework subcommittee meeting - 18 November 2005
   -----------------------------------------------------------------------

Attending:  Chris, George, Brett, Caius, Jim, Jon, and part of: 
            Robert, Rustem and Sergei (due to FNAL phone line problems)
Absent:     Nathaniel, Nick, Sue

The meeting was chaired by Jon, pending appointment/selection of a committee 
chair.

1) Hearing no preference on the matter from the committee, Jon will appoint 
   a chair from one of the non-ex-officio members.  Anyone interested in 
   doing this should contact him asap.

2) The discussion was open to comments on the charge to the committee. 
   None were forthcoming.  Rustem said the charge was fine from his and 
   Sergei's perspective.

3) Jon asked Sergei how his plans to take up a new position (on Minerva,  
   with the Rochester group) early in 2006 might impact his ability to 
   contribute to the development of the new framework for MINOS.  Sergei 
   said his main responsibility would be on offline software for Minerva, 
   and that there was natural complementarity because of the shared beam, 
   detector hall, etc.  He said that even if we decide against moving toward 
   a new framework for MINOS, he would most likely still be implementing a 
   system along the lines of his and Rustem's proposal for Minerva.

4) Rustem was asked about his timetable for graduation.  This is not 
   imminent, but is not infinitely far off either, so there is obvious 
   value to moving quickly on the decision to pursue this further or not.

5) The floor was open for questions, comments, discussion about the big 
   picture aspects about Rustem and Sergei's proposal.  Unfortunately it 
   was shortly thereafter that connection with folks at FNAL (Robert, 
   Rustem and Sergei) became highly intermittent due to the site-wide phone   
   problems there.   A coarse summary of the discussion follows:

   - Jim asked for clarification on the value of having a reconstruction 
   framework that was more amenable to end-user data analysis activities 
   than the existing one, in light of the fact that most people would find 
   using ntuples more desirable in any case.  Brett and Caius replied that 
   there was benefit - that people generating their own ntuples would have 
   access to the full range of framework services (like geometry) to allow 
   calculation of desired quantities to include in ntuples.  There was  
   speculation that the intermediate step of generating the "standard 
   ntuples" could be skipped with the new framework - that analysis groups 
   could generate their own lightweight "analysis ntuples" directly from 
   candidate files for example.

   - This led to a discussion of the requirements that the new framework 
   should fulfill in order to make it worthwhile to do the conversion. 
   Jim noted that the benefit to the reconstruction group was not obvious 
   since most reconstruction software has been written already, so he 
   thought the benefit to the end user doing data analysis is the key factor.  
   Rustem made the point that the reconstruction is the data analysis, and 
   people should be able to understand the code.  He pointed out several 
   features of the new framework that would result in vastly improved 
   readability.  He also pointed out that improved I/O and execution time 
   performance would bestow important benefits.

   - Discussion followed on how to proceed with the development in
   such a way as to demonstrate the features.  George noted the idea
   of first backing into the new framework by translating the data from
   existing candidates into corresponding data objects.  This would allow
   definition of the interfaces, and provide persistable objects that
   people could play with and benchmark etc.  

   - Chris asked about the concept behind the reco ABC's in the new system.
   Specifically he was concerned that every new reco algorithm would want 
   to add its own varibles to these classes; would there be some way of
   managing this that would avoid having to cast up, as is advertized to 
   be the case?  Somebody (Brett? and also Robert) pointed out that the 
   ABC's in the new system were not really ABCs in the strict sense of 
   having no data members, but were more like interface classes.

6) Since we had lost the proponents from the phone call we decided to adjourn.
   We will meet again in two weeks (on Friday Dec 2, time TBD).
   Jon listed action items that can be addressed via email before then:

   (1) Rustem and Sergei will draft a list of requirements/use cases that 
       their framework is aiming to support.

   (2) Committee members will also try to identify what requirements/use 
       cases would factor into a decision to move forward with the new 
       framework.

   (3) Rustem and Sergei will clarify some of the questions about the 
       philosophy and function behind the reconstruction objects as 
       implemented via the ABCs.