Student projects

From ASCEND
Jump to: navigation, search

Welcome to ASCEND! You might want to read our overview to learn a bit about our project, or read about our more general Development Activities. This page gives a long list of possible student projects with our project, which means GSOC projects projects, or possibly undergrad or post-grad research projects. Our contact details are here.

Last updated Mar 2013.

Contents

New projects

We have assigned priorities to these projects. All things being equal, we will choose students who propose high-priority projects. However, all things are not equal; if we receive a very strong proposal from a student who has done lots of preparatory work, then we will probably choose that student over a lower-quality proposal for a higher-priority project.

New fluid types for FPROPS

This project requires someone with some background in engineering thermodynamics. We would like to add support in FPROPS for calculations of ideal and incompressible fluids, as well as fluids with specified density and specific heat capacity as a function only of temperature. FPROPS already supports two different equations of state, so most of the data structures are in place and simply need to be extended for these new types. However, it's possible that some problems arise when we consider that these fluid types have no phase transition, and all our work up to now has assumed the possibility of a phase change.

  • Contact: Krishnan Chittur, John Pye
  • Languages: C and maybe a small amount of Python
  • Difficult: Medium
  • Priority: Medium

Ideal mixture support for FPROPS

This project needs someone with fairly well-advanced knowledge of engineering thermodynamics, probably a third or fourth-year chemical or mechanical engineering student, or a chemistry student, and also a fairly good C programmer if possible (strong Java or C++ is probably a good enough start). We want to extend FPROPS to include support for calculations of the properties of mixtures of more than one chemical species. We will start of with ideal calculations, but we would like to try to define the architecture in a way that will be flexible for non-ideal mixtures down the track. You should review the relevant theory on this, discuss with the proposed mentors, and come up with an implementation plan before the application deadline.

Python bindings rewrite

The language bindings for 'libascend' (our core calculation engine) to Python are written using some C++-based wrapper code, and the SWIG interface generator. The current wrapper code uses a lot of C++ Standard Template Library code, with the result that the wrappers are a bit bloated. We would like to make ASCEND leaner and meaner by rewriting the Python bindings using either (1) SWIG with plain C wrapper code or (2) some othe approach such as Cython, if we can be convinced that it's a good move. Completion of this project would require the current GUI code to be rewritten to make use of the new wrappers, too.

  • Contact: John Pye
  • Languages: C, Python, C++, SWIG
  • Difficulty: Medium
  • Priority: Medium

GUI update to GTK3

We would like to update ASCEND to use the GTK3 graphics toolkit. Currently it is using GTK2, but eventually this toolkit will become deprecated, and eventually unsupported! Terrible! So we should find out what changes are needed in the ASCEND code to ensure we can support GTK3. Probably this will require some of our Python code to be rewritten. It is an opportunity to clean up the code and implement some better design patterns in our GUI code, a lot of which was written by a fairly inexperienced GUI programmer (speaking for myself there).

  • Contact: John Pye
  • Languages: Python
  • Difficulty: Low/Medium
  • Priority: Medium

Chemical engineering domain-specific models

Quite a few domain-specific models exist in ASCEND. If you are a later-year chemical engineering student, we would like you to help us extend our current set of models and test them with some samples of well-known process flowsheets. We want to validate our models for some such cases, then make them flexible and reusable as far as possible. A key part of this will be the dependency on our current models/thermodynamics.a4lalert! code, and possibly the need for new flash algorithms, whether externally codes (as external libraries) or not. There is the scope to compare/contrast with other open-source packages such as DWSIM, noting that ASCEND is fundamentally different due to its equation-based approach.

Windows installer

ASCEND on Windows is a bit difficult to support, because of our dependencies on Python, PyGTK, GTK, NumPy, PyCairo, PyGOBject, IPython, BLAS, LAPACK, and the various solvers that we bundle. Our current installer, trying to be small, only includes the 'core' ASCEND stuff, and then attempts to download any missing dependencies. It also expects the dependencies to be installed in 'shared' locations, with the intention that integration of ASCEND with other tools on the user's system should be possible. However, this makes maintaining ASCEND a bit difficult. Possibly we could write a new installer that bundles all the required dependencies into a single folder, as is down with the Griffith installer. The resulting package would be larger, but more robust and maintainable. Some options would need to be discussed before embarking on this project, but the goal in any case is (1) to make it easier for new users to get started with ASCEND (2) to make the Windows installer easier to maintain (3) to still provide support to Windows 'power users' if at all possible.

  • Contact: John Pye
  • Languages: Python (including DistUtils?), NSIS?
  • Difficulty: Medium
  • Priority: Medium

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
  • Languages: Python, C (and learn to read Tcl/Tk code)
  • Must know: usability principles
  • Level of difficulty: Medium/Low
  • Priority: High

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

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

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/High
  • Languages: C

