Student projects

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

The following exercises are no longer part of the application process but may be interesting reading OpenMP Exercise, ANTLR exercise. Submitting patches to fix bugs in the tracker or working on a new feature ahead of GSOC11 are the best ways to support an application.

Please contact John Pye instead of Ben Allan for any item below listing Ben Allan as contact. Ben is not mentoring for 2011, though he may be helpful by email after GSOC starts.

See also Development Activities.

GSOC applicants, please also read our suggestions for GSOC2011.

Active projects

Integration of conditional models

Dynamic models with switching behaviour are a common need in much engineering work. Examples from mechanical engineering include non-return valves, on/off valves, laminar/turbulent transitions, user demand for hot water, sunlight dropping while clouds pass, etc. The IDA solver provides support for detection of boundaries during the solution of the DAE system. These boundaries can be used to stop the solver, and to implement switching conditions, for example to switch from laminar flow to turbulent flow once the speed gets to a certain threshold. This problem requires digging deeply into the conditional modelling data structures in ASCEND and re-wiring them for use with dynamic simulations.

• Contact person: John Pye
• Languages: C

Current activity: Leon Kwek is working on this project as a final-year engineering honours project at ANU.

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++
• Priority: Low/Medium

Current activity: Franc Ivankovic is working on this an a final-year engineering honours project at ANU.

QRCUDA

This project involves writing a parallelised version of QRSlv that works with CUDA GPGPUs.

• Contact person: John Pye
• Level of difficulty: high

Current activity: User:Arash from Murdoch University, Western Australia, is working on this project.

RADAU5

ASCEND currently has a good supply of multi-step solvers for ODE/DAE systems, namely LSODE and IDA, but for single-step solvers, only DOPRI5 (explicit solver for non-stiff problems) is present. This project involves the addition of the RADAU5, an implicit solvers for stiff problems. RADAU5 is a mature solver, and connecting it is not expected to be overly difficult, but it will be a useful addition for a certain class of dynamic problems, and also useful for benchmarking.

• Contact person: John Pye, Kannan Moudgalya
• Level of difficulty: medium

Current activity: Shrikanth Ranganadham from IIT-Bombay is working on this project as part of a Masters degree in the Chemical Engineering Department.

New projects

Dynamic modelling improvements

This project would build on the progress with dynamic modelling by Dante in GSOC2009. This year, we'd like to thoroughly incorporate the new LINK syntax into the integrator API, and and make further changes to the ASCEND language to make dynamic modelling more 'natural', hopefully getting as far as simple der(x) = x + y expressions being possible. The changes to the integrator API would need to be incorporated into all the current ODE/DAE solvers, too, as part of this work. Some reusable elements would be identified, and may be incorporated into libascend.

• Contact person: John Pye
• Level of difficulty: High
• Priority: High
• Must know: numerical methods
• Languages: C, plus ideally some experience of lex/yacc

Debugging tools for DAE modelling

We would like to implement tools that make it easier to determine degrees-of-freedom problems for initial value problems, and possibly implement index reduction into ASCEND. One possible algorithm is that by Soares and Secchi (see doi:10.1016/S1570-7946(07)80063-0 or else here). This project will have some overlap with the current work by Leon Kwek but can also probably run parallel if only considering initial conditions and not boundaries as well.

• Contact person John Pye
• Level of difficulty: High
• Priority: Medium
• Must know: numerical methods, differential equations, graph theory
• Languages: C

Renewable energy system modelling

A student with strong engineering thermodynamics skills is needed to work on expanding support for energy systems modelling in ASCEND (see here and here). We would like as a minimum to be able to perform annual simulations of domestic solar hot water systems of a variety of types. If time permits, we would like to move on to dynamic simulations of large-scale solar thermal power stations, including trough, dish, and tower systems. Initially, models based on correlations and equations from published journal papers are the goal. Good textbooks containing the necessary background theory would be Çengel Thermodynamics (Rankine cycles, etc) and Duffie & Beckman Solar Engineering of Thermal Processes (solar collectors, solar radiation, etc).

