ASCEND - User contributions [en]

User:Aakash

2011-08-20T02:23:56Z

Aakash: /* Summary of work done */

'''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: {{srcbranchdir|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:
*# Added the ability to delete an observer tab.
*# Rows can now be deleted, either by using the right click popup menu or the delete or backspace key.
*# Improved the way the observer tab behaves when the model is reloaded or a new model is loaded.
*# Better support for multiple observers.
*# 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:
*# Intuitive units of measurement checking.
*# Option of Logarithmic and Linear step distribution
*# Option to run a particular method before solving for each point.
*# 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.
*# 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.

* Fixed some bugs- {{bug|473}}, {{bug|360}}, {{bug|515}}, {{bug|510}}, {{bug|514}}, {{bug|331}}.

== 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",
*# Implement sorting of columns in the Observer. It would help in making plots work properly.
*# Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales
*# Add the ability to select line type using matplotlib specifiers like "r-", "b." etc.
*# 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,
*# It could be made faster by reducing the rate at which the GUI is updated.
*# 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.

*# 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.
*# 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 :
*# {{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

== 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.
** [[File: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,

*# Multiple rows can now be selected and deleted.
*#* [[File:PyGTK Study - 18.png]]
*# A column can now be preselected as a y-variable (for plotting) by right clicking on it and selecting plot.
*# 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.

* Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales

* 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.

*# 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.
*# 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,
*# Fixed a problem which was happening when you deleted a column, and then added a new column or row.
*# 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.
*#* [[File:PyGTK Study - 14.png]]
*# It is now possible select units of measurement in the Observer tab.
*#* [[File:PyGTK Study - 15.png]]
*# 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.
*# Implemented tooltips which display solver errors for rows in the Observer's tab
*#* [[File:PyGTK Study - 16.png]]

* Plot button,
*# Implemented the following interface to select the columns to be plotted.
*#* [[File:PyGTK Study - 17.png]]
*# 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 -
** [[File: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,
*# 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.
*#* [[File:PyGTK Study - 13.png]]

'''To Do'''

* In the Observer tab,
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)
[[File: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.
[[File: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,
*# 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.
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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
*# 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.
*# Lower bound now defaults to the current value of the variable.

* In the Observer tab
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*#* Fixed.
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*#* Done.
*# If an observer tab is "dead" then the "add" button should be greyed out.
*#* Done.
*# Can you work out a way to remove a column from the observer?
*#* Done.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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,
*# 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,
*# Remove "Units" from the right-hand side of the inputs.
*# Make sure that checking of inputs is performed.
*# Boxes with invalid input should be highlighted pink.
*# The number of steps should be a user preference.
*# 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.
*# 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

[[File:PyGTK Study - 9.png]]

'''To Do'''

* In the Study dialog,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*# If an observer tab is "dead" then the "add" button should be greyed out.
*# Can you work out a way to remove a column from the observer?
*#* Will do it.
*# 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
*# 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.

[[File: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.

[[File: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.

[[File:PyGTK Study - 3.png]]

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

[[File: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.

[[File:PyGTK Study - 5.png]]

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

[[File: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 -

[[File:PyGTK Study - 1.png]]

[[File: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 :

* {{bug|294}} - Need to discuss the implementation with John.
* {{bug|501}}

'''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

[[Category:GSOC2011]]
[[Category:ASCEND Contributors]]

User:Aakash

2011-08-19T16:35:25Z

Aakash:

'''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: {{srcbranchdir|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:
*# Added the ability to delete an observer tab.
*# Rows can now be deleted, either by using the right click popup menu or the delete or backspace key.
*# Improved the way the observer tab behaves when the model is reloaded or a new model is loaded.
*# Better support for multiple observers.
*# 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:
*# Intuitive units of measurement checking.
*# Option of Logarithmic and Linear step distribution
*# Option to run a particular method before solving for each point.
*# 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.
*# 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.

* Fixed some bugs- {{bug|473}}, {{bug||360}}, {{bug|515}}, {{bug|510}}, {{bug|514}}.

== 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",
*# Implement sorting of columns in the Observer. It would help in making plots work properly.
*# Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales
*# Add the ability to select line type using matplotlib specifiers like "r-", "b." etc.
*# 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,
*# It could be made faster by reducing the rate at which the GUI is updated.
*# 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.

*# 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.
*# 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 :
*# {{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

== 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.
** [[File: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,

*# Multiple rows can now be selected and deleted.
*#* [[File:PyGTK Study - 18.png]]
*# A column can now be preselected as a y-variable (for plotting) by right clicking on it and selecting plot.
*# 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.

* Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales

* 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.

*# 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.
*# 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,
*# Fixed a problem which was happening when you deleted a column, and then added a new column or row.
*# 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.
*#* [[File:PyGTK Study - 14.png]]
*# It is now possible select units of measurement in the Observer tab.
*#* [[File:PyGTK Study - 15.png]]
*# 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.
*# Implemented tooltips which display solver errors for rows in the Observer's tab
*#* [[File:PyGTK Study - 16.png]]

* Plot button,
*# Implemented the following interface to select the columns to be plotted.
*#* [[File:PyGTK Study - 17.png]]
*# 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 -
** [[File: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,
*# 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.
*#* [[File:PyGTK Study - 13.png]]

'''To Do'''

* In the Observer tab,
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)
[[File: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.
[[File: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,
*# 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.
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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
*# 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.
*# Lower bound now defaults to the current value of the variable.

* In the Observer tab
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*#* Fixed.
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*#* Done.
*# If an observer tab is "dead" then the "add" button should be greyed out.
*#* Done.
*# Can you work out a way to remove a column from the observer?
*#* Done.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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,
*# 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,
*# Remove "Units" from the right-hand side of the inputs.
*# Make sure that checking of inputs is performed.
*# Boxes with invalid input should be highlighted pink.
*# The number of steps should be a user preference.
*# 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.
*# 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

[[File:PyGTK Study - 9.png]]

'''To Do'''

* In the Study dialog,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*# If an observer tab is "dead" then the "add" button should be greyed out.
*# Can you work out a way to remove a column from the observer?
*#* Will do it.
*# 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
*# 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.

[[File: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.

[[File: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.

[[File:PyGTK Study - 3.png]]

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

[[File: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.

[[File:PyGTK Study - 5.png]]

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

[[File: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 -

[[File:PyGTK Study - 1.png]]

[[File: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 :

* {{bug|294}} - Need to discuss the implementation with John.
* {{bug|501}}

'''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

[[Category:GSOC2011]]
[[Category:ASCEND Contributors]]

User:Aakash

2011-08-19T16:32:37Z

Aakash:

