User:Aakash

From ASCEND
(Redirected from Aakash Goenka)
Jump to: navigation, search

Aakash is a Google Summer of Code 2011 Student. He has undertaken a project for GUI Improvements & Bug Squashing for the PyGTK GUI.

Development branch: aakash:

Project goals

The primary goals, in order of importance would be –

  • Porting extra features of old GUI to the new GUI.
  • Addition of requested features. (will think of some too)
  • Add whatever more that the GTK library has to offer.
  • Check for and fix bugs in my code.

Summary of work done

  • Ported the PyGTK GUI from libglade to GTK Builder (bug 493)
  • Improvements to the observer functionality:
    1. Added the ability to delete an observer tab.
    2. Rows can now be deleted, either by using the right click popup menu or the delete or backspace key.
    3. Improved the way the observer tab behaves when the model is reloaded or a new model is loaded.
    4. Better support for multiple observers.
    5. Regarding plotting, the user can now select which columns to plot and whether to leave out points where the solver failed.
  • Implemented 1D Study (bug 294) in PyGTK with the following features:
    1. Intuitive units of measurement checking.
    2. Option of Logarithmic and Linear step distribution
    3. Option to run a particular method before solving for each point.
    4. The values for which the solver failed are highlighted in red in the observer tab, with the solver error as the tooltip for that row.
    5. It uses a separate Study status dialog, derived from the existing solver status dialog. The dialog shows relevant information regarding the point being solved currently, no of points solved, etc.
  • Implemented Automatic (weekly) checking for updates.
  • Improved the units of measurement checking in the "Variable Properties" dialog.

More that can be done

Every few days, John and I would have a discussion regarding the work I had done and what more I could do. During those, a number of things were suggested, and I worked on many of them. However for a project like ASCEND, the possibilities are unlimited, and there is a lot that can still be done:

  • In the "Observer Tab",
    1. Implement sorting of columns in the Observer. It would help in making plots work properly.
    2. Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales
    3. Add the ability to select line type using matplotlib specifiers like "r-", "b." etc.
    4. Presently, tainting of rows is only done when the solver fails while the Study function is used. It could also be implemented for the normal process of solving for individual values.
  • In the new "Study" functionality,
    1. It could be made faster by reducing the rate at which the GUI is updated.
    2. One could add an option for writing the output data to a file, while solving.
  • Think about ways that we can use NOTES for effective documentation of models as seen in the GUI.
  • In the "incidence matrix" window, we could add coloring of diverged/converged blocks, and light-grey background shading to identify the blocks. This would make it much easier to see where things were going wrong.
  • In the "diagnose" window, we should get rid of (or else improve) the current fairly cryptic colour-scheme for points, and try to improve usability. This window aims to provide similar functionality to the "incidence matrix" window, but with more detail allowing more debugging and investigation to happen.
    1. Values of variables should be shown with the preferred units, if possible, but perhaps when hovering over the value it should show the scaled value as used by the solver.
    2. It should be easy to find which equations are diverging, which variables have gone to their limits or have gone to crazy big values, and the shortest possible name for variables should be used, rather than the first one that ASCEND manages to locate (variables have ALIASES and ARE_THE_SAME relationships which means that there is often a number of different ways of referring to a single solver variable).
  • Some bugs which need attention :
    1. bug 423 Changing value of solved variable should force removal of 'solved' indication
    2. bug 501 pygtk/ascdev fails to load solvers under Windows 7
    3. bug 507 propagate var/relation 'solved' status up through model hierarchy in processVarStatus
    4. bug 429 default units often not very useful

Progress reports

19 Aug 2011

The work done in the last few days :

  • Implemented Automatic Weekly Update checking.
  • Implemented better units of measurement checking in the "Variable Properties" dialog box.
    • PyGTK Study - 19.png
  • Fixed bug 518
  • Fixed bug 473
  • Found some plotting related bugs in my code and fixed them.
  • Tested out the updated trunk on Ubuntu and Windows 7 to ensure that everything was working alright.

7 Aug 2011

The progress made this week is as follows-

Done

  • In the Observer tab,
    1. Multiple rows can now be selected and deleted.
      • PyGTK Study - 18.png
    2. A column can now be preselected as a y-variable (for plotting) by right clicking on it and selecting plot.
    3. Plotting and copy to clipboard were not working properly if used after deleting any column or for columns which had been added to the observer tab late, ie., after addition of some rows. Fixed all of those problems.
  • Did a merge from the current trunk, to make sure that everything was working properly.
  • Updated the URLs in "Report a bug" and the "About" dialog.

