Student projects

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 potential GSOC2018 projects, or possibly undergrad or post-grad research projects, such as for engineering final-year students. Our contact details are here.

Last updated Jan 2018.

Recommended 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.

Graphical flowsheet editor

Similar to the flowsheet editor in chemical process modelling software such as ASPEN, ASCEND has a Canvas-based modeller which is currently in development, and not yet quite usable. We would like to push this nice new interface closer to usability. The next step in the implementation, be believe, is to implement proper 'connector' logic, including annotation which which variables should be connected in a 'potential' sense (eg. voltage, temperature), and which which should be connected in a 'flow' sense (eg. current, energy). Connectors should be able to connect a number of related variables at once. Also it would be good to present documents/tutorials to users for solving practical problems. Before going ahead with this project, we would like to discuss implementation details with interested students.

• Contact person: John Pye, Tengda (Mike) Han
• Level of difficulty: Medium
• Priority: Medium/High
• Languages: Python, possibly a small amount of C/C++
• Also useful: Cairo/PyGTK/PyGI, design patterns for GUI programming

Parallel optimisation solvers for ASCEND

We would like to develop optimisation solvers for ASCEND using particle swarm optimisation (PSO) or a hybrid of PSO with gradient-based Newton solver methods. Such methods are amenable to parallelisation, and should be considerably faster for certain kinds of models with modern hardware. Connecting to an existing open-source solver would be preferred, but only if it makes good sense architecturally. Before starting, we would like to discuss possible implementation approaches. It's important to note that current ASCEND is not thread-safe, so care may be required depending on the approach that is taken.

• Contact: John Pye, Ben Allan
• Languages: C
• Difficulty: Medium-High
• Priority: High

FPROPS

Our FPROPS fluid properties library within ASCEND is used to calculate the properties of pure fluids (enthalpy, pressure, temperature, density, viscosity, conductivity, etc) with high accuracy. We would like to extend its capabilites in various ways: (1) add support for mixtures, (2) add support for more equations of state, especially cubic equations of state such as Redlich-Kwong and others, (3) add support for incompressible liquids, (4) add support for humid air calculations, (4) demonstrate its use in flash, heat exchanger and reactor models in ASCEND, (5) finalise the integration of Tabulated Taylor Series Expansion feature into FPROPS (acheving a 100× speedup compared to current helmholtz routines). This project requires someone with background in engineering thermodynamics (for example, having studied the Sandler book or similar), because the theory from that book is a necessary starting point for the project. Only one or two of these sub-topics need to be implemented for a successful GSOC project.

• Contact: Mahesh Venkataraman, John Pye, Krishnan Chittur
• Languages: C and maybe a small amount of Python
• Must know: engineering thermodynamics (eg. the Sandler book)
• Difficult: Medium
• Priority: High

Gibbs equilibrium reactor model

We would like to implement a robust tool for calculating reaction equilibrium using Gibbs free energy minimisation. This needs to be done in a way that is compatible with the ASCEND approach to declaring MODELs etc., and should make use of FPROPS for the calculation of the properties of each component. We have some sample code in MATLAB; a first step might be to convert that code to C and connect it to FPROPS. We will need to simultaneously discuss how to interface to the code to ASCEND so that it can be used in the context of flexible modelling of chemical process flowsheets.

• Contact person: Mahesh Venkataraman, John Pye
• Level of difficulty: Medium
• Must know: engineering thermodynamics (eg the Sandler book)
• Priority: Medium/High
• Languages: C

Dynamic modelling improvements

This project would build on the progress with dynamic modelling by Ksenija in GSOC2012-2013. We would like to improve our new EVENT syntax and extend its support to a range of problem types not yet supported, such as periodic events, and make further changes to the ASCEND language to make dynamic modelling more 'natural'. We would like to work on the efficiency of the ODE/DAE engines, to ensure that integrator restarts after boundaries are as efficient as possible.

• Contact person: John Pye
• Level of difficulty: High
• Priority: High
• Must know: numerical methods
• Languages: C, plus possibly some use 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 Soares_Secchi_Dycops-2007 or (somewhat different) doi:10.1016/S1570-7946(07)80063-0).

• Contact person John Pye
• Level of difficulty: High
• Priority: Medium
• Must know: numerical methods, differential equations, graph theory
• 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

Test Coverage

We have been working hard to increase the coverage of our ASCEND CUnit test suite. Currently we've got coverage at around 50% of libascend. But we would like to improve that. This project would require learning the functionality of different self-contained code modules, including correct versus incorrect behaviour cases, then implementing those tests via new C code, using the existing CUnit test infrastructure. As an optional element, we would be pleased to see new mock testing implemented to help with testing some of the deeper-buried functionality. Some small expansions to the features of libascend may also be helpful to facilitate this work, eg on-the-fly declaration of equations/variables with a reduced parser.

• Contact person: John Pye
• Level of difficulty: medium
• Priority: High
• Languages: C

Other projects

The following list contains a range of projects that we consider either harder to tackle, or lower priority, or which require very particular skills.