'''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: {{srcbranchdir|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:
*# Added the ability to delete an observer tab.
*# Rows can now be deleted, either by using the right click popup menu or the delete or backspace key.
*# Improved the way the observer tab behaves when the model is reloaded or a new model is loaded.
*# Better support for multiple observers.
*# 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:
*# Intuitive units of measurement checking.
*# Option of Logarithmic and Linear step distribution
*# Option to run a particular method before solving for each point.
*# 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.
*# 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.

* Fixed some bugs- {{bug|473}}, {{bug||360}}, {{bug|515}}, {{bug|510}}, {{bug|514}}.

== 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 lot of things were suggested, and I worked on most of them. However, the following are some which still remain untouched by me:

* In the "Observer Tab",
*# Implement sorting of columns in the Observer. It would help in making plots work properly.
*# Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales
*# Add the ability to select line type using matplotlib specifiers like "r-", "b." etc.
*# 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,
*# It could be made faster by reducing the rate at which the GUI is updated.
*# 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.

*# 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.
*# 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 :
*# {{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

== 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.
** [[File: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,

*# Multiple rows can now be selected and deleted.
*#* [[File:PyGTK Study - 18.png]]
*# A column can now be preselected as a y-variable (for plotting) by right clicking on it and selecting plot.
*# 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.

* Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales

* 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.

*# 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.
*# 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,
*# Fixed a problem which was happening when you deleted a column, and then added a new column or row.
*# 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.
*#* [[File:PyGTK Study - 14.png]]
*# It is now possible select units of measurement in the Observer tab.
*#* [[File:PyGTK Study - 15.png]]
*# 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.
*# Implemented tooltips which display solver errors for rows in the Observer's tab
*#* [[File:PyGTK Study - 16.png]]

* Plot button,
*# Implemented the following interface to select the columns to be plotted.
*#* [[File:PyGTK Study - 17.png]]
*# 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 -
** [[File: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,
*# 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.
*#* [[File:PyGTK Study - 13.png]]

'''To Do'''

* In the Observer tab,
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)
[[File: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.
[[File: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,
*# 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.
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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
*# 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.
*# Lower bound now defaults to the current value of the variable.

* In the Observer tab
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*#* Fixed.
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*#* Done.
*# If an observer tab is "dead" then the "add" button should be greyed out.
*#* Done.
*# Can you work out a way to remove a column from the observer?
*#* Done.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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,
*# 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,
*# Remove "Units" from the right-hand side of the inputs.
*# Make sure that checking of inputs is performed.
*# Boxes with invalid input should be highlighted pink.
*# The number of steps should be a user preference.
*# 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.
*# 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

[[File:PyGTK Study - 9.png]]

'''To Do'''

* In the Study dialog,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*# If an observer tab is "dead" then the "add" button should be greyed out.
*# Can you work out a way to remove a column from the observer?
*#* Will do it.
*# 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
*# 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.

[[File: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.

[[File: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.

[[File:PyGTK Study - 3.png]]

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

[[File: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.

[[File:PyGTK Study - 5.png]]

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

[[File: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 -

[[File:PyGTK Study - 1.png]]

[[File: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 :

* {{bug|294}} - Need to discuss the implementation with John.
* {{bug|501}}

'''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

[[Category:GSOC2011]]
[[Category:ASCEND Contributors]]

User:Aakash

2011-08-19T14:35:45Z

Aakash: /* Progress reports */

'''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: {{srcbranchdir|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.

== 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.
** [[File: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,

*# Multiple rows can now be selected and deleted.
*#* [[File:PyGTK Study - 18.png]]
*# A column can now be preselected as a y-variable (for plotting) by right clicking on it and selecting plot.
*# 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.

* Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales

* 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.

*# 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.
*# 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,
*# Fixed a problem which was happening when you deleted a column, and then added a new column or row.
*# 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.
*#* [[File:PyGTK Study - 14.png]]
*# It is now possible select units of measurement in the Observer tab.
*#* [[File:PyGTK Study - 15.png]]
*# 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.
*# Implemented tooltips which display solver errors for rows in the Observer's tab
*#* [[File:PyGTK Study - 16.png]]

* Plot button,
*# Implemented the following interface to select the columns to be plotted.
*#* [[File:PyGTK Study - 17.png]]
*# 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 -
** [[File: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,
*# 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.
*#* [[File:PyGTK Study - 13.png]]

'''To Do'''

* In the Observer tab,
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)
[[File: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.
[[File: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,
*# 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.
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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
*# 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.
*# Lower bound now defaults to the current value of the variable.

* In the Observer tab
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*#* Fixed.
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*#* Done.
*# If an observer tab is "dead" then the "add" button should be greyed out.
*#* Done.
*# Can you work out a way to remove a column from the observer?
*#* Done.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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,
*# 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,
*# Remove "Units" from the right-hand side of the inputs.
*# Make sure that checking of inputs is performed.
*# Boxes with invalid input should be highlighted pink.
*# The number of steps should be a user preference.
*# 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.
*# 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

[[File:PyGTK Study - 9.png]]

'''To Do'''

* In the Study dialog,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*# If an observer tab is "dead" then the "add" button should be greyed out.
*# Can you work out a way to remove a column from the observer?
*#* Will do it.
*# 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
*# 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.

[[File: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.

[[File: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.

[[File:PyGTK Study - 3.png]]

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

[[File: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.

[[File:PyGTK Study - 5.png]]

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

[[File: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 -

[[File:PyGTK Study - 1.png]]

[[File: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 :

* {{bug|294}} - Need to discuss the implementation with John.
* {{bug|501}}

'''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

[[Category:GSOC2011]]
[[Category:ASCEND Contributors]]

File:PyGTK Study - 19.png

2011-08-19T14:33:59Z

Aakash:

User:Aakash

2011-08-19T14:33:35Z

Aakash:

'''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: {{srcbranchdir|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.

== Progress reports ==

'''19 Aug 2011'''

The work done in the last few days :

* Implemented Automatic Weekly Update checking and fixed a .
* Implemented better units of measurement checking in the "Variable Properties" dialog box.
** [[File: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,

*# Multiple rows can now be selected and deleted.
*#* [[File:PyGTK Study - 18.png]]
*# A column can now be preselected as a y-variable (for plotting) by right clicking on it and selecting plot.
*# 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.

* Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales

* 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.

*# 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.
*# 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,
*# Fixed a problem which was happening when you deleted a column, and then added a new column or row.
*# 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.
*#* [[File:PyGTK Study - 14.png]]
*# It is now possible select units of measurement in the Observer tab.
*#* [[File:PyGTK Study - 15.png]]
*# 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.
*# Implemented tooltips which display solver errors for rows in the Observer's tab
*#* [[File:PyGTK Study - 16.png]]

* Plot button,
*# Implemented the following interface to select the columns to be plotted.
*#* [[File:PyGTK Study - 17.png]]
*# 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 -
** [[File: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,
*# 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.
*#* [[File:PyGTK Study - 13.png]]

'''To Do'''

* In the Observer tab,
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)
[[File: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.
[[File: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,
*# 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.
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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
*# 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.
*# Lower bound now defaults to the current value of the variable.

* In the Observer tab
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*#* Fixed.
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*#* Done.
*# If an observer tab is "dead" then the "add" button should be greyed out.
*#* Done.
*# Can you work out a way to remove a column from the observer?
*#* Done.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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,
*# 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,
*# Remove "Units" from the right-hand side of the inputs.
*# Make sure that checking of inputs is performed.
*# Boxes with invalid input should be highlighted pink.
*# The number of steps should be a user preference.
*# 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.
*# 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

[[File:PyGTK Study - 9.png]]

'''To Do'''

* In the Study dialog,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*# If an observer tab is "dead" then the "add" button should be greyed out.
*# Can you work out a way to remove a column from the observer?
*#* Will do it.
*# 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
*# 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.

[[File: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.

[[File: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.

[[File:PyGTK Study - 3.png]]

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

[[File: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.

[[File:PyGTK Study - 5.png]]

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

[[File: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 -

[[File:PyGTK Study - 1.png]]

[[File: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 :

* {{bug|294}} - Need to discuss the implementation with John.
* {{bug|501}}

'''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

