Jpye at 10:14, 25 February 2016

2016-02-25T10:14:19Z

← Older revision	Revision as of 10:14, 25 February 2016
Line 1:	Line 1:
		'''This page contains some 'stale' ideas for projects that might need to be reviewed before being presented again as options. Feel free to contact us if you see something interesting here.'''

		== New solver integration ==

		There are a number of interesting new solvers available which could be considered for inclusion ASCEND as new [[external libraries]]. We'd consider [http://lancet.mit.edu/ga/ GAlib], [http://www.coin-or.org/projects/Bonmin.xml BonMin], perhaps [http://code.google.com/p/ceres-solver/ CERES] and probably others if we can see strong potential for the solver's use for the types of problems we use ASCEND for. A key issue before deciding on a new solver is whether there are any particular ways that the solver in question does things that might be hard to interface with ASCEND. Every solver has a different approach! It's also worth comparing ASCEND's API with those of GAMS and AMPL, other well-known multi-solver frameworks.

		* Languages: C, possibly other depending on the solver in question
		* Contact person: [[John Pye]]
		* Level of difficulty: hard
		* Must know: some numerical methods, operations research
		* Priority: Medium/High

		== GAMS/AMPL interface ==

		The optimisation programs GAMS and AMPL provide well-defined ('server') interfaces with which their solvers interact (as 'clients'). It should be possible for ASCEND to reproduce the GAMS and/or AMPL server interfaces, and hence to allow ASCEND immediate access to re-using all of the solvers implemented for those programs. The same could possibly also be said of the [http://www.cuter.rl.ac.uk/ CUTEr] solver/problem suite.

		* Contact person: [[John Pye]]
		* Level of difficulty: Medium
		* Must know: numerical methods, operations research
		* Languages: C
		* Priority: Medium

		== CMSlv with IPOPT, improvements to solver API ==

		In GSOC2009, Mahesh completed the tie-in of the [[IPOPT]] solver into ASCEND. Next, we would like to modify our current CMSlv solver to be able to use IPOPT or CONOPT interchangeably, so that we have a completely open-source way of doing [[conditional modelling]]. An important part of this project would be reviewing of current solver APIs and making changes to allow solvers to work well in 'nested' ways, for example, for CMSlv to make calls to IPOPT. Down the track, we might also want other combinations, such as a dynamic optimiser, in which [[IPOPT]] makes calls to [[IDA]], for example.

		* Contact person: [[John Pye]]
		* Level of difficulty: medium
		* Languages: C.
		* Priority: Medium

		== Export/Import ASCEND models to OpenOffice spreadsheet ==

		We would like to be able to export models and data sets to spreadsheets, as the spreadsheet is the most common interface used by energy systems modelers today. Export will give advanced modelers using ASCEND more ways to communicate their results to others. Import from spreadsheets and data exchange will give spreadsheet modelers access to all ASCEND solvers without loss of their preferred user interface.

		* Contact person: [[John Pye]]
		* Level of difficulty: medium
		* Languages: most likely C, python, XML.
		* Priority: Low

		== [[Parameter estimation]] ==

		We would like to be able to process a dynamic ASCEND model with experimental data, and use the experimental data to give us estimates of the key operating parameters of the system. This would be useful for fitting models to experimental data in situations where simple steady-state measurements can not provide those parameters. It is anticipated that this would make use of similar code to the [[IPOPT]] solver, but would probably require a new Estimation API to be set up; defining a suitable API would be part of this project.

		One application of this type of modelling would be to use inside and outside temperature measurements for a house, taken over a few days, to predict its thermal characteristics (insulation effectiveness, thermal mass, etc), as a simple way of evaluating whether a house meets current standards of energy efficiency.

		* Contact person: John Pye
		* Level of difficulty: medium
		* Must know: numerical methods, modern control theory
		* Languages: C
		* Priority: Low (until someone has an itch that needs scratching!)
		<!--
		== Parallelising ASCEND computations ==

		...arash currently working in similar area...

		There is the potential for large speedups in ASCEND by implementing parallel evaluation of equation residuals. For systems with a large number of equations in a single block, this could give very large improvements. This project would involve writing a new [[Solvers\|Solver]] based on [[QRSlv]] that incorporated message passing using [http://en.wikipedia.org/wiki/OpenMP OpenMP] or similar.
		More detailed ideas on [[Parallelizing ASCEND]]. GSOC applicants interested in this area should consider working the [[OpenMP Exercise]] (our apologies to anyone who may have tried for 2010 the [[Differentiation Exercise]] that has expired.

		* Contact person: Ben Allan
		* Level of difficulty: medium-high
		* Priority: Medium/Low
		* Languages: C/C++ (with MPI, OpenMP, etc)
		-->

		== [[Reaction kinetics data]] support ==

		Currently, reaction rate models in ASCEND are done on an ad hoc basis. Assorted tools, notably [http://en.wikipedia.org/wiki/CHEMKIN CHEMKIN], define and support a widely used [http://www.frad.t.u-tokyo.ac.jp/public/chemkin/CKm_man.html.en text input format] for describing chemical reaction rate equations. This project would include:
		# creating or adapting an open-source parser of the CHEMKIN data format to generate a data representation suitable for machine transformations.
		# defining a transformation instance that maps the equations into ASCEND equation code.
		# defining a transformation instance that maps the equations into python, C or C++ code for performance comparisons.
		# demonstrating the use of the tool on test problems related to renewable energy systems: H<sub>2</sub>-air or methane-water.
		# [https://github.com/OpenCFD/OpenFOAM-1.7.x/tree/master/src/thermophysicalModels/reactionThermo/chemistryReaders/chemkinReader this code] may be of some help, possibly.

		* Contact person: Ben Allan, Krishnan Chittur
		* Level of difficulty: low-medium
		* Must know: physical chemistry, chemical engineering, numerical methods
		* Languages: C (but other compiled languages may be possible)
		* Priority: Low

		== Thermophysical properties database ==

		ASCEND includes a set of native ASCEND models that provide support for thermodynamic property correlations of a number of types. The current system is fully open and extensible, but its use of native ASCEND syntax makes it difficult to maintain, and difficult to browse the list of available chemical species. It also makes it difficult for users to work out how to add support for new substances. This project would involve migrating the chemical property data to a separate data file (perhaps via an [http://www.sqlite.org SQLite] and then implementing a suitable interface between ASCEND and that database so that chemical property formulations could be loaded from the database by a suitable statement in the ASCEND model file. A range of tests would need to be developed to prove that the property formulations worked as expected. It might be possible to investigate other freely-available sources of chemical property data, and import that data if suitable. In performing this work, it would be desirable to consider the edicts of the [http://co-lan.org CAPE-OPEN] project, which specifies a possible API for accessing chemical property data in a platform-agnostic way. Some partial efforts have been made to implement a suitable system, see [[FPROPS]], although currently this consists only of pure C code, with no mechanism for loading material properties from a database, and no support for mixtures of fluids.

		* Contact person: [[Krishnan Chittur]]
		* Level of difficulty: low-medium
		* Must know: chemical engineering, physical chemistry
		* Languages: C
		* See also [[FPROPS]]
		* Priority: Low

Jpye: Blanked the page

2016-02-25T09:35:01Z

Blanked the page

← Older revision		Revision as of 09:35, 25 February 2016
Line 1:		Line 1:
	~~== Nice post ==~~

	~~Truly great post u got here. It'd be really cool to read more concerning such theme. Thanx for posting such data.~~

178.93.193.142: /* Nice post */ new section

2010-05-17T21:34:36Z

Nice post: new section

← Older revision	Revision as of 21:34, 17 May 2010
Line 1:	Line 1:
		== Nice post ==

		Truly great post u got here. It'd be really cool to read more concerning such theme. Thanx for posting such data.

Jpye: Blanked the page

2010-05-17T00:06:36Z

Blanked the page

Show changes

Jpye at 00:05, 17 May 2010

2010-05-17T00:05:47Z

Show changes

87.106.216.64: putevki

2010-05-16T07:09:33Z

putevki

New page

Putevki, goryachie putevki, magazini putevok, turi, goryachie turi, otdih, tauland, turciya, grecija, oteli, more, plyazh, skuteri, nomera, diskoteki, bari, eda, turizm, vesel'e <a href=http://putevka.cz.cc/index.html>putveka</a>
EGE, ekzamini, matematika, himiya, russkiy, algebra, geometrija, testi, voprosi, otveti <a href=http://e-g-e.biz/index.html>EGE</a>

Talk:Student projects - Revision history

Jpye at 10:14, 25 February 2016

Jpye: Blanked the page

178.93.193.142: /* Nice post */ new section

Jpye: Blanked the page

Jpye at 00:05, 17 May 2010

87.106.216.64: putevki