• Contact person: John Pye
• Level of difficulty: Medium
• Priority: Medium
• Must know: Thermodynamics, Heat transfer
• Languages: C, ASCEND

GUI improvements

Our PyGTK-based GUI for ASCEND now implements are fairly usable subset of the functionality originally provided by the Tcl/Tk GUI. But there are some rusty bits and some buggy bits, and some functionality that still remains to be implemented. This project would require a student with a bit of a flair and/or interest in human interface design (eg see the GNOME HIG), as well as hopefully a little bit of experience using other comparable software packages, to go in and look at the old Tcl/Tk GUI, look at the new PyGTK GUI and then go ahead and add or fix up the missing pieces, while also fixing some of the various bugs in the currently-implemented stuff.

• Contact person: John Pye
• Level of difficulty: Medium/Low
• Priority: High
• Must know: usability principles
• Languages: Python, C (and learn to read Tcl/Tk code)

Parameter handling for the canvas-based modeller

ASCEND's Canvas-based modeller is the result of some work by John Pye together with two GSOC projects (Arijit Chakraborty and Grivan Thapar). It's alpha quality at the moment, but shows proof-of-concept of wiring up and solving models using reusable 'blocks' placed on a 'canvas'. The current implementation has some design flaws in the handling of parameters which need to be resolved before the project can proceed. The aim of this project would be to implement an improved solution for parameter handling. Early discussions with the ASCEND will be needed to decide the right course of action. This project suits someone with GUI programming experience; strong mathematics and/or engineering background would be advantageous but possibly not essential.

• Contact person: John Pye
• Level of difficulty: medium
• Must know: Python
• Also useful: PyGTK, mathematics, numerical methods
• Priority: Medium
• Languages: C

Automated connector routing for the canvas-based modeller

When working on big simulation models, line routing can be annoying and tedious, but with a sufficiently clever constraint-based solver, algorithms can be used to automate the task, leaving only minor tweaking required to complete a diagram. Our collaborator on the canvas-based modeller, Arjan Molenaar, has been working to integrate Michael Wybrow's adaptagrams library into Gaphas, to add support for automatic line routing. At this stage he has got partial Python bindings for the needed parts of adaptagrams, but not plan yet exists for how that will be incorporated into Gaphas or thence to our canvas-based modeller. This project would require someone with good Python skills to work in Gaphas as well as ASCEND to development this functionality.

• Contact person: John Pye and Arjan Molenaar would hopefully help out as an informal mentor
• Level of difficulty: medium
• Priority: medium
• Languages: C

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: John Pye, Art Westerberg
• Level of difficulty: medium
• Priority: High
• Languages: Flex/Bison, 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: hard
• Must know: numerical methods, operations research
• Languages: C.
• Priority: Medium/High

Bug Squashing

We've got a big long list of bugs and feature requests (as well as a shortlist) that a student could certainly work on with success. Many of the bugs can be fairly easily fixed and just need a little time. Someone with the right C/C++/Python programming background plus understanding on numerical methods and hopefully some understanding of compiler design and/or GUI design could really make a difference for us.

• Contact person: John Pye
• Level of difficulty: variable, depends on the bugs you choose to fix
• Must know: numerical methods
• Languages: C, and then possibly Python, C++, Flex/Bison, SWIG, Tcl/Tk, PyGTK,...
• Priority: Medium/High

Model Export Engine Experiments (meee!)

A number of the other projects on this page are concerned with converting a model into some format appropriate for use with another tool. There are actually 2 kinds of objects both ambiguously known as ASCEND models:

• an ascend TypeDescription: a lit of statements that must be interpreted somehow to derive a data tree (Instance) in memory.
• an Instance data tree (which, in principle, may contain references to unexecuted statements from the TypeDescription or may be 'completed').

Potential approaches

• Conversion of C TypeDescriptions to equivalent classes in some other language is the most general form of model reuse, but requires careful implementation of the conversion operation. A general solution would be to create, or expose in a convenient form, visitor functionality over a self-consistent list of related TypeDescriptions for type-translation plugins to convert to other languages. In the compiler science world, the ascend TD is most related to an AST.

