last update:$Date: 2004/09/06 14:10:57 $
Problem domain
Function minimization and related statistical analysis (error matrix, contours, etc.)
Development team
Fred James, Matthias Winkler
Technology base
Object-oriented, C++
Platforms, operating systems
MINUIT should be platform independent but must work at least on SUN/Solaris, PC/Linux.
Minimization methods
Variable Metric Methods (Migrad), Simplex; foreseen: Fumili
Error analysis: Minos (asymmetric errors)
Tools
- configuration environment and build system for the development: SCRAM
- distribution: autoconf, make
- code repository: CVS
The goals for the MINUIT prototypes in C++ are:
- executable prototypes in C++
- better understanding of the user interfaces
- general vision of requirements, the architecture and in particular the C++ API
The prototypes for the following functionalities of MINUIT have been finished:
- Migrad, 28 January 2003
- Minos, 6 March 2003
- numerical accuracy, equivalent or better to Fortran version of MINUIT
- performance, equivalent or better to Fortran version of MINUIT
- The core of the minimization functionality and related tools (the kernel of MINUIT) should be clearly separated from the user, who is interfacing via defined user interfaces (user himself ("int main{...};", via GUI (ROOT, HippoDraw, etc.), etc.).
- Currently existing user interfaces have to exist also in the new implementation of MINUIT.
The desired user interfaces are part of the requirements. Currently the user can use MINUIT in different ways:
From a user program:
The user himself writes his/her own "int main {...};", including MINUIT header files and linking MINUIT libraries.
From a terminal (interactive):
The user executes interactivly MINUIT commands from the terminal.
From a file (batch):
The user writes MINUIT commands on a file for batch job submission.
Via a general user program:
The user wants to do fitting via a GUI like
ROOT,
HippoDraw, etc.
It will have to be defined in which places the change in technology requires also a technical change of the user interface (e.g. "int main{...};" instead of Fortran subroutine), in which places the user interfaces should/could stay unchanged (MINUIT commands for interactive and batch mode usage), and where already existing interfaces (via GUI for instance) need to be respected. In order to lower the
risk of non-acceptance of MINUIT by the experienced user, it is desired to leave the "skin" unchanged as much as possible while changing everything else.
Reasons why MINUIT would not be used (and therefore the project could fail) are all possible reasons where the user's expectations have not been met. Important points which require additional attention are:
- user interfaces (human interaction): building the wrong thing
- speed: being too slow
- qualitative degradation with respect to Fortran version of MINUIT
About the development
The development of MINUIT will be focused on the creation of a common architecture and on quality, both quality of the code and quality of the results. The architecture should provide the necessary infrastructure within an existing computing environment as well as define the
user interfaces with MINUIT. The quality aspect is of general priority. The behaviour (application) of MINUIT is already defined to a large extent by the previous Fortran version, as well as the
user interfaces. The creation of the architecture will therefore be determined to a large extent by exploiting common patterns within the existing MINUIT.
During the initial development phase (conceptualization) the
core requirements should be established and a
collection of essential minimal characteristics of MINUIT should be defined. An executable
prototype should serve as "proof of concept" as well as help finding a general architectural vision.
The experience from the
prototype should be used to create an architecture for the final implementation and to get feedback on the C++ API. The desired behaviour should be achieved by actively communicating with users and experts. The evolution of the implementation should be refined by continously iterating over the
analysis and design of MINUIT, rapidly converging on solutions.
In general the success of a software project is defined by the satisfaction of the user or by exceeding his or her expectations. A project fails if it does not meet the user's expectations and therefore the software is not used. These
risks why the user would not want to use MINUIT have to be determined in order to minimize them.
Having a piece of code compiling, linking and executing is one thing, having confidence in the numerical result of a fit is another. Therefore
testing is of particular importance for a project like MINUIT. This aspect will have an impact when establishing a
test process and even the
design of MINUIT could be affected (testing of individual components).