Requirements
The requirements are the basis to organise the development of the project. The main problems of beginner - according to David Henty - are:
- Bad communication resulting in a dead-lock.
- Sending wrong data.
- Not waiting for asynchronous requests.
Example of state view.
In order to solve the 1st one, a synchronised view of the communication is needed. Providing the state of a process (for example: waiting for process 1: Recv) and the pattern of already executed messages. This is close to what Vampir provides, but display as the program is running and not after.
Example of a 2D array view.
Sending the wrong data would involve the software to know about important arrays for the user. A mechanism to register data is therefore needed - to both simplify development and readability. The user would be able to highlight operation on a given array, and display graphical information when part of it is used.
Deliverables
Two components will be delivered. A library (mpi_wrapper) that acts as a profiler; this part is using the MPI profiling interface and gather the information of the executing program. The other part is a software, that displays information gathered by the profiler; there is therefore a communication need between profiler and display, that will introduce some slowdown on the original MPI program.
Functional requirements
- Communication profiling
- point to point: communication from a processor to another.
- global: use of general communication routines.
- using different communicators: registering and selecting the communicators to profile.
- communication time: display the time when the communication occurred and the duration of the operation.
- step by step view: providing a blocking synchronized view of the communication, showing step by step what is going on for each processor.
- display communication with graphical “animation”: display the occurring communication with simple animation, using the step by step view.
- generate a log file: either using standard log formats (Vampir’s or Scalasca’s) or a dedicated one.
- Data view
- register an array: see information regarding an array when used in communications by registering it to the profiler.
- display graphical view of registered data: when used during communication display which part of data are transferred.
- recognise derived data types: in order to display the graphical view using simple data types first (vectors, subarrays) or more complex ones later.
Non-functional requirements
The project will as much as possible create a transparent tool for the user (only add a header and few compiler options to use the profiler); therefore it will avoid adding extra function calls. But some of the functionalities needs explicit calls - like the data view, that needs explicit listing of the arrays to look at - and have to add new functions. The aim is to have as few as possible extra calls for the user code to work with and without the library very easily.
The project is driven by a "teaching tool" goal. Therefore the development will be focussed on a solid backbone library usable for potential future development rather than providing a swiss-army knife of partially implemented functionalities. If the project leads to a well-developed tool that provides interesting features it will be published on the Internet and the code will be released with an open source licence.
The project is not motivated by a good performance tool. Analysing and displaying real time information will obviously introduce a delay. But as a matter of fact, the provided tool will try to be efficient in memory usage. It is important that the tool is both reliable and does not need enormous amount of RAM to work.
