RunII Physics Analysis Software Support And Maintenance Requirements

Table of contents


Introduction

The main charge of the Physics Analysis Software Support and Maintenance Requirements Group is to specify a set of questions to be asked of any candidate software products and tools that would uncover any support and maintenance issues and bring them up-front. As part of the process of formulating these questions, we looked at a number of current candidates, which helped identify issues. The month spent looking at the candidate products was not sufficient for a fair comparison, and that was not the charge. If more issues are documented for a given candidate, it likely reflects more familiarity with the software product rather than more issues or defects.

We have formulated the requirements in terms of questions to ask of candidate software and tried to give some indication of how to answer the question and provide examples from our discussions of the candidate products where appropriate. This is presented as a bulleted list below. The requirements section is followed by a summary of the support and maintenance issues uncovered for particular products we looked at. ( Minutes and transparencies from discussions are available online)We also had a couple of general issues and concerns which are discussed next.

The issue of how support and maintenance would be coordinated between Fermilab and CERN for products like Root came up in our discussions. Even though Root is geared towards High Energy Physics Analysis so likely will satisfy a good deal of Run II functional requirements, it is inevitable that there will need to be development by a local team. Can the development be shared? At the moment this might be difficult as Root uses CMZ and Fermilab CVS. If there is independent development, how are the branches merged? It was felt that we should avoid divergence as in the case of 4-vectors in CLHEP.

There was general concern that commercial and freeware packages would not be able to fully satisfy the needs of physicists in the subset of functionality covered by the package. For this reason, it was felt that in addition to meeting at least a subset of the functional requirements, the candidate product must be looked at carefully in terms of its extensibility in areas where functionality may need to be added or augmented. As an example, an attempt to read in and write out ntuple data and process it in packages like IDL, MATLAB, or OCTAVE could be made to determine the flexibility of its i/o.

back to top


Support

Maturity and Completeness

back to top

Who supports users

back to top

Licensing

back to top


Maintenance

Who provides it and how much:

back to top

Maintenance Infrastructure

back to top

Maturity and Completeness

back to top

Modularity:

back to top

Portability

back to top

Standards:

back to top

Reliability and Security:

back to top

Application specific:

back to top