Meeting on the Future of the MM6 GUI, February 3, 2011
The meeting will take place on February 3, 2011, from 0900 to 1200 at GSI in the "Seminarraum Theorie", SB3 3.170.
Background
The c++ MM6 GUI is used at many ion trap experiments. It has gone a long way and is around since about 18 years or so. In the past, it has been maintained by a small group of people. At present we do not have a maintainer for that piece of software. Trap systems like ISOLTRAP develop further (first: tandem trap -> then: triple trap -> now: quad-trap). The GUI that has been developed for a tandem-trap set-up is urgently in the need for further development.
Proposed Agenda
The aim of that meeting would be to review the present situation and to discuss future plans. We should not discuss requirements in too much detail but concentrate more on a general strategy.
- short review and status
- extension of MM6 or development of new software?
- shall we have a common software approach for "all" experiments?
- separation of control GUI from on-line analysis?
- one solution (one executable like now) for everything or
- something with experiment specific modules / plug-ins?
- LabVIEW based, C++ based, Java based?
- on-line analysis based on other frameworks like ROOT or GO4 (http://www-win.gsi.de/go4/)?
- maybe DAQ based on something different like MBS (http://www-win.gsi.de/daq/) or DABC (http://dabc.gsi.de/) (just think of all this tape station and particle detector stuff that is coming in addition!)
For more information, suggestions, comments... please contact
DietrichBeck.
Participants
DietrichBeck,
MichaelGoncharov,
ChristopherBorgmann,
SzilardNagy,
JensKetelaer,
PeterZumbruch,
FrankHerfurth,
NikolausKurz,
WenxueHuang,
LinevSergey,
JoernAdamczewski
Results
Situation
MM6 is a GUI based on C++, originally developed with Borland C++. It does configuration of the control system as well as on-line analysis. It is used by about 7 trap experiments since about 20 years. However, experiments have become more complex and the GUI is more and more outdated. The GUI has been maintained by Stefan Schwarz for a long time (thanks), but Stefan stopped the maintenance since he has other obligations. Presently, the source code is unpublished. Somebody who really wants to take over the job of maintaining the software and developing it further, would get access to the code.
Possible Solutions
- Somebody continues to maintain and develop further MM6.
- Somebody develops a new GUI based on LabVIEW.
- Somebody develops a new GUI. However, this is not done from scratch, but based on existing frameworks.
Common Solution versus Individual Solutions
A common solution looks more promising for the following reasons.
- Stability: If a solution is used by many people in different environments, (hidden) bugs are to be found sooner.
- Correctness: If a solution is tested for different experiments with different parameters, possible mistakes in the analysis (error...) are more likely to be found.
- Time-Saving: Developing a solution for many experiments takes more time than developing a dedicated solution in the beginning. But on the long term, and especially if the work is distributed, the required effort is reduced compared to many individual solutions.
A Route to a Solution
- Separation of GUI for two different tasks. The first takes care about the control system, the second takes care about the on-line analysis.
- Most likely, the GUI for the control system will be developed in LabVIEW at some moment. At a first step, one can take the present MM6 GUI and disable its on-line analysis. At present, first steps into the direction of a pure LabVIEW based "control GUI" are being taken by TRIGA-TRAP and PENTATRAP. It is hoped, that these solutions will have a good re-usability.
- A new on-line analysis might be based on the GO4 framework, which is maintained by the DAQ group of GSI. Joern volunteered in providing a module, that can import the trap data into GO4. Moreover, he offers to give some advice on how-to setup the analysis with GO4. Frank will look into setting up a proof-of-principle analysis, so that a resonance can be seen in GO4. In principle, it should be possible to reuse the analysis routines (existing in MM6) with GO4. By this, also the fitting in GO4 should be no problem.
By using this solution, it is hoped that some existing code of MM6 can be reused. Moreover, analysis task can be simplified by making use of the features that are already provided by the GO4 framework.
GO4 involves (like with MM6) another technology than LabVIEW. Programming the analysis requires C/C++ knowledge, which is not available among many of the present MM6 users. This could hinder a joint effort in developing a new on-line analysis. However, using the GUI can be done without any programming knowledge. There is also a "GO4-Hot-start" option, the allows to run a pre-configured analysis on new sets of data.
As another advantage, an on-line analysis based on GO4 could serve as a starting point for a future replacement of the EVA off-line analysis program.
The aim of the effort by Joern and Frank is to show the feasibility. This will become clear in spring 2011. If successful, it needs to be discussed further, what solution is adopted and who are the people that are doing the work.
Other Possible Routes to a Solution (presently not being followed)
Continue MM6
Nobody wants to to take over the job of maintaining and developing further the present MM6 program.
Devloping a new GUI with LabVIEW
Developing a GUI with LabVIEW seems to be attractive, since expertise with LabVIEW is available amongst the present users of MM6. However, this would have to be a development from scratch, since no frameworks exist on which such a work can be based. There exists the danger, the parallel developments take place and that no common GUI for all MM6 users is developed, but one ends up with many different solutions with limited re-usability.
--
DietrichBeck - 09 Feb 2011