Talk:Student projects

From ASCEND
Jump to: navigation, search

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 GAlib, BonMin, perhaps 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 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!)

Reaction kinetics data support

Currently, reaction rate models in ASCEND are done on an ad hoc basis. Assorted tools, notably CHEMKIN, define and support a widely used text input format for describing chemical reaction rate equations. This project would include:

  1. creating or adapting an open-source parser of the CHEMKIN data format to generate a data representation suitable for machine transformations.
  2. defining a transformation instance that maps the equations into ASCEND equation code.
  3. defining a transformation instance that maps the equations into python, C or C++ code for performance comparisons.
  4. demonstrating the use of the tool on test problems related to renewable energy systems: H2-air or methane-water.
  5. 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 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 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