Talk:GSOC2010/Mentor Summit notes - Revision history

Jpye: /* Windows build */

2010-10-28T00:30:18Z

Windows build

← Older revision		Revision as of 00:30, 28 October 2010
Line 31:		Line 31:
	== Windows build ==		== Windows build ==

	* Build is already native with MinGW.		* Build is already native with MinGW (IIUIC)
	* Currently some minor issues with passing file handles from Python to C/Windows.		* 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.		* Installer attempts to detect and install dependencies rather than incorporating them into the installer.

Jpye: /* ASCEND API */

2010-10-28T00:29:22Z

ASCEND API

← Older revision		Revision as of 00:29, 28 October 2010
Line 20:		Line 20:
	* API-related memory allocation and use is something that needs to be understood/discussed in context of how SWIG and Python operate.		* 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!'''		* That stack-unwiding code is '''awesome!'''
			::[[User:Jpye\|Jpye]] 00:29, 28 October 2010 (UTC)

	== GUIs ==		== GUIs ==

Jpye: /* Text-only ASCEND */

2010-10-28T00:29:14Z

Text-only ASCEND

← Older revision		Revision as of 00:29, 28 October 2010
Line 12:		Line 12:

	::[[User:Jpye\|Jpye]] 00:03, 28 October 2010 (UTC)		::[[User:Jpye\|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!'''

	== GUIs ==		== GUIs ==

Jpye: /* Funding wish */ new section

2010-10-28T00:18:48Z

Funding wish: new section

← Older revision		Revision as of 00:18, 28 October 2010
Line 38:		Line 38:
	* Our SVN-to-Mantis link is currently offline, I believe. This link triggers Mantis notes when svn commits refer to bug numbers.		* Our SVN-to-Mantis link is currently offline, I believe. This link triggers Mantis notes when svn commits refer to bug numbers.
	::[[User:Jpye\|Jpye]] 00:13, 28 October 2010 (UTC)		::[[User:Jpye\|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]]).
			::[[User:Jpye\|Jpye]] 00:18, 28 October 2010 (UTC)

Jpye: /* Refactoring/testing/tooling */ new section

2010-10-28T00:13:34Z

Refactoring/testing/tooling: new section

← Older revision		Revision as of 00:13, 28 October 2010
Line 31:		Line 31:
	* We want to make it very easy for new users to start 'playing.		* We want to make it very easy for new users to start 'playing.
	::[[User:Jpye\|Jpye]] 00:10, 28 October 2010 (UTC)		::[[User:Jpye\|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.
			::[[User:Jpye\|Jpye]] 00:13, 28 October 2010 (UTC)

Jpye: /* Windows build */ new section

2010-10-28T00:10:58Z

Windows build: new section

← Older revision		Revision as of 00:10, 28 October 2010
Line 19:		Line 19:
	* GTK is the dominant Linux GUI toolkit (with Qt snapping at its heels) and has a safe future.		* GTK is the dominant Linux GUI toolkit (with Qt snapping at its heels) and has a safe future.
	::[[User:Jpye\|Jpye]] 00:06, 28 October 2010 (UTC)		::[[User:Jpye\|Jpye]] 00:06, 28 October 2010 (UTC)

			== Windows build ==

			* Build is already native with MinGW.
			* 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.
			::[[User:Jpye\|Jpye]] 00:10, 28 October 2010 (UTC)

Jpye: /* GUIs */ new section

2010-10-28T00:06:41Z

GUIs: new section

← Older revision		Revision as of 00:06, 28 October 2010
Line 12:		Line 12:

	::[[User:Jpye\|Jpye]] 00:03, 28 October 2010 (UTC)		::[[User:Jpye\|Jpye]] 00:03, 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.
			::[[User:Jpye\|Jpye]] 00:06, 28 October 2010 (UTC)

Jpye at 00:03, 28 October 2010

2010-10-28T00:03:32Z

← Older revision		Revision as of 00:03, 28 October 2010
Line 11:		Line 11:
	* 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.		* 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.

	:[[User:Jpye\|Jpye]] 00:03, 28 October 2010 (UTC)		::[[User:Jpye\|Jpye]] 00:03, 28 October 2010 (UTC)

Jpye at 00:03, 28 October 2010

2010-10-28T00:03:22Z

← Older revision		Revision as of 00:03, 28 October 2010
Line 10:		Line 10:
	* 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.		* 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.		* 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.

			:[[User:Jpye\|Jpye]] 00:03, 28 October 2010 (UTC)

Jpye: Text-only ASCEND

2010-10-28T00:02:48Z

Text-only ASCEND

New page

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