Feature #964: === GUI ===
GUI: finalize FitWidget
|Status:||Archived||Start date:||18 Mar 2016|
|Priority:||Normal||Due date:||01 Apr 2016|
|Target version:||Sprint 31|
- FitParameters widget (right part): replace text editor on the right with something more fancy
- For fitParameter provide (name) like "par0", (min, max) values and (enabled/disabled) flag.
- For fitParameter provide a place were one can see to which itemParameters he is looking at
- provide possibility to remove fitParameter
- provide possibility to remove itemParameter
Widget can be done either as before (QTreeView), or as dedicated widget where QComboBox, QTextEdit will be used for fitParameters (then you can use your trick with QModelMapper).
- FitParameters widget (left tree): provide interaction between left and right.
- It should be possible to add itemParameter to certain fitParameter. If dragAndDrop is too complicated, may be via context menu will be easier.
- FitParameters widget (left tree): find a way to exclude "Form Factor" from the tree (to discuss).
i.e. to get /Particle0/Cylinder/Radius
The main goal is to have in all views (SampleDesigner/ComponentEditor, RealTimeActivity, FirParameters) more or less the same layout. Excluding extra "FormFactor" level is important, because it makes GUI closer to the domain layout (and so less confusing for GUI->Python script migration).
This task is closely related to the ParticleDistributionItem and parameterTranslation. Currently it is broken because of extra level in GroupProperty.
- FitParameter widget (left tree): some items do not show up in the tree
- Check Transformation
- Check Position Offset
- provide a button "Generate data from current instrument/sample settings"
- Attempt to close BornAgain while fit is running should lead to warning "Cancel fit yes/no"
- It seems that in 3 ColorMap plots - RealData, SimulationData, RelativeDifference - the very left plot is not relativeDifference.
#2 Updated by david almost 4 years ago
- Due date set to 01 Apr 2016
I have a completely new idea for fitting: Instead of a separate fit view, let's integrate fitting into real time activity. This will make the whole process more organic and we avoid replicating many features.
I'd like to extend simulation and job view.
A) The right place to load real data is the simulation view. 1. There is plenty of space 2. Real data belongs logically to a simulation (pair of instrument and sample) and has only meaning in this context. When we load the data in a separate view, we must replicate this context, including selection of instrument, sample, validation, etc. - its all done in simulation view. 3. This is also the right view to place mask editor. Mask has only meaning in the context of real data. It belongs to a whole simulation, not to some special instrument.
- Add option to load real data file
- Add button to open mask editor. Mask editor should contain real data. Masks should be stored to job item.
- Before run simulation: Check if file is readable, resolution is matching, etc - give warning if not.
B) What is the difference between real time activity and fitting? The only difference is, that fitting has a chi2-map available, which is calculated according to real data. The rest of the context is the same. So we should merge the work flows of manual tuning and fitting. A separate view to run fittings is a lot of replicated work.
- You can selected multiple entries in real time activity. Then you click a button "Fit Parameters" which opens dialog box. You can select algorithm and limits and start the fitting
- While fitting is running, real time activity is locked, but values are continuously updated to progress of fitting. The color map plot should update too.
- Add two actions to toolbar: Show real data and Show chi2map. Both should open new window with plot. User can place them where ever it suits him or close them if not useful.
- Fitting toolbar should be added: Slider for update interval, button to stop fitting, labels to show iteration and current chi2.
- After fitting, real time activity should color fitted parameters. User can then continue to fit other parameters of adjust results manually. All changes will update the simulation.
- When something goes wrong, show warning sign as now. User can click on it to see detailed information.
C) The work effort is immediate. Job items and real time activity will be extended a lot, but we need not to replicate many existing features. This will make the code clean. I think the first functioning implementation will take one week, polishing it another one. This fits into my remaining time here. You can take over there.
#3 Updated by pospelov almost 4 years ago
In general your idea is reasonable, but please do not start coding/big planing before we discuss. The main problems I see is the remaining time.
You have made an outstanding GUI model refactoring and implemented working fit prototype. Now it's a good moment to fix the point. The remaining time should be enough to fix couple of important issues, stabilize the GUI and merge it without much stress to the develop. If you will still have some time left, you can always spent it doing something on your own. But I'm scared to start another big refactoring now. This will make our current sprint too long (and we will have to stabilize the GUI in your absence).
Also it is not clear, how to proceed with fitting workflow. I'm afraid that at this point we know too little about user needs, to implement it right from the first attempt. We will have to make iterations and your current prototype is perfectly fine to start to play with the fitting and to interview users.
My current plans is to include your fitting widget (more or less as it is) to the next release (end of April), to have final fitting version ready in November (when we organise our fist BornAgain user meeting and tutorials).
Concerning your idea of extending simulation and job view with parts related to the fitting. We have to be careful here. It is true, that fitting has some common settings with the simulation. My personal arguments to not to try to squeeze everything in existing tabs will be
- JobView, SimulationView will grow further. For example, SimulationView will get widgets related to Monte-Carlo integration, while JobView will contain parts for more convenient work with images (e.g. measuring distances on the image, making slices)
- Simulation will be used more often, than fitting. I would like not to overload interface with rarely used elements.
- Fitting potentially can grow much further (i.e. simultaneous fitting of two dataset, batch fitting etc). So strategically may be it is better from the beginning to place it separately.