Talk:GSOC2010/Mentor Summit notes

Text-only ASCEND

Some comments:

• there is already a text-only ASCEND: one can instantiated models and solve them using Python scripting, with no GUI required.
• the Python API is a bit troublesome, due to the use of some less-than-ideal C++ code that John Pye wrote during his PhD. It is proposed to down-convert that C++-based API to a C-based one, but still using SWIG. To some extent this rewrite would be 'grunt work' but requires some intimate knowledge of the current C code as well as SWIG.
• Continuing to use SWIG leaves open the option of wrapping the API with other non-Python languages if a need for that arose, especially if we convert to a simpler C-based API code layer.
• John Pye sees any change to the current METHODS implementation of basic scripting as a major change that no-one's actually prepared to work on, so proposes to leave that idea on the backburner.
• by data table output I understand you to mean something like the current STUDY functionality. This is to some extent supported in the current Python layer, but we need some way to declare parameter ranges for simpler generation of parametric plots.
• For file export/output, I would like to see something like the PROBE functionality added to the PyGTK GUI, so that some/all of the variables and their associated values could be exported in the form of a CSV file or similar. Note that the current Observer functionality allows tabular data to be copied/pasted into Excel/OpenOffice.
• Plot generation could be worked on but I see it as lower priority than the STUDY feature. We need to make it easier to generate the data as a first step.

Jpye 00:03, 28 October 2010 (UTC)

ASCEND API

• Although the original developers are familiar with many function names in the original, there is a great deal of inconsistence of styles across different modules in the API. John is in favour of refactoring to rename functions to attempt to converge on a more uniform coding style. This will pay back especially when in comes to the SWIG wrapping.
• A major impediment during the current C++-based SWIG wrapping was the extensive use of global variables. We need to get rid of these as part of any new API work.
• CPP macros are very expressive but we need to be careful with them as extensive macro use reduces the usefulness of many code-analysis tools.
• API-related memory allocation and use is something that needs to be understood/discussed in context of how SWIG and Python operate.
• That stack-unwiding code is awesome!

Jpye 00:29, 28 October 2010 (UTC)

GUIs

• Cleaning up the SWIG wrapping of the C API is an important step.
• I don't think we should embark on any new GUI writing. It is bad enough that John was allergic to Tcl/Tk.
• GTK is the dominant Linux GUI toolkit (with Qt snapping at its heels) and has a safe future.

Jpye 00:06, 28 October 2010 (UTC)

Windows build

• Build is already native with MinGW (IIUIC)
• Currently some minor issues with passing file handles from Python to C/Windows.
• Installer attempts to detect and install dependencies rather than incorporating them into the installer.
• Incorporating deps in the installer would increase its size to 50+ MB.
• Problems experienced by people attempting to install, especially Indians working behind university firewalls/proxies. We need to support that user base better.
• Issues with 64-bit support on Windows, John has not yet tested this.
• Python scripting and the ability to interoperate with other Python software that the user may wish to install is very desirable.
• We want to make it very easy for new users to start 'playing.

Jpye 00:10, 28 October 2010 (UTC)

Refactoring/testing/tooling

• We should try to re-establish our BuildBot system. This was a very effective way to quickly test build/run on a variety of systems.
• Our test suite has been growing but needs to regular bug-fixing
• Our SVN-to-Mantis link is currently offline, I believe. This link triggers Mantis notes when svn commits refer to bug numbers.

Jpye 00:13, 28 October 2010 (UTC)

Funding wish

• We have some chance of connecting with spanish solar thermal reseach funding for FOSS modelling software. For this application we would want to demonstrate the ability to do full system simulation of solar thermal plants around-the-year. This means dynamic modelling with boundary detection/integration of conditional models together with the data reader, as well as well-tested extensions to the model library. It would also ideally mean completion of the canvas-based modeller for ASCEND.
• John would also like to see ASCEND able to be used for a wider range of tasks such as parameter estimation, sensitivity studies, control system tuning, etc.
• Extending our capability for working on chemical reaction systems, building up a library of chemical flow-sheet models (eg see COCO simulator and EMSO in other modelling tools).

Jpye 00:18, 28 October 2010 (UTC)