Student projects

From ASCEND
Revision as of 05:20, 9 November 2010 by Jpye (talk | contribs)
Jump to navigation Jump to search

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. Please note: many of the ideas on this page were placed here for GSOC 2008, 2009; in particular, the differentiation exercise became part of a 2009 GSOC project and is no longer part of the application process. OpenMP Exercise, ANTLR exercise and perhaps others are available; for those less oriented to exercises, submitting patches to fix bugs in the tracker are also very good to support an application.

See also Development Activities. GSOC applicants, please also read our suggestions for GSOC2010.

Active projects

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 Ivancovic will be working on this project as part of his Summer Scholarship at ANU.

Dynamic modelling improvements

This project would build on the progress with dynamic modelling by Dante in GSOC2009. This year, we'd like to correctly link the IDA solver to the new LINK syntax, and complete the implementation of boundary detection for IDA, so that we can do integration of conditional models. Finally, we'd like to add an implementation of a new structural analysis (debugging) algorithm to ASCEND specifically for dealing with DAE models. This project has a fairly significant mathematical component; we'll be looking for a student who's seen a bit of graph theory as well as numerical methods in their courses to date, and one who's already up to speed with C programming. As always, students who've already connected with the project and started looking at the problem will be selected in preference to those who come along at the last minute.

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

Current activity: Kelvin Hang Sio will be working on this project as part of his Summer Scholarship at ANU. Shrikanth R from IIT Bombay is also working on aspects of this task.


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 this task as part of his Masters research project.

New projects

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: High
  • 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)

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. Another area of work is specification of flow streams. When dealing with fully generic models of things like turbines, etc, we need to be able to specify the fluids in the system in some way that is independent of the blocks being sketched out. Suitable architecture for that needs to be discussed and designed.

  • Contact person: John Pye
  • Level of difficulty: medium
  • Must know: computer graphics, human-computer interface design, graph theory
  • Priority: High
  • Languages: Python, C/C++.

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

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.

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 <a href="https://projects.coin-or.org/Bonmin" class="external text" title="https://projects.coin-or.org/Bonmin" rel="nofollow">BonMin</a>, 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 we 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 to ASCEND. (see also <a href="#Packaging_for_Mac" title="">#Packaging for Mac</a>)

  • 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 / ? 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 acheive 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.

  • 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!)

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 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)

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 (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

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


  • 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

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 <a href="https://software.sandia.gov/trac/acro/wiki/Overview" class="external text" title="https://software.sandia.gov/trac/acro/wiki/Overview" rel="nofollow">Sandia</a>.

  • 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
Retrieved from "https://ascend4.org/index.php?title=Student_projects&oldid=1467"