• Conversion of ascend model source via an independent parser to another language. This approach 'reinvents' the ASCEND AST and grammar, but may then be much more translator friendly-- e.g. Java or other tools could be used for implementation with no direct reference to the existing C code base.

• Define a visitor API for conversion of instance data structures to classes in other languages. These classes may or may not look anything like the original object-oriented models. Note that conversions of this sort to flat-file data storage formats (for reloading in ascend later) and to object-free (flat) modeling languages are in the ascend code base already.

See also: Persistence, Openoffice below.

• Contact person: Ben Allan
• Level of difficulty: medium
• Language: C / ANTLR / others
• Priority: Medium

Persistence of modelling results

Currently, ASCEND models are loaded and solved afresh each time. But sometimes, it can take a bit of fiddling to achieve solution of a model. In these cases, it would be useful to be able to save the model state and load it again into ASCEND. A coherent proposal for how to do this needs to be prepared, in discussion with the ASCEND team, by a student who would like to work in this area. Because this task involved loading and saving model state, it is proposed that it could also incorporate more general data export functionality, eg to export whole/partial model results to a CSV or tab-delimited file, for use with other tools. How this system would work with 'observers' and 'integrator' output is an open question. See also Saving and restoring model state. Especially important that the design of this component would work nicely with the new canvas-based modeller for ASCEND.

• Contact person: John Pye
• Level of difficulty: Low-medium
• Languages: C, Python, possibly some Tcl.
• Priority: Medium

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:

• 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.
• 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 <a href="#FPROPS" title="">#FPROPS</a>
• Priority: Medium

Packaging for Mac

ASCEND has now been ported to Mac OS X. What remains to be done, however, is to create an application bundle that runs in the way users expect. This project will require the user to create a suitable set of 'frameworks' and 'packages' that allow ASCEND to run in a Mac-ish way, but without too much disruption to the overall codebase. One key challenge is to provide suitable Apple Event bindings so that models can be opened using the ASCEND GUI.

This project seems as thought it may be a bit small so we'd be looking for a candidate who's already demonstrated their willingness to tackle a range of other tasks relating to the overall improvement of the program.

• Contact person: John Pye, Art Westerberg
• Level of difficulty: low-medium
• Priority: Medium
• Languages: C, Python, plus maybe some need for Apple-specific languages like Objective C.

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: very 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), medium (thermodynamics), medium (numerical methods)
• Languages: C, ASCEND.
• Priority: Medium

Current activity: Ankit Mittal from IIT Bombay is working on some aspects of this task, but more work is also required in other areas.

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 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 https://software.sandia.gov/trac/acro/wiki/Overview.

• 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 <a href="/images/c/c3/PhDthesisChungExactNumDiffChapt6.pdf" class="internal" title="PhDthesisChungExactNumDiffChapt6.pdf"> in Chapter 6 (596 kB pdf)</a> 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 (more work is possible)

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)

Automatic recursive initialisation (completed by the ASCEND developers)

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
• Level of difficulty: Medium
• Languages: C
• Priority: Medium

Embedded solver settings (completed by the ASCEND developers)

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 (see Controlling the solvers from within METHODS). 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)
• Priority: Medium/High

Prototype compiler

Building a whole new compiler implementation and hooking it to the existing C system is very difficult (very high quality code and testing required), and is generally unsuitable for a 3 month project. A solid contribution possible in 3 months, however, is to create the basis for a new parser infrastructure and ascend4 language migration tool. The particulars are open to negotiation, but may include development of parsers and walkers from scratch in ANTLR or the extension of an existing language (e.g. Chapel?) to support equation based programming. See also chapel.cray.com and elsewhere in this site for Ben's scribblings on new compiler design.

• Contact person: Ben Allan
• Level of difficulty: Low-Medium
• Priority: Medium
• Must know: ANTLR or other compiler development tools
• Languages: ASCEND, probably java, optionally C, Fortran