CAPE-OPEN thermodynamics

CAPE-OPEN is a well-documented API for evaluating thermodynamic properties of mixtures, running flash calculations, etc, which exists in the chemical process simulation community. In this project, we'd like to develop a first proof-of-concept integration of CAPE-OPEN into ASCEND. It is suggested that we might use the CAPE-OPEN thermodynamics library provided by the DWSIM project, although other possibilities exist. Importantly, we need this approach to work on Linux as well as Windows, and this may complicate matters. However, on the whole, it should be possible to achieve this integration in a relatively straightforward way using our support for external functions (eg see writing ASCEND external relations in C). Having CAPE-OPEN support will greatly increase ASCEND's access to a range of high-quality thermodynamic property engines, which would be very helpful in improving the usefulness of our code.

• Contact person: John Pye, Mahesh Venkataraman, Krishnan Chittur
• Level of difficulty: Medium (/ Low?)
• Must know: chemical engineering thermodynamics (eg the Sandler book)
• Priority: Medium/High
• Languages: C, possibly others for 'gluing' to the CAPE-OPEN DLLs/COM objects

Python bindings rewrite

We would like to review and improve the way that ASCEND accesses its low-level C functionality from Python. Currently this is done via C++ using the SWIG interface generator. Our preference is probably to keep using SWIG, but to eliminate the C++ layer. Alternatively, a different type of interfacing tool like Cython could be used instead. The new wrapping/langugage bindings would need to be tested via a set of test suites, and program examples in Python provided. It would not be necessary to translate the GUI code to use this new wrapper, although that would certainly be desirable.

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

MSYS2

We would like to implement a new build process for ASCEND for Windows, based on the use of MSYS2. MSYS2 is a command-line environment similar to Linux. It offers the usual GCC compilers etc, plus a package manager with pre-compiled versions of many of our dependency libraries and tools. This project would require (1) modifying current SCons build files so that they work correctly with MSYS2 (compared to older MSYS), (2) ensuring that all required dependencies are also available in MSYS2 and (3) producing a new installer for ASCEND, by updating our current NSIS-based scripts, that makes use of the MSYS2 binaries built in 1 and 2.

• Contact person: John Pye
• Languages: Python, C, NSIS
• Must know: usability principles
• Level of difficulty: Low/Medium
• Priority: High

GTK3/Python3

We have already done quite a bit of work (eg User:Adrian) on adapting ASCEND to work with GTK3 (PyGI, PyGTK3). Next we need to update ASCEND so that it works correctly with Python3. This will require some work using SWIG to update our Python wrapper to work with Python3. It will also require some changes to the Python GUI (code in pygtk. Finally, it is very important to check that the build and install processes work correctly with Python3 on both Windows and Linux as a minimum.

• Contact: John Pye
• Languages: Python, SWIG, possibly some C/C++.
• Difficulty: Low/Medium
• Priority: High

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. A careful review of the OPTION syntax is also required, as it appears that in some cases the current approach fails to pass through parameters if the solver has already been connected to the system. 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

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

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

Packaging for Mac

We want to get ASCEND working for Mac! We previously did a lot of the work (see Porting to Mac), but since then Python3 and GTK3 have become commonplace, and we also need to develop an ASCEND bundle/installer/disk-image that feels nice and Mac-ish, but doesn't cause 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.

• Contact person: John Pye, Art Westerberg
• Level of difficulty: low-medium
• Priority: Medium
• Languages: Python, C, and a fair bit of general Mac OSX knowhow

New Compiler

If you've got a strong background or interest in designing parsers/lexers/compilers, we'd be interested to discuss possible ways to write a new compiler for the ASCEND language. The original ASCEND compiler uses Flex/Bison, but perhaps we can make something more efficient and easier to maintain using more modern tools, perhaps such as ANTLR. See also New Compiler

• Contact person: Ben Allan, John Pye
• Level of difficulty: very high
• Languages: flexible, would need to interface with current instance hierarchy C code
• Priority: Medium

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, John Pye
• Level of difficulty: medium
• Language: C / ANTLR / others
• Priority: Medium/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

Structural Mechanics Solver in Graphical flowsheet editor

As mentioned above, ASCEND has a Canvas-based modeller which is currently in development. We would like to explore and develop more functionality for this canvas-based modeller. One possible direction is to build a structural mechanics solver to solve mechanics problems. Ideally users can draw the structure in the modeller, with various loading condition and constrains. The solver should solve the structure according to equilibrium equations and return the required answers. We can start with some simple structure from mechanics textbooks, and extend to complicated situation like buckling and advanced beam theory, etc. Of course, it would be good to present documents/tutorials to users for solving example problems. Ideally, for this project you should have some elementary (undergraduate) mechanics knowledge.

• Contact person: Tengda (Mike) Han, John Pye
• Level of difficulty: Medium/Low
• Priority: Low
• Languages: Python
• Also useful: Cairo/PyGTK/PyGI, design patterns for GUI programming

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