[[Category:GSOC2011]]
[[Category:ASCEND Contributors]]

User:Aakash

2011-08-07T15:21:37Z

Aakash: /* Progress reports */

'''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: {{srcbranchdir|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.

== Progress reports ==

'''7 Aug 2011'''

The progress made this week is as follows-

'''Done'''

* In the Observer tab,

*# Multiple rows can now be selected and deleted.
*#* [[File:PyGTK Study - 18.png]]
*# A column can now be preselected as a y-variable (for plotting) by right clicking on it and selecting plot.
*# 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.

* Extend the plotting interface for (optionally) dual plots, example - http://matplotlib.sourceforge.net/examples/api/two_scales.html#api-two-scales

* 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.

*# 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.
*# 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,
*# Fixed a problem which was happening when you deleted a column, and then added a new column or row.
*# 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.
*#* [[File:PyGTK Study - 14.png]]
*# It is now possible select units of measurement in the Observer tab.
*#* [[File:PyGTK Study - 15.png]]
*# 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.
*# Implemented tooltips which display solver errors for rows in the Observer's tab
*#* [[File:PyGTK Study - 16.png]]

* Plot button,
*# Implemented the following interface to select the columns to be plotted.
*#* [[File:PyGTK Study - 17.png]]
*# 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 -
** [[File: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,
*# 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.
*#* [[File:PyGTK Study - 13.png]]

'''To Do'''

* In the Observer tab,
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# Study dialog should disappear after clicking "ok" (see below, Study Reporter should pop up)
[[File: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.
[[File: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,
*# 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.
*# Fix problems regarding the observer tab when different model is loaded, without reloading the file.
*# 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
*# 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.
*# Lower bound now defaults to the current value of the variable.

* In the Observer tab
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*#* Fixed.
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*#* Done.
*# If an observer tab is "dead" then the "add" button should be greyed out.
*#* Done.
*# Can you work out a way to remove a column from the observer?
*#* Done.
*# 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,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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,
*# 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,
*# Remove "Units" from the right-hand side of the inputs.
*# Make sure that checking of inputs is performed.
*# Boxes with invalid input should be highlighted pink.
*# The number of steps should be a user preference.
*# 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.
*# 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

[[File:PyGTK Study - 9.png]]

'''To Do'''

* In the Study dialog,
*# Add a check-box saying "continue on failure" and have the box checked by default
*# 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
*# After a model is reloaded, a right-click in the "dead" Observer table results in an error
*# If an observer tab is "dead" clearing the Observer should be the same as closing it (confirmation dialog should pop up, etc)
*# If an observer tab is "dead" then the "add" button should be greyed out.
*# Can you work out a way to remove a column from the observer?
*#* Will do it.
*# 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
*# 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.

[[File: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.

[[File: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.

[[File:PyGTK Study - 3.png]]

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

[[File: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.

[[File:PyGTK Study - 5.png]]

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

[[File: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 -

[[File:PyGTK Study - 1.png]]

[[File: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 :

* {{bug|294}} - Need to discuss the implementation with John.
* {{bug|501}}

'''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

[[Category:GSOC2011]]
[[Category:ASCEND Contributors]]

File:PyGTK Study - 18.png

2011-08-07T15:21:28Z

Aakash:

User:Aakash

2011-06-22T16:39:33Z

Aakash: /* Windows 7 64-bit with 32-bit Python */

This page contains specific instructions for building ASCEND on systems that we know about. First you should read about [[VersionManagement]] for information on how to get hold of the source code.