Automated parameter-setting for dynamic models

With the addition of SOLVE, SOLVER and OPTION statements to the ASCEND language, we now have a way to specify all the necessary parameters for most of the ASCEND solvers like QRSlv, IPOPT and others. However, this implementation doesn't work with our ODE/DAE solvers like LSODE and IDA. This project would involve extending the ASCEND language in a way that dynamic models could be easily initialised and solved using statements in METHOD syntax. There is no tough mathematics involved in this project; mostly it's about data structures and information-passing, but efficient software design will be very important.

  • Contact person: John Pye
  • Very helpful: experience on a large software project (or software engineering studies)
  • Level of difficulty: Medium/high
  • Languages: C, Python

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

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

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

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: primarily C, and then possibly Python, C++, Flex/Bison, SWIG, Tcl/Tk, PyGTK,...
  • Priority: Medium/High

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

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

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 two kinds of objects both ambiguously known as ASCEND models:

  • an ascend TypeDescription: a list 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/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: H2-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 FPROPS
  • Priority: Low

Internationalisation

ASCEND has some bugs when used in locales that use the comma ',' as the decimal point separator. Furthermore, its user interface is in english only, with the exception of some standard menus that GTK+ provides translations for. This project would work towards internationalising ASCEND, starting with solving the decimal point problem, then translating the Python GUI, then moving on into the C library part of ASCEND. It would not be intended that the modelling language itself would be translated, though, nor would the decimal point separator in model files change from the default "." -- the same model files need to work for everyone.

  • Contact person: John Pye
  • Level of difficulty: low
  • Languages: Python, C
  • Priority: Low

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!

  • Contact person: write 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

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.

Leon Kwek completed large parts of this project as work towards a final-year engineering honours project at ANU. Further work is currently (Feb 2012) being done by Ksenija Bestuzheva.

Further improvements to the Canvas GUI

This project aims to take the current canvas-based modeller for ASCEND and add support for configurable streams such as chemical mixtures, so that we approach the ability to do full chemical flowsheet modelling with this prototype tool. Grivan Thapar worked on this project for GSOC2011. There is still more to be done.

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

Shrikanth Ranganadham (ChE Masters project) and C S Karthik (GSOC2011) from IIT-Bombay worked on this project. Partial support for RADAU5's support for integration of DAEs (of a specific kind) was added, but full testing of the resulting solver was not yet completed.

FPROPS

FPROPS is a module of code developed by John Pye to support thermodynamic property evaluations using Helmholtz correlation equations. These correlations are good, but there are many published correlations for thermodynamic data that comes in other forms, from Peng-Robinson to Benedict-Webb-Rubin and many others. This project would involve refactoring the FPROPS code so that there was support for multiple types of property correlations. We would start by adding support for ideal gases, and keep going from there. To complete this project, you will need to have a fairly solid background in thermodynamics to be able to deal with the mathematics that's involved, then you'll also need to get up to speed with C data structures.

  • Contact person: John Pye
  • Level of difficulty: medium/high
  • Must know: partial derivatives, thermodynamics
  • Languages: C
  • Priority: High

Richard Towers via GSOC2011. As of Feb 2011, a branch fprops-ideal:alert! contains code that is working towards generalising the FPROPS data structures to support a number of different correlation types. Richard has got some interesting code for dealing with parameter input/output via XML/XSL forms. The branch code needs to be completed and integrated into trunk, and additional correlation types and fluids added. The ability to import fluid property databases from other sources would be a good addition.

QRCUDA

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

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

Arash Sadrieh from Murdoch University, Western Australia, completed this project as part of his PhD but also current supported by GSOC2011. A paper was presented at ESCAPE conference, see our publications page. Further testing is needed by someone with a suitable GPU.

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

Franc Ivankovic completed an ANU summer scholarship working on this topic, but continues working on it as a final-year engineering project (Feb 2012).

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

Vikram Kadam (GSOC2011) did some limited work towards these goals, but unforunately was unable to complete the full GSOC programme. More work remains to be done.

GUI improvements & bug fixing

Aakash Goenka (GSOC2011) completed a project to add 'study' functionality to the PyGTK GUI, import the Observer functionality, added 'check for updates', improved handling of units of measurement, and fixed 6 other bugs. This was a great example of someone jumping in, learning our codebase quite broadly, and making a range of really useful small contributions that help to improve the overall use experience of ASCEND.

Personal tools
Namespaces

Variants
Actions
Navigation
tools
Tools