From ASCEND

Jump to: navigation, search

Here are some possible projects for students wanting to participate in the ASCEND project. These could be suitable for final-year theses in Engineering studies, research projects, etc. For contact details, see the Support page.

New projects

Automatic recursive initialisation

Extend ASCEND's METHODS code so that certain methods are run recursively one instantiated MODELs. This would allow simpler code for setting initial values of solver variables, and make constructing robust models easier, especially in the context of canvas-based modelling tools. Making this stuff work is probably an prerequisite for an efficient canvas-based modeller for ASCEND, because it allows 'blocks' to be initialised without the user having to explicitly request it.

Contact person: John Pye

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

ABsolver integration

ABsolver is an interesting new kind of solver that uses a SAT solver to drive the solution to a conditional modelling problem. We would like to work together with the authors of ABsolver to connect that solver to our modelling environment, and then test it on a range of engineering problems. It's not sure yet if some tricks will be required to make the SAT problem formulation compatible with ASCEND's modelling language, so there's a bit of architecture/design required as part of this problem.

Contact person: John Pye, Andreas Bauer (one of the ABsolver developers)
Level of difficulty: not sure yet
Languages: C, C++

BonMin integration

For conditional modelling problems, ASCEND currently offers CMSlv solver, developed by Vicente Rico-Ramirez. To diversify our offerings for solving these kinds of problems, we would like to also add support for BonMin, the MINLP solver offered by the COIN-OR project. The BonMin API seems to have some notable differences from the API provided by ASCEND, so we anticipate that providing the suitable adapter routines will be a significant part of the project

Contact person: John Pye
Level of difficulty: medium
Languages: C.

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.

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.

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
Languages: C
An undergraduate student at ANU is currently working on this project.

Canvas-based modelling, continued

Our recent GSOC project on this topic made excellent progress, and it is now possible to construct and solve simple models uby 'wiring up' blocks and setting the parameters therein. However, more work is needed before this tool becomes generally usable. This includes adding support for customised block appearance (so that the canvas looks more like a process flow diagram), and consideration of some nitty-gritty issues relating to debugging of models with closed circulation loops, which naturally involve redundant equations. We'd really like someone from an engineering background to take this one on, if possible, because we also need to develop a library of suitable canvas components, such as turbines, pumps, etc.

Contact person: John Pye
Level of difficulty: medium
Languages: Python, C/C++.

Parallelising ASCEND computations

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 Solver based on QRSlv that incorporated message passing using OpenMP or similar. More detailed ideas on Parallelizing ASCEND. GSOC applicants interested in this area should consider working the Differentiation Exercise.

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

Improvements to the Conditional Modelling syntax

ASCEND provides support for Conditional modelling in the form of language constructs and a solver called CMSlv. Unfortunately the syntax available for conditional modelling is unintuitive. It could be improved by a student willing to delve into the dark corners of the ASCEND compiler and willing to learn about the Flex and Bison parser/compiler tools. Further work on this project could include a rigorous test-suite to demonstrate that all aspects of the conditional model parser and corresponding solver are working OK. Additional further might include enhancements to the graphical interface to make it more obvious to the user when parts of the model are switched on and off as a result of changes in IF or WHEN statements, or alternatively completion of the conditional modelling support for the dynamic modelling solver IDA. This is another item that would benefit from a New Compiler effort.

Contact person: Art Westerberg
Level of difficulty: medium
Languages: Flex/Bison, C

Embedded solver settings

Difficult-to-solve models often require a bit of tweaking of the solver parameters, tolerances, etc, before a model will solve as intended. Currently, this must be done either manually via the GUI(s), or else through a script that exists separately from the model. We would like a way to embed solver parameter settings directly within the model. One approach that partly does the job (although not very nicely) is solver NOTES. We have also discussed the idea of a couple of new 'solver request' keywords, such as SET and SOLVER. This project would involve leading a design discussion to work out the best possible solution to this problem, and then implementing the agreed solution, as well as thorough testing.

Contact person: John Pye
Level of difficulty: medium
Languages: C, Python, Tcl/Tk (if both GUIs are to be supported)

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:

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₂-air or methane-water.

Contact person: Ben Allan, Krishnan Chittur
Level of difficulty: low-medium
Languages: probably any compiled language would be OK, we encourage Python or C.

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
Languages: C

Porting to Mac (ACTIVE)

We have made some initial investigations about the possibility of running ASCEND on Mac. The core ASCEND 'engine' runs with pure C so there shouldn't be any problem with that side of it. But the main current ASCEND GUI runs with PyGTK, and we're not sure how acceptable that would be to Mac users. This project would involve modifying ASCEND so that the current GUI would work on Mac *in addition to* the platforms it currently supports. This project seems as thought it may be a bit small so perhaps it could be enlarged to include some other GUI enhancements, such as printing support.

Contact person: John Pye, Art Westerberg
Level of difficulty: low-medium
Languages: C, Python, optionally Tcl/Tk if also looking at the old GUI

New Compiler

The ASCEND compiler is currently highly efficient, but it has a large and complicated body of code based around the Flex/Bison toolset. Using more modern compiler-generators such as ANTLR we believe it will be possible to rewrite the ASCEND compiler to be more modular, more maintainable and hopefully faster. This task would be very challenging and require fairly extensive experience with compiler-compilers and small-language implementation. More detailed ideas on a New Compiler

Contact person: Ben Allan
Level of difficulty: high
Languages: flexible, would need to interface with current instance hierarchy C code

FPROPS

FPROPS is a module of code developed by John Pye to support thermodynamic property evaluations using Helmholtz correlation equations. This has the potential to be a very powerful and flexible solution to the problem of high-accuracy thermodynamic property evaluation, but it is still missing some crucial code relating to the location of the saturation line. A student with a strong understanding of thermodynamics would be able to complete this project. The real difficulty is in the thermo, the coding would be pretty straight-forward.