To Do

  • Implement sorting of columns in the Observer. It would help in making plots work properly.
  • Automatic checking for updates.
  • Add the ability to select line type using matplotlib specifiers like "r-", "b." etc.

More that could be done

The following are suggestions given by John, regarding what more can be done to improve the GUI further.

  • Think about ways that we can use NOTES for effective documentation of models as seen in the GUI.
  • In the "incidence matrix" window, we could add coloring of diverged/converged blocks, and light-grey background shading to identify the blocks. This would make it much easier to see where things were going wrong.
  • In the "diagnose" window, we should get rid of (or else improve) the current fairly cryptic colour-scheme for points, and try to improve usability. This window aims to provide similar functionality to the "incidence matrix" window, but with more detail allowing more debugging and investigation to happen.
    1. Values of variables should be shown with the preferred units, if possible, but perhaps when hovering over the value it should show the scaled value as used by the solver.
    2. It should be easy to find which equations are diverging, which variables have gone to their limits or have gone to crazy big values, and the shortest possible name for variables should be used, rather than the first one that ASCEND manages to locate (variables have ALIASES and ARE_THE_SAME relationships which means that there is often a number of different ways of referring to a single solver variable).

30 July 2011

On the basis of discussions held with John during the last week, I have made some progress. The detailed report is as follows-

Done

  • In the Observer tab,
    1. Fixed a problem which was happening when you deleted a column, and then added a new column or row.
    2. Fixed problems regarding the observer tab when different model is loaded, without reloading the file. Also added a dialog to warn the user -- if there are any active Observers -- that they will become inactive after reload.
      • PyGTK Study - 14.png
    3. It is now possible select units of measurement in the Observer tab.
      • PyGTK Study - 15.png
    4. When an observer is inactive (not connected to the simulation, eg after a 'reload') the active row will turn black, have its arrow removed etc.
    5. Implemented tooltips which display solver errors for rows in the Observer's tab
      • PyGTK Study - 16.png
  • Plot button,
    1. Implemented the following interface to select the columns to be plotted.
      • PyGTK Study - 17.png
    2. As you can see, the user will also be able to leave out points where a solver error occurred.

To Do

  • Implement sorting of columns in the Observer. It would help in making plots work properly.
  • Think about ways that we can use NOTES for effective documentation of models as seen in the GUI

24 July 2011

Some updates on what I have been doing, and what more I have to do. -

Doing Now

  • Plot button. We need to work on more flexibility of plotting. The first thing is some way to indicate "x" and "y" variables for a simple plot. Perhaps you could try hand-drawing some sketches of possible GUI implementations, and scan/photo them and send me? This is a slightly different topic, but it all goes to making the "observer" tab a useful tool for working with out simulations.
    • I have designed the following dialog -
    • PyGTK Study - 12.png
    • Both the columns will show the variables we have in our observer tabs. Left column is for y axis and right one is for x axis. A user can just select one from each and click on 'plot'.
  • In the Observer tab,
    1. If possible, can we "flag" a row in the table as being a "problem row" if the solver was not converged at the time the data was "kept". eg perhaps the font can be red, or there can be an icon at the left of the table?
      • Coloring of rows and error icon are done. Now working on setting the error message as its tooltip.
      • PyGTK Study - 13.png

To Do

  • In the Observer tab,
    1. Fix problems regarding the observer tab when different model is loaded, without reloading the file.
    2. Fix a problem which is happening when you delete a column, then add a new column or row.

14 July 2011

Made an adapted version of the SolverReporter Dialog for the Study function in PyGTK GUI . Updates on what I have done, and what more I have to do. -

Finished doing

  • In the Study dialog,
    1. Add a check-box saying "continue on failure" and have the box checked by default
    2. Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)

PyGTK Study - 10.png

  • A new "Study Reporter" dialog should pop up for the actual STUDY calculation. This should be a specialised form of the Solver Reporter that is adapted for reporting the progress of multiple attempted solve actions. There should be a progress bar showing how many of the "points" (not "steps") have been solved/attempted. The usual Solver Reporter should not appear.

PyGTK Study - 11.png

  • When the process has finished, the box should disappear if there were no errors. Otherwise, the box should stay there, and there should be a "label" that reports the presence of errors (see below for flagging of "problem rows"). Details of the failures can be shown in the "error" tab for the moment.
    • About the "label" to report presence of errors, I need to discuss with John.