Building ASCEND (as of March 2006) requires the [http://www.scons.org/ SCons] build tool. In our opinion, SCons is a significant advance on Autotools, so we encourage you to give it a chance, if you're not familiar with it.

<s>'''Note:''' If you are having trouble building ASCEND, it might be worth checking out the [[BuildBot]] (link [http://ascend.cheme.cmu.edu:8011/ here]) to see if the latest sources have compiled correctly on our test server.</s>

== General instructions ==

Building with SCons (as of Jun 2010, we recommend version 1.x) should be as simple as typing

<source lang="a4c">scons</source>

Get info on the [[SCons_options_for_building_ASCEND|current build options]] by typing <tt>scons -Qh</tt>. To clean up after your build, type <tt>scons -c</tt>. To include any building options, type <tt>scons</tt> followed by options. For instance, type <tt>scons WITH_LOCAL_HELP = /usr/local/share/ascend/manual</tt>.

Any build option that you see in <tt>scons -Qh</tt> can be entered into a file <tt>config.py</tt> that you can create in the root source directory (ie <tt>~/src/ascend/trunk</tt>). For example, you might create a config.py file like this:

<pre>WITH_LOCAL_HELP = /usr/local/share/ascend/manual
DEFAULT_ASCENDLIBRARY = /usr/local/share/ascend/models
</pre>

So, if you want to set configuration options so that they always get applied, edit your <tt>config.py</tt> file.

On top of that, you should also be aware that the SCons build will cache your build options in a file called <tt>options.cache</tt>. That means that if you type a scons command with command-line options, then later without those command line options, the options from the first run will still be there, because they will have been saved in the cache.

A major fiddle with SCons, especially on Windows, is ensuring that all the required programs are present in your path. You need to install Bison (from the GnuWin32 project). For SCons to run correctly from the MSYS command line, you will also need to add <tt>/c/Python25/Scripts:/c/Python25</tt> to your path, so that the 'scons' script is discovered.

The SCons system will manage the building of FORTRAN components and is able to link to an installed version of CONOPT.

For instructions on building with Autotools, see the old versions of this page. We're not actively supporting the Autotools build any more.

Running <tt>scons</tt> will create a locally-executable version of ASCEND that can be run from the source tree (<tt>pygtk/ascdev</tt> or <tt>tcltk/generic/interface/ascend4</tt>, possibly subject to some environment variable settings. Alternatively, you can install ASCEND and run it from a 'proper' location such as ~/bin/ascend or /usr/bin/ascend, etc. To install files for ASCEND, run

<source lang="a4c">scons install INSTALL_PREFIX=/usr/local</source>

The above will install the PyGTK GUI at /usr/local/bin/ascend and the Tcl/Tk GUI at /usr/local/bin/ascend4. Other sensible values of INSTALL_PREFIX include <tt>~/ascend</tt> or <tt>~</tt>, which will install the PyGTK GUI at ~/ascend/bin/ascend and ~/bin/ascend respectively. These latter ones are good if you don't have root privileges on your system. There are a range of other INSTALL_* options available with our build script, type <tt>scons -qH</tt> to see them. Also note the importance of the <tt>ABSOLUTE_PATHS</tt> option for our build script. Note then when you run '<tt>scons install</tt>' you don't get all the files in the model library, you only get a filter set according to the [[PACKAGE metafiles]] contained in the [[ModelLibrary]].

Some more details on the implementation of the ASCEND build process via SCons is given in [[Developer's_Manual#Build_system]].

== Tcl/Tk GUI ==

In order to build the original Tck/Tk GUI, you need a Tcl/Tk distribution. Recently we have modified ASCEND so that it can run with Tcl/Tk 8.4. Standard Tcl/Tk binary packages can be used, such as those included in Fedora Core 5 (Note, the tcl-devel and tk-devel packages required as well). For Windows they available from ActiveState, see:

http://www.activestate.com/activetcl

At present, detection of Tcl/Tk is not particularly sophisticated. <tt>SConstruct</tt> just looks for <tt>tcl.h</tt> in your standard include path. So you might need to tweak. Check the <tt>scons -h</tt> list of configuration options for more. On Debian-based systems, try something like <tt>scons TCL_CPPPATH=/usr/include/tcl8.4</tt>

== Python interface ==

See PythonWrapper for more information. You will need to have SWIG 1.3.24 or newer and Python 2.4 or newer installed. These are both easy to install for both Windows and Linux.

To run the PyGTK interface requires more dependencies, see the PythonWrapper page for full details.

== Instructions for Linux ==

In general, see [[Prerequisites for Linux]]. You will be using <tt>scons</tt> to build ASCEND. We update these distribution-specific notes at the time that we implement support for that particular distro, so it's possible that if you're using an old distro, you may need to go back and use an old version of the code.

=== Ubuntu 10.10 ===

ASCEND compiles fine on Ubuntu 10.10, but you need to use the latest code from the 'trunk' of our [[VersionManagement|subversion repo]]. Subversion r3082 corrects a bug that was preventing use of SCons 2.x, as supplied as part of this distro. Otherwise, required packages are the same as for 10.04, see below. It is recommended that all 'optional' packages are installed at the time of building ASCEND.

For IPOPT, which is an optional component of ASCEND, you should see the build instructions [[IPOPT|here]].

It appears that in Ubuntu 10.10, GraphViz has been upgraded and is not longer compatible with ASCEND. ASCEND should build fine without it, although you will be missing the [[incidence graph]] feature as a result (see {{bug|443}}).

=== Ubuntu 10.04 ===

<s>There is currently a problem with building ASCEND on this platform, due to an error thrown by SWIG version 1.3.40 (ASCEND {{bug|403}}). This error is not seen when running SWIG version 1.3.38 or earlier. ''A temporary workaround is to install the Ubuntu Karmic version if SWIG, available [http://packages.ubuntu.com/karmic/i386/swig/download from here].''</s> (this bug is now fixed in the subversion repo)

For [[IPOPT]], which is an optional solver that can be used by ASCEND, you should additionally see the build instructions [[IPOPT|here]].

To build ASCEND on a clean Ubuntu 10.04 box, the following packages were required (as of trunk r2777):

* subversion
* swig <s>''(see note above)''</s>
* g++
* gfortran
* python-dev
* scons

The following are optional but recommended:

* flex
* bison
* graphviz-dev
* libsundials-serial-dev
* liblapack-dev (used by IPOPT)
* tcl8.5-dev
* tk8.5-dev
* libtktable2.9
* libblas-dev

At runtime, the following packages will add capability to ASCEND:
* ipython
* python-matplotlib

=== Kubuntu 10.04 ===

Building on Kubuntu (KDE) is identical to Ubuntu (GNOME) with the exception that python-gtk2 and python-glade2 must be installed before running the resulting program. This was tested with trunk r3039. At this point in time, building also requires the package libgsl0-dev, because of some dependencies in [[FPROPS]] which need to be removed/made optional.

=== Ubuntu 9.10 ===

Ongoing development of ASCEND is primarily done on this Ubuntu 9.10. Although ASCEND builds against the standard Ubuntu packages for Sundials, you will obtain better functionality with the [[IDA]] solver if you use a version built from latest 2.4.0 source code. The latest release fixes problems with boundary-crossing during integration.

To build ASCEND on a clean Ubuntu 9.10 box, the following packages are required (as of trunk r2667):

* scons
* swig
* python-dev
* scons
* g++
* gfortran

The following packages are optional:

* libsundials-serial-dev
* graphviz-dev
* flex
* bison
* libblas-dev
* tcl8.5-dev
* tk8.5-dev
* tktable2.9

At runtime, the following packages will add capability to ASCEND:

* ipython
* python-matplotlib

For the [[IPOPT]] solver, you will also need to build that separately from source -- see [[IPOPT]] for details.
For the [[CONOPT]] and [[CMSlv]] solvers, you must obtain libconsub3.so, see [[CONOPT]] for details.

=== Ubuntu 9.04 ===

ASCEND should build on this system without any problems, providing the prerequisited that you need are installed. Watch closely the 'scons' output for fleeting comments which may suggest that you're missing a library or a header file, etc. Prereqs should be the same as for Ubuntu 8.04.

Note that after updating to Ubuntu 9.04, you will probably need to rebuild and reinstall things like IPOPT and CONOPT, as gfortran errors seem to arise otherwise.

For the [[IDA]] solver, you may need to add the scons option SUNDIALS_CPPPATH=/usr/include/sundials to make this integrator build correctly.

=== Ubuntu 8.04 LTS ===

ASCEND built fine on Ubuntu 8.0.4 LTS when we last tried it. Numerous prerequisites must be installed, but all of these except IPOPT and CONOPT are currently available from the Ubuntu repositories. Specifically, check libsundials-serial-dev, swig, flex, bison, python-dev, tk-dev, libtktable2.9. Haven't yet tested with CONOPT, so conditional modelling has not yet been checked.

Special treatment for the gfortran compiler is no longer required (as was required for Ubuntu 7.10).

Building of a .deb package can be performed using the [[dtar]] tool included in the source distribution. Usage: scons dist && ~/ascend/tools/dtar/dtar ~/ascend/dist/ascend-0.9.5.116.tar.bz2 ~/ascend/dist/debian.tar.gz.

Ubuntu 8.04 uses GtkSourceView2 instead of the earlier version, with the result that source code highlighting in GEdit using a different <tt>.lang</tt> file. We have written a new version of this file, see the page on [[syntax highlighting]] for more info.

Currently, LyX 1.5 is not available on Ubuntu, and the manual .lyx files require this newer version. So for the moment, you must use <tt>scons WITH_DOC_BUILD=0</tt>.

ASCEND has been runninng on earlier Ubuntu versions, right back to version 5.10.

=== Fedora 11 ===

The following steps build ASCEND on a clean Fedora 11 machine (I tested using the Live CD installed to a qemu/kvm virtual machine):

<source lang="a4c">su
yum install scons subversion tk-devel flex bison gcc-gfortran gcc-c++ python-devel sundials-devel graphviz-devel swig
scons</source>

<s>Currently (as of 16 Jun 2009), the above results in a error message from g++ while compiling the SWIG output. See {{bug|403}}. Testing on Windows has shown that SWIG 1.3.39 and 1.3.40 have this problem, but 1.3.36 does not have this problem.</s> ''This bug is fixed in the pre-0.9.8 code from our SVN server.''

=== Fedora 9 ===

ASCEND builds without any problems on Fedora 9. You need to install several packages first, including swig, tk-devel, python-devel, scons, flex, bison, gcc-gfortran, gcc-c++. There may be some problems getting the GraphViz and CUnit-related functionality working, let us know if you have problems with that. -- JP, Jun 2008.

You can build an RPM version of ASCEND using <tt>scons dist</tt> followed by <tt>rpm -ta ascend-0.9.5.116.tar.bz2</tt>, providing you have RPM correctly set up. See also [[Building an RPM Package for ASCEND]].

=== OpenSUSE ===

OpenSUSE does not provide an up to date version of SCons (as of this writing, suse 10.2 comes with scons-0.96.91-37). You will need to download a newer version (0.96.93) ([http://sourceforge.net/project/showfiles.php?group_id=30337&package_id=22359 from SF.net].
Do not try 0.97 SCons, as it is not yet supported by the ASCEND SConscripts on the SUSE platform.

''Update (Mar 2010)'' it is suggested that you try latest SCons 1.x if possible, and report your experiences here.

=== Arch Linux ===

To build ASCEND on Arch Linux, follow these steps:

<source lang="a4c">sudo pacman -S gcc gcc-fortran flex bison python scons swig tcl tk graphviz blas</source>

Download and build sundials manually (see [[Prerequisites for Linux]]).

Then follow the [[Building_ASCEND#General_instructions|Genereal instructions]] (running scons and scons install).

If you have problem with SWIG 1.3.40 (scons reports that SWIG package was not found), download older version of [http://www.swig.org SWIG](1.3.38 worked for me, 1.3.24 didn't) and build it manually (./configure, make, make install). Then re-run swig with parameter <tt>SWIG=/usr/local/bin/swig</tt> (or different location where you installed SWIG).

When running ascend script:

<source lang="a4c">LDPATH = [INSTALL_LIB] + GTKLIBPATH + LDPATH
TypeError: can only concatenate list (not "NoneType") to list</source>
<source lang="a4c">LDPATH = [INSTALL_LIB] + GTKLIBPATH + LDPATH</source>
<source lang="a4c">if GTKLIBPATH:
LDPATH = [INSTALL_LIB] + GTKLIBPATH + LDPATH
else:

LDPATH = [INSTALL_LIB] + LDPATH</source>

(found [http://www.mail-archive.com/ascend-sim-users@lists.sourceforge.net/msg00089.html here]).

=== Gentoo ===

Some details for build ASCEND on Gentoo Linux are on a sub-page at [[Building ASCEND/Gentoo]].

== Instructions for Windows ==

The only currently-supported way to build ASCEND on Windows is using MinGW/MSYS and the GCC compiler. There has previously been partial success with the Microsoft compiler tools, but these are not currently actively being used or tested.

=== Windows 7 64-bit with 32-bit Python ===

We are currently in the process of testing the ASCEND build on 64-bit Windows 7, running via Virtual Box on a Dell Optiplex 980, with the host OS being Ubuntu 10.04.2 LTS.

* install 'mingw-get-inst', selecting to install C, C++ and Fortran compilers, plus the MSYS Basic System and the MinGW Developer Toolkit.
* install the [http://sourceforge.net/projects/win32svn/files/1.6.15/Setup-Subversion-1.6.15.msi/download win32svn package] from SF.net
* check out the source code from our [[VersionManagement|svn trunk]].
* download [http://www.python.org/download Python 2.7.1] 32-bit version and install with default settings. Python 3 is likely still to cause problems with our code, and we haven't tested it yet. We tried using the 64-bit version of Python 2.7.1, but SCons didn't seem to be able to detect it.
* download [http://sourceforge.net/projects/win32svn/files/1.6.15/Setup-Subversion-1.6.15.msi/download Glade3] and install it.
* download [http://sourceforge.net/projects/scons/files/scons/2.0.1/scons-2.0.1.win32.exe/download SCons 2.0.1] and install it by right-clicking and 'run as administrator' (note that failing to do this might have been the reason that we failed with the 64-bit version of Python, above -- if you get 64-bit Python to work, let us know).
* Add c:\Python27 and c:\Python27\Scripts to your PATH.
* download [http://sourceforge.net/projects/swig/files/swigwin/swigwin-1.3.40/swigwin-1.3.40.zip/download swigwin 1.3.40] and unzip it into your MSYS home directory, then add ~/swigwin-1.3.40 to your PATH.
* download [http://prdownloads.sourceforge.net/gnuwin32/flex-2.5.4a-1.exe?download Flex 2.5.4a] and [http://downloads.sourceforge.net/gnuwin32/bison-2.4.1-setup.exe Bison 2.4.1] from gnuwin32.sf.net, and install them. Add the c:\Program Files (x86)\GnuWin32\bin location to your PATH.
* run scons from within your ASCEND working directory.
* the build process completes successfully

To actually run the resulting binary, you need to also have PyGTK and GTK+ installed on your machine. The best way to do that is via the [http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.22/ new PyGTK All-in-One installer].

The resulting binary can then be run from the MSYS prompt using the following, providing GTK is available in the PATH:
cd ~/ascend
pygtk/ascdev

We have a mechanism for [[building a installer for ASCEND on Windows]] that makes use of NSIS. We are in the process of testing it on Windows 7.

As an aside, the above highlights that it would be desirable to move from the use of libglade to GtkBuilder (as noted {{bug|493}}). We would then be able to use standard PyGTK installers again, rather than needing the huge PyGTK-All-In-One with the optional libglade.dll that it includes.

=== Windows XP with MinGW/MSYS ===

''It is currently suggested that you attempt the same process as given above for Windows 7, instead of that given below.''

The following instructions were tested on 32 bit Windows XP running on a DELL Precision (Core 2 Duo) machine in Nov 2009 and 32 bit Windows VISTA running on a ThinkPad X61 (Core 2 Duo) machine in March 2010.

First install the MinGW/MSYS environment. Download MinGW-5.1.6.exe, and select the basic options plus 'g++' (the C++ compiler). Then download and install MSYS-1.0.11.exe.

Now install Python-2.6.4.msi.

Install pywin32-214.win32-py2.6.exe.

Next, download and install SCons, scons-1.2.0.win32.exe.

Download swigwin-1.3.36 (''later versions are OK'') and unzip it in your root directory (it's just a folder with that name).

Download and install Flex (2.5.4a-1) and Bison (2.4.1) from GnuWin32, installing in the default location.

Download GFortran 'native installer' for MinGW from [http://gcc.gnu.org/wiki/GFortranBinaries]. Our release was dated '2009-04-21'.

With a right-click on the My Computer icon, then in the Advanced tab, add the following to your PATH environment variable (no quotes): ';c:\Python26;c:\Python26\Scripts;c:\swigwin-1.3.36;c:\Program Files\GnuWin32\bin;C:\Program Files\gfortran\bin'. For Windows VISTA system, right-click on the Computer icon, choose Properties. In Advance System Settings, you can configure PATH environment variable.

Install NSIS 2.45.

Download '[[Media:Book.pdf|book.pdf]]' and save it as 'book.pdf' in ~/ascend/doc.

In MSYS, run <tt>scons WITH_DOC_BUILD=0 installer</tt>.

The above will allow you to build ASCEND (and also to build the ASCEND installer using {{src|nsis/installer.nsi}}) but not to run it. For that, you additionally need to complete the following steps:

* Download and install the GTK Glade3 windows installer [http://ftp.gnome.org/pub/GNOME/binaries/win32/glade3/3.6/glade3-3.6.7-with-GTK+.exe]
* Download and install PyGTK [http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.12/pygtk-2.12.1-3.win32-py2.6.exe]
* Download and install PyCairo [http://ftp.gnome.org/pub/GNOME/binaries/win32/pycairo/1.4/pycairo-1.4.12-2.win32-py2.6.exe]
* Download and install PyGObject [http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.2-2.win32-py2.6.exe]

The above Glade3 installer should have added 'c:\Program Files\Gtk+\bin' to your PATH; you can check that if necessary.

To test the installer, it is recommended you remove GTK Glade3, PyGTK, PyCairo, PyGObject, Tcl/Tk and Python. Then run the installer, and it should discover all those missing things and proceed to reinstall them for you.

[[Image:mingw-1.png]]
[[Image:mingw-6.png]]

'''SUNDIALS'''. If you want to use the [[IDA]] integrator (recommended) then you should download and install SUNDIALS. See [[building SUNDIALS on Windows]].

Everything should build and you should end up with a file dist/ascend-{version}.exe which is your 'setup' program. Run that then find ASCEND in your Start menu.

=== MSVC ===

We don't currently support the use of Microsoft compilers. They probably can be made to work, but we don't see any good reason to work on that.

=== Windows / Borland C Builder ===

Some very early efforts to support free Borland 5.5 were made; the core engine basically compiles but there is more work to be done.

== Instructions for Mac ==

=== Mac OS X 10.5 ===

ASCEND runs fine on Mac OS X 10.5, and probably other versions. Currently we haven't completed the job of bundling ASCEND into a convenient distributable form, but the work is now well underway. See [[Porting to Mac]] for details.

There has been no attempt to build or test the Tcl/Tk GUI on Mac at this stage.

== See also ==

* [[Building a Debian package]]
* [[Building an RPM Package for ASCEND]]
* [[Windows Miscellany]]

[[Category:Development]]
[[Category:Documentation]]

Building ASCEND

2011-06-22T16:26:11Z

Aakash: Added download links for scons for windows and swigwin

This page contains specific instructions for building ASCEND on systems that we know about. First you should read about [[VersionManagement]] for information on how to get hold of the source code.

Building ASCEND (as of March 2006) requires the [http://www.scons.org/ SCons] build tool. In our opinion, SCons is a significant advance on Autotools, so we encourage you to give it a chance, if you're not familiar with it.

<s>'''Note:''' If you are having trouble building ASCEND, it might be worth checking out the [[BuildBot]] (link [http://ascend.cheme.cmu.edu:8011/ here]) to see if the latest sources have compiled correctly on our test server.</s>

== General instructions ==

Building with SCons (as of Jun 2010, we recommend version 1.x) should be as simple as typing

<source lang="a4c">scons</source>

Get info on the [[SCons_options_for_building_ASCEND|current build options]] by typing <tt>scons -Qh</tt>. To clean up after your build, type <tt>scons -c</tt>. To include any building options, type <tt>scons</tt> followed by options. For instance, type <tt>scons WITH_LOCAL_HELP = /usr/local/share/ascend/manual</tt>.

Any build option that you see in <tt>scons -Qh</tt> can be entered into a file <tt>config.py</tt> that you can create in the root source directory (ie <tt>~/src/ascend/trunk</tt>). For example, you might create a config.py file like this:

<pre>WITH_LOCAL_HELP = /usr/local/share/ascend/manual
DEFAULT_ASCENDLIBRARY = /usr/local/share/ascend/models
</pre>

So, if you want to set configuration options so that they always get applied, edit your <tt>config.py</tt> file.

On top of that, you should also be aware that the SCons build will cache your build options in a file called <tt>options.cache</tt>. That means that if you type a scons command with command-line options, then later without those command line options, the options from the first run will still be there, because they will have been saved in the cache.

A major fiddle with SCons, especially on Windows, is ensuring that all the required programs are present in your path. You need to install Bison (from the GnuWin32 project). For SCons to run correctly from the MSYS command line, you will also need to add <tt>/c/Python25/Scripts:/c/Python25</tt> to your path, so that the 'scons' script is discovered.

The SCons system will manage the building of FORTRAN components and is able to link to an installed version of CONOPT.

For instructions on building with Autotools, see the old versions of this page. We're not actively supporting the Autotools build any more.

Running <tt>scons</tt> will create a locally-executable version of ASCEND that can be run from the source tree (<tt>pygtk/ascdev</tt> or <tt>tcltk/generic/interface/ascend4</tt>, possibly subject to some environment variable settings. Alternatively, you can install ASCEND and run it from a 'proper' location such as ~/bin/ascend or /usr/bin/ascend, etc. To install files for ASCEND, run

<source lang="a4c">scons install INSTALL_PREFIX=/usr/local</source>

The above will install the PyGTK GUI at /usr/local/bin/ascend and the Tcl/Tk GUI at /usr/local/bin/ascend4. Other sensible values of INSTALL_PREFIX include <tt>~/ascend</tt> or <tt>~</tt>, which will install the PyGTK GUI at ~/ascend/bin/ascend and ~/bin/ascend respectively. These latter ones are good if you don't have root privileges on your system. There are a range of other INSTALL_* options available with our build script, type <tt>scons -qH</tt> to see them. Also note the importance of the <tt>ABSOLUTE_PATHS</tt> option for our build script. Note then when you run '<tt>scons install</tt>' you don't get all the files in the model library, you only get a filter set according to the [[PACKAGE metafiles]] contained in the [[ModelLibrary]].

Some more details on the implementation of the ASCEND build process via SCons is given in [[Developer's_Manual#Build_system]].

== Tcl/Tk GUI ==

In order to build the original Tck/Tk GUI, you need a Tcl/Tk distribution. Recently we have modified ASCEND so that it can run with Tcl/Tk 8.4. Standard Tcl/Tk binary packages can be used, such as those included in Fedora Core 5 (Note, the tcl-devel and tk-devel packages required as well). For Windows they available from ActiveState, see:

http://www.activestate.com/activetcl

At present, detection of Tcl/Tk is not particularly sophisticated. <tt>SConstruct</tt> just looks for <tt>tcl.h</tt> in your standard include path. So you might need to tweak. Check the <tt>scons -h</tt> list of configuration options for more. On Debian-based systems, try something like <tt>scons TCL_CPPPATH=/usr/include/tcl8.4</tt>

== Python interface ==

See PythonWrapper for more information. You will need to have SWIG 1.3.24 or newer and Python 2.4 or newer installed. These are both easy to install for both Windows and Linux.

To run the PyGTK interface requires more dependencies, see the PythonWrapper page for full details.

== Instructions for Linux ==

In general, see [[Prerequisites for Linux]]. You will be using <tt>scons</tt> to build ASCEND. We update these distribution-specific notes at the time that we implement support for that particular distro, so it's possible that if you're using an old distro, you may need to go back and use an old version of the code.

=== Ubuntu 10.10 ===

ASCEND compiles fine on Ubuntu 10.10, but you need to use the latest code from the 'trunk' of our [[VersionManagement|subversion repo]]. Subversion r3082 corrects a bug that was preventing use of SCons 2.x, as supplied as part of this distro. Otherwise, required packages are the same as for 10.04, see below. It is recommended that all 'optional' packages are installed at the time of building ASCEND.

For IPOPT, which is an optional component of ASCEND, you should see the build instructions [[IPOPT|here]].

It appears that in Ubuntu 10.10, GraphViz has been upgraded and is not longer compatible with ASCEND. ASCEND should build fine without it, although you will be missing the [[incidence graph]] feature as a result (see {{bug|443}}).

=== Ubuntu 10.04 ===

<s>There is currently a problem with building ASCEND on this platform, due to an error thrown by SWIG version 1.3.40 (ASCEND {{bug|403}}). This error is not seen when running SWIG version 1.3.38 or earlier. ''A temporary workaround is to install the Ubuntu Karmic version if SWIG, available [http://packages.ubuntu.com/karmic/i386/swig/download from here].''</s> (this bug is now fixed in the subversion repo)

For [[IPOPT]], which is an optional solver that can be used by ASCEND, you should additionally see the build instructions [[IPOPT|here]].

To build ASCEND on a clean Ubuntu 10.04 box, the following packages were required (as of trunk r2777):

* subversion
* swig <s>''(see note above)''</s>
* g++
* gfortran
* python-dev
* scons

The following are optional but recommended:

* flex
* bison
* graphviz-dev
* libsundials-serial-dev
* liblapack-dev (used by IPOPT)
* tcl8.5-dev
* tk8.5-dev
* libtktable2.9
* libblas-dev

At runtime, the following packages will add capability to ASCEND:
* ipython
* python-matplotlib

=== Kubuntu 10.04 ===

Building on Kubuntu (KDE) is identical to Ubuntu (GNOME) with the exception that python-gtk2 and python-glade2 must be installed before running the resulting program. This was tested with trunk r3039. At this point in time, building also requires the package libgsl0-dev, because of some dependencies in [[FPROPS]] which need to be removed/made optional.

=== Ubuntu 9.10 ===

Ongoing development of ASCEND is primarily done on this Ubuntu 9.10. Although ASCEND builds against the standard Ubuntu packages for Sundials, you will obtain better functionality with the [[IDA]] solver if you use a version built from latest 2.4.0 source code. The latest release fixes problems with boundary-crossing during integration.

To build ASCEND on a clean Ubuntu 9.10 box, the following packages are required (as of trunk r2667):

* scons
* swig
* python-dev
* scons
* g++
* gfortran

The following packages are optional:

* libsundials-serial-dev
* graphviz-dev
* flex
* bison
* libblas-dev
* tcl8.5-dev
* tk8.5-dev
* tktable2.9

At runtime, the following packages will add capability to ASCEND:

* ipython
* python-matplotlib

For the [[IPOPT]] solver, you will also need to build that separately from source -- see [[IPOPT]] for details.
For the [[CONOPT]] and [[CMSlv]] solvers, you must obtain libconsub3.so, see [[CONOPT]] for details.

=== Ubuntu 9.04 ===

ASCEND should build on this system without any problems, providing the prerequisited that you need are installed. Watch closely the 'scons' output for fleeting comments which may suggest that you're missing a library or a header file, etc. Prereqs should be the same as for Ubuntu 8.04.

Note that after updating to Ubuntu 9.04, you will probably need to rebuild and reinstall things like IPOPT and CONOPT, as gfortran errors seem to arise otherwise.

For the [[IDA]] solver, you may need to add the scons option SUNDIALS_CPPPATH=/usr/include/sundials to make this integrator build correctly.

=== Ubuntu 8.04 LTS ===

ASCEND built fine on Ubuntu 8.0.4 LTS when we last tried it. Numerous prerequisites must be installed, but all of these except IPOPT and CONOPT are currently available from the Ubuntu repositories. Specifically, check libsundials-serial-dev, swig, flex, bison, python-dev, tk-dev, libtktable2.9. Haven't yet tested with CONOPT, so conditional modelling has not yet been checked.

Special treatment for the gfortran compiler is no longer required (as was required for Ubuntu 7.10).

Building of a .deb package can be performed using the [[dtar]] tool included in the source distribution. Usage: scons dist && ~/ascend/tools/dtar/dtar ~/ascend/dist/ascend-0.9.5.116.tar.bz2 ~/ascend/dist/debian.tar.gz.

Ubuntu 8.04 uses GtkSourceView2 instead of the earlier version, with the result that source code highlighting in GEdit using a different <tt>.lang</tt> file. We have written a new version of this file, see the page on [[syntax highlighting]] for more info.

Currently, LyX 1.5 is not available on Ubuntu, and the manual .lyx files require this newer version. So for the moment, you must use <tt>scons WITH_DOC_BUILD=0</tt>.

ASCEND has been runninng on earlier Ubuntu versions, right back to version 5.10.

=== Fedora 11 ===

The following steps build ASCEND on a clean Fedora 11 machine (I tested using the Live CD installed to a qemu/kvm virtual machine):

<source lang="a4c">su
yum install scons subversion tk-devel flex bison gcc-gfortran gcc-c++ python-devel sundials-devel graphviz-devel swig
scons</source>

<s>Currently (as of 16 Jun 2009), the above results in a error message from g++ while compiling the SWIG output. See {{bug|403}}. Testing on Windows has shown that SWIG 1.3.39 and 1.3.40 have this problem, but 1.3.36 does not have this problem.</s> ''This bug is fixed in the pre-0.9.8 code from our SVN server.''

=== Fedora 9 ===

ASCEND builds without any problems on Fedora 9. You need to install several packages first, including swig, tk-devel, python-devel, scons, flex, bison, gcc-gfortran, gcc-c++. There may be some problems getting the GraphViz and CUnit-related functionality working, let us know if you have problems with that. -- JP, Jun 2008.

You can build an RPM version of ASCEND using <tt>scons dist</tt> followed by <tt>rpm -ta ascend-0.9.5.116.tar.bz2</tt>, providing you have RPM correctly set up. See also [[Building an RPM Package for ASCEND]].

=== OpenSUSE ===

OpenSUSE does not provide an up to date version of SCons (as of this writing, suse 10.2 comes with scons-0.96.91-37). You will need to download a newer version (0.96.93) ([http://sourceforge.net/project/showfiles.php?group_id=30337&package_id=22359 from SF.net].
Do not try 0.97 SCons, as it is not yet supported by the ASCEND SConscripts on the SUSE platform.

''Update (Mar 2010)'' it is suggested that you try latest SCons 1.x if possible, and report your experiences here.

=== Arch Linux ===

To build ASCEND on Arch Linux, follow these steps:

<source lang="a4c">sudo pacman -S gcc gcc-fortran flex bison python scons swig tcl tk graphviz blas</source>

Download and build sundials manually (see [[Prerequisites for Linux]]).

Then follow the [[Building_ASCEND#General_instructions|Genereal instructions]] (running scons and scons install).

If you have problem with SWIG 1.3.40 (scons reports that SWIG package was not found), download older version of [http://www.swig.org SWIG](1.3.38 worked for me, 1.3.24 didn't) and build it manually (./configure, make, make install). Then re-run swig with parameter <tt>SWIG=/usr/local/bin/swig</tt> (or different location where you installed SWIG).

When running ascend script:

<source lang="a4c">LDPATH = [INSTALL_LIB] + GTKLIBPATH + LDPATH
TypeError: can only concatenate list (not "NoneType") to list</source>
<source lang="a4c">LDPATH = [INSTALL_LIB] + GTKLIBPATH + LDPATH</source>
<source lang="a4c">if GTKLIBPATH:
LDPATH = [INSTALL_LIB] + GTKLIBPATH + LDPATH
else:

LDPATH = [INSTALL_LIB] + LDPATH</source>

(found [http://www.mail-archive.com/ascend-sim-users@lists.sourceforge.net/msg00089.html here]).

=== Gentoo ===

Some details for build ASCEND on Gentoo Linux are on a sub-page at [[Building ASCEND/Gentoo]].

== Instructions for Windows ==

The only currently-supported way to build ASCEND on Windows is using MinGW/MSYS and the GCC compiler. There has previously been partial success with the Microsoft compiler tools, but these are not currently actively being used or tested.

=== Windows 7 64-bit with 32-bit Python ===

We are currently in the process of testing the ASCEND build on 64-bit Windows 7, running via Virtual Box on a Dell Optiplex 980, with the host OS being Ubuntu 10.04.2 LTS.

* install 'mingw-get-inst', selecting to install C, C++ and Fortran compilers, plus the MSYS Basic System and the MinGW Developer Toolkit.
* install the [http://sourceforge.net/projects/win32svn/files/1.6.15/Setup-Subversion-1.6.15.msi/download win32svn package] from SF.net
* check out the source code from our [[VersionManagement|svn trunk]].
* download [http://www.python.org/download Python 2.7.1] 32-bit version and install with default settings. Python 3 is likely still to cause problems with our code, and we haven't tested it yet. We tried using the 64-bit version of Python 2.7.1, but SCons didn't seem to be able to detect it.
* download [http://sourceforge.net/projects/win32svn/files/1.6.15/Setup-Subversion-1.6.15.msi/download Glade3] and install it.
* download [http://sourceforge.net/projects/scons/files/scons/2.0.1/scons-2.0.1.win32.exe/download SCons 2.0.1] and install it by right-clicking and 'run as administrator' (note that failing to do this might have been the reason that we failed with the 64-bit version of Python, above -- if you get 64-bit Python to work, let us know).
* Add c:\Python27 and c:\Python27\Scripts to your PATH.
* download [http://sourceforge.net/projects/swig/files/swigwin/swigwin-1.3.40/swigwin-1.3.40.zip/download swigwin 1.3.40] and unzip it into your MSYS home directory, then add ~/swigwin-1.3.40 to your PATH.
* download Flex 2.5.4a and Bison 2.4.1from gnuwin32.sf.net, and install them. Add the c:\Program Files (x86)\GnuWin32\bin location to your PATH.
* run scons from within your ASCEND working directory.
* the build process completes successfully

To actually run the resulting binary, you need to also have PyGTK and GTK+ installed on your machine. The best way to do that is via the [http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.22/ new PyGTK All-in-One installer].

The resulting binary can then be run from the MSYS prompt using the following, providing GTK is available in the PATH:
cd ~/ascend
pygtk/ascdev

We have a mechanism for [[building a installer for ASCEND on Windows]] that makes use of NSIS. We are in the process of testing it on Windows 7.

As an aside, the above highlights that it would be desirable to move from the use of libglade to GtkBuilder (as noted {{bug|493}}). We would then be able to use standard PyGTK installers again, rather than needing the huge PyGTK-All-In-One with the optional libglade.dll that it includes.

=== Windows XP with MinGW/MSYS ===

''It is currently suggested that you attempt the same process as given above for Windows 7, instead of that given below.''

The following instructions were tested on 32 bit Windows XP running on a DELL Precision (Core 2 Duo) machine in Nov 2009 and 32 bit Windows VISTA running on a ThinkPad X61 (Core 2 Duo) machine in March 2010.

First install the MinGW/MSYS environment. Download MinGW-5.1.6.exe, and select the basic options plus 'g++' (the C++ compiler). Then download and install MSYS-1.0.11.exe.

Now install Python-2.6.4.msi.

Install pywin32-214.win32-py2.6.exe.

Next, download and install SCons, scons-1.2.0.win32.exe.

Download swigwin-1.3.36 (''later versions are OK'') and unzip it in your root directory (it's just a folder with that name).

Download and install Flex (2.5.4a-1) and Bison (2.4.1) from GnuWin32, installing in the default location.

Download GFortran 'native installer' for MinGW from [http://gcc.gnu.org/wiki/GFortranBinaries]. Our release was dated '2009-04-21'.

With a right-click on the My Computer icon, then in the Advanced tab, add the following to your PATH environment variable (no quotes): ';c:\Python26;c:\Python26\Scripts;c:\swigwin-1.3.36;c:\Program Files\GnuWin32\bin;C:\Program Files\gfortran\bin'. For Windows VISTA system, right-click on the Computer icon, choose Properties. In Advance System Settings, you can configure PATH environment variable.

Install NSIS 2.45.

Download '[[Media:Book.pdf|book.pdf]]' and save it as 'book.pdf' in ~/ascend/doc.

In MSYS, run <tt>scons WITH_DOC_BUILD=0 installer</tt>.

The above will allow you to build ASCEND (and also to build the ASCEND installer using {{src|nsis/installer.nsi}}) but not to run it. For that, you additionally need to complete the following steps:

* Download and install the GTK Glade3 windows installer [http://ftp.gnome.org/pub/GNOME/binaries/win32/glade3/3.6/glade3-3.6.7-with-GTK+.exe]
* Download and install PyGTK [http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.12/pygtk-2.12.1-3.win32-py2.6.exe]
* Download and install PyCairo [http://ftp.gnome.org/pub/GNOME/binaries/win32/pycairo/1.4/pycairo-1.4.12-2.win32-py2.6.exe]
* Download and install PyGObject [http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.2-2.win32-py2.6.exe]

The above Glade3 installer should have added 'c:\Program Files\Gtk+\bin' to your PATH; you can check that if necessary.

To test the installer, it is recommended you remove GTK Glade3, PyGTK, PyCairo, PyGObject, Tcl/Tk and Python. Then run the installer, and it should discover all those missing things and proceed to reinstall them for you.

[[Image:mingw-1.png]]
[[Image:mingw-6.png]]

'''SUNDIALS'''. If you want to use the [[IDA]] integrator (recommended) then you should download and install SUNDIALS. See [[building SUNDIALS on Windows]].

Everything should build and you should end up with a file dist/ascend-{version}.exe which is your 'setup' program. Run that then find ASCEND in your Start menu.

=== MSVC ===

We don't currently support the use of Microsoft compilers. They probably can be made to work, but we don't see any good reason to work on that.

=== Windows / Borland C Builder ===

Some very early efforts to support free Borland 5.5 were made; the core engine basically compiles but there is more work to be done.

== Instructions for Mac ==

=== Mac OS X 10.5 ===

ASCEND runs fine on Mac OS X 10.5, and probably other versions. Currently we haven't completed the job of bundling ASCEND into a convenient distributable form, but the work is now well underway. See [[Porting to Mac]] for details.

There has been no attempt to build or test the Tcl/Tk GUI on Mac at this stage.

== See also ==

* [[Building a Debian package]]
* [[Building an RPM Package for ASCEND]]
* [[Windows Miscellany]]

[[Category:Development]]
[[Category:Documentation]]