Contact person: John Pye
Level of difficulty: low (programming), high (thermodynamics)
Languages: C, ASCEND.

Your Own Ideas

There are many other areas of possible work on ASCEND, including those from our long list of current and future Development Activities. Feel free to discuss other possible ideas with us, see Support for contact details.

Contact person: send email to the 'users' mailing list (see Support)

Completed GSOC projects

These are the summaries of the projects that were undertaken during our participation in GSOC 2009.

Real-time ASCEND (more work is possible)

The core engine of ASCEND is a low-level C code compiler and set of solvers. It is conceivable that ASCEND could be incorporated into a real-time control and/or parameter estimate engine, using live data feeds for its modelling calculations. This is an open-ended project, with the hope that basic use of ASCEND for this application could be demonstrated. With such a capability it would be possible to contemplate using ASCEND to control systems that change over time, by allowing the values of system parameters to be adjusted in response to changing system behaviour.

Contact person: John Pye
Level of difficulty: medium
Lanaguages: C

Non-proprietary Optimisation (completed)

ASCEND is a free/open source software package licensed under the GPL. We have a number of Solvers in our software, including a wrapper for the excellent optimisation solver CONOPT. Unfortunately, however, this solver is expensive commercial software and can not be distributed freely as part of ASCEND. The lack of a good (free) optimisation solver limits the utility of ASCEND for many users.

This project would involve linking the IPOPT solver (or possibly some other suitable alternative, if any exists) to ASCEND, allowing us to run complex optimisation problems in ASCEND. Some work would be required to give ASCEND the ability to evaluate Hessian matrices (second derivatives of object functions), then tying it all together so that ASCEND can pass values and parameters etc through to the IPOPT solver.

Further work on this project could include development of a benchmarking suite using various standard sets of optimisation problems such as CUTEr.

Note that there is a fairly new repository of open-source optimisation code now available from Sandia.

Contact person: Ben Allan
Level of difficulty: medium-high.
Language(s): C

Adding Exact Numerical Differentiation for Second Partial Derivatives (completed)

(combined with 'Non-proprietary Optimisation')

When solving nonlinear equations, the ASCEND solver creates exact numerical derivatives to create needed jacobian matrices. This task would be to extend these capabilities to generate exact numerical second derivatives, which could then support optimization solvers. The approach one can use is in Chapter 6 (596 kB pdf) of Yonsoo Chung, Solving Index and Near Index Problems in Dynamic Simulation, PhD Thesis, Dept. of Chemical Engineering, Carnegie Mellon University (1991).

Please consider submitting a response to the Differentiation Exercise if applying for this topic under GSOC.

Contact person: John Pye and Art Westerberg
Level of difficulty: medium
Languages: C

Renewable energy system modelling (more work is possible)

ASCEND has all the built-in capabilities needed to solve systems of equations, and historically has been used to solve some difficult modelling problems in chemical and process engineering. We would like to improve its usefulness in the field of renewable energy systems modelling, through the development of some reusable modelling 'blocks' for common system components. These would include flat-plate solar hot water collectors, sun position, weather data, photovoltaic panels, pumps, turbines, storage tanks, and so on. The goal would be to allow typical engineers to quickly produce accurate models of renewable energy systems for various locations, hopefully including prediction of their economic performance.

Much information on modelling these types of systems is available in books like Duffie and Beckman (ISBN 0471698679), Flynne (ISBN 0852964196) and elsewhere. This project would involve pulling together a coherent set of models for this task, and testing them carefully and making sure they are reusable and well-documented so that they can be of maximum use to the community.

Contact person: John Pye
Level of difficulty: low-medium
Languages: ASCEND, possibly some C for 'hard to converge' models if necessary.

Improved ODE/DAE support (completed)

ASCEND currently has a system for allowing users to model dynamic systems. You can specify variables that are the derivatives of other variables, and then use a special Integrator to solve for time-varying behaviour of your model. We support a number of Integrators, including IDA, LSODE and DOPRI5.

Unfortunately, however, the ASCEND syntax for dynamic models is very clumsy, and this makes it hard to write compact, readable models for such systems.

This project would involve implementing proposed LINK semantics for ASCEND (in itself a value enhancement to the ASCEND language), then, upon that, building a new ODE/DAE syntax so that dynamic models could be succinctly expressed with the ASCEND modelling language. This would require you to become familiar with the Flex and Bison tools, which are used to implement the ASCEND language parser, so that you could then extend out language grammar with the necessary additional language constructs.

Further work on this project could include enhancing the reporting from External Integrators including perhaps a live graphical plot of progress or improvements to the Data reader to allow arbitrary input data to be fed into a simulation.

Contact person: Ben Allan
Level of difficulty: high
Languages: C, Flex/Bison

Canvas-based modeller for ASCEND (completed)

Power stations are large and systems of many interacting components, including turbines, boilers, pumps and controllers. Their complexity arises as optimisations are applied, to extract the maximum possible energy from the available resource. The preferred way of modelling these systems is through the use of (very expensive) canvas-based GUI software in which 'blocks' are shown connected by lines, and parameters can be adjusted by editing the data behind the various blocks in the model. Some work has already taken place within the ASCEND project to implement a GUI, using Gaphas, allowing these kinds of energy systems to be modelling using a GUI, but further work is required. It is anticipated that great progress could be made on this if someone were able to dedicate a few months to the job, and the result would be an open energy modelling system that would be much more user-friendly for those people who don't like writing text-based models.

Contact person: John Pye
Level of difficulty: low-medium
Languages: Python (GTK, Cairo)

Student projects