To Do

  • Plot button. We need to work on more flexibility of plotting. The first thing is some way to indicate "x" and "y" variables for a simple plot. Perhaps you could try hand-drawing some sketches of possible GUI implementations, and scan/photo them and send me? This is a slightly different topic, but it all goes to making the "observer" tab a useful tool for working with out simulations.
    • Will look into it once I finish with the remaining problems in observer tab (see below)
  • In the Observer tab,
    1. If possible, can we "flag" a row in the table as being a "problem row" if the solver was not converged at the time the data was "kept". eg perhaps the font can be red, or there can be an icon at the left of the table?
      • Will do that, coloring the entire row appears to be a bit difficult because you need to set the color for each cell individually. An icon at the left of the table, with the error message as its tooltip should be easy. Will look into it.
    2. Fix problems regarding the observer tab when different model is loaded, without reloading the file.
    3. Fix a problem which is happening when you delete a column, then add a new column.

11 July 2011

Just finished some work on the observers functionality. Further updates on what I have done, and what more I have to do. -

Finished doing

  • In the Study dialog
    1. Log-spaced values work if BOTH the upper and lowewr bound are negative. But if one is negative and the other is positive, it does not, and the relevant entries are highlighted.
    2. Lower bound now defaults to the current value of the variable.
  • In the Observer tab
    1. After a model is reloaded, a right-click in the "dead" Observer table results in an error
      • Fixed.
    2. If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
      • Done.
    3. If an observer tab is "dead" then the "add" button should be greyed out.
      • Done.
    4. Can you work out a way to remove a column from the observer?
      • Done.
    5. What happens when a column is added to an observer that already contains a number of rows... does it work OK?
      • Yes, it works Ok

Noticed some problems regarding the observer tab when different model is loaded, without reloading the file. Need to look into it.

P.S. :(The work related to the Study Dialog should have been there in the 10th July update, but I forgot to mention it in there)

To Do

  • In the Study dialog,
    1. Add a check-box saying "continue on failure" and have the box checked by default
    2. Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)
  • A new "Study Reporter" dialog should pop up for the actual STUDY calculation. This should be a specialised form of the Solver Reporter that is adapted for reporting the progress of multiple attempted solve actions. There should be a progress bar showing how many of the "points" (not "steps") have been solved/attempted. The usual Solver Reporter should not appear.
  • When the process has finished, the box should disappear if there were no errors. Otherwise, the box should stay there, and there should be a "label" that reports the presence of errors (see below for flagging of "problem rows"). Details of the failures can be shown in the "error" tab for the moment.
  • Plot button. We need to work on more flexibility of plotting. The first thing is some way to indicate "x" and "y" variables for a simple plot. Perhaps you could try hand-drawing some sketches of possible GUI implementations, and scan/photo them and send me? This is a slightly different topic, but it all goes to making the "observer" tab a useful tool for working with out simulations.
  • In the Observer tab,
    1. If possible, can we "flag" a row in the table as being a "problem row" if the solver was not converged at the time the data was "kept". eg perhaps the font can be red, or there can be an icon at the left of the table?
      • Will do that along with the Study Reporter dialog

10 July 2011

Working on improving the Observers, Study and Plot functions in PyGTK GUI. In an e-mail John sent me on 8th July, he pointed out some bugs and gave many suggestions. I have categorised them here in two parts, depending on the status. -

Finished doing

  • When right-clicking in the Simulation tab, the "Study" option should only be available for Fixed variables. Otherwise it should be greyed out.
  • In the Study dialog,
    1. Remove "Units" from the right-hand side of the inputs.
    2. Make sure that checking of inputs is performed.
    3. Boxes with invalid input should be highlighted pink.
    4. The number of steps should be a user preference.
    5. Input focus for keyboard should be in the "lower bound" box when the dialog pops up, with the text selected so that use can start typing immediately.
    6. Does the box work properly when units are omitted? Did you re-use the code for this input box from elsewhere?
      • Yes, it wont proceed unless valid input is provided. Some of the code for checking Atom entries was taken from properties.py

PyGTK Study - 9.png

To Do

  • In the Study dialog,
    1. Add a check-box saying "continue on failure" and have the box checked by default
    2. Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)
  • A new "Study Reporter" dialog should pop up for the actual STUDY calculation. This should be a specialised form of the Solver Reporter that is adapted for reporting the progress of multiple attempted solve actions. There should be a progress bar showing how many of the "points" (not "steps") have been solved/attempted. The usual Solver Reporter should not appear.
  • When the process has finished, the box should disappear if there were no errors. Otherwise, the box should stay there, and there should be a "label" that reports the presence of errors (see below for flagging of "problem rows"). Details of the failures can be shown in the "error" tab for the moment.
  • In the Observer tab
    1. After a model is reloaded, a right-click in the "dead" Observer table results in an error
    2. If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
    3. If an observer tab is "dead" then the "add" button should be greyed out.
    4. Can you work out a way to remove a column from the observer?
      • Will do it.
    5. What happens when a column is added to an observer that already contains a number of rows... does it work OK?
      • Yes, it works Ok
    6. If possible, can we "flag" a row in the table as being a "problem row" if the solver was not converged at the time the data was "kept". eg perhaps the font can be red, or there can be an icon at the left of the table?
      • Should be possible, need to see.
  • If there are multiple Observers, does everything work OK? Check carefully.
    • As far as I checked, it was fine, will do more checking though.
  • Plot button. We need to work on more flexibility of plotting. The first thing is some way to indicate "x" and "y" variables for a simple plot. Perhaps you could try hand-drawing some sketches of possible GUI implementations, and scan/photo them and send me? This is a slightly different topic, but it all goes to making the "observer" tab a useful tool for working with out simulations.

7 July 2011

Just added the following features, as requested by John in a discussion held on 5th July -

1. Allow right-click in the Observer tab, so that if the user has selected a number of variables, they should then be able to do a study on any variable that's already selected.

PyGTK Study - 7.png

As you can see in the screenshot, you can study any variable by using the right click menu.

2. Remove selected row(s) from an Observer table.

  Now, this can be done in two ways- either by using the right click menu, or by selecting the row and pressing the "BackSpace" or "Delete" on the keyboard.

3. Clear the whole thing (but keeping the list of variables being 'observed'). - Was Already there !

4. Ability to delete an Observer tab, i.e., a close button with a confirmatory dialog box.

PyGTK Study - 8.png

4 July 2011

I have implemented the STUDY functionality in the PyGTK GUI partially. Its working for linear distribution of one variable. I need to complete it for the logarithmic distribution, that should not take much time. It is slightly different from what I had planned earlier.

Usage -

1. For all variables you want to watch, first you need to 'Observe' them.

PyGTK Study - 3.png

2. Then, just right click on the variable you want to "Study" and select Study.

PyGTK Study - 4.png

3. In the dialog box, one can set the upper bound, lower bound, number of steps, distribution type (linear or logarithmic) and there is also an option to run a particular method before each solving. For convenience, it retrieves the lower and upper bounds of the variable as mentioned in its properties.

PyGTK Study - 5.png

4. Clicking on OK does everything, and the results can be seen in the Observer tab.

PyGTK Study - 6.png

1 July 2011

Implementing the STUDY function in PyGTK GUI now. Had a discussion with John, and for the beginning it will only be 1-D, i.e, we will be varying only one parameter. The implementation will work together with the 'Observers' functionality which is already there.

The idea is that the user can 'observe' all the variables to be studied. Then, one can select which one of them will be varied. There will be a dialog box for setting the upper bound, lower bound, number of steps, distribution type (linear or logarithmic) and an option to run a particular method before each solving. We have also thought of adding a feature where the output data could be written to a file during the solving.

I plan to make it something like this -

PyGTK Study - 1.png

PyGTK Study - 2.png


27 Jun 2011

Almost completed the port from libglade to GTK Builder. A few warnings related to missing signal connect handlers remain.

Tried it on OS X, Ubuntu and Windows 7. Need to talk to Richard regarding easier setup in OS X. The main issue I am facing is whether to use Apple's Python or Python.org python.

Presently looking into :


12 Jun 2011

Some work on replacing libglade with Gtk Builder in the PyGTK GUI changeset 3483.

14 May 2011

After a discussion with John, the more important bugs to be fixed are

  • bug 423 Changing value of solved variable should force removal of 'solved' indication
  • bug 501 pygtk/ascdev fails to load solvers under Windows 7
  • bug 507 propagate var/relation 'solved' status up through model hierarchy in processVarStatus
  • bug 429 default units often not very useful
  • bug 472 slvreq: with SOLVER statement before FIX/FREE methods, model is not updated
  • bug 294 Implement 'STUDY' function in PyGTK GUI