Development activities

From ASCEND
(Redirected from Development Activities)
Jump to: navigation, search

This page outlines the range of tasks being tackled by the ASCEND team. Current tasks are near the top of the page, with older and dormant tasks further down the page.

Current focus of development effort

Recent tasks

See also our Student Projects list.

GSOC2013

We participated in GSOC2013 as a sub-organisation of Python Software Foundation. See our student list for the two projects we completed.

GSOC2012

We participated in GSOC2012. See our student list for project details.

GSOC2011

We participated in GSOC2011. See our student list for project details.

GSOC2010

Our participation in GSOC2010 is completed, so thanks to Google and to all our participants. Ben Allan and Krishnan Chittur met up at the GSOC2010 Mentor Summit and discussed plans. You can read their discussion notes.

GSOC 2009

We recently completed five exciting Google Summer of Code projects. Here is a list of our GSOC students in 2009, and their assigned tasks. We're gradually merging these projects into our trunk.

Dante Stroe:

  • LINK semantics This is adding a LINK command to ASCEND, which will give us the ability to express links between elements in a model. The initial purpose for this would be as a way of defining derivative-of relationships, but it might be found to need further extension upon that.
  • Initial-value modelling Current methods of dynamic modelling in ASCEND are rather cumbersome. We have currently code a Tcl-based DAE] solver implementation (there is a PDF HOWTO chapter describing this; it uses an elegant DAE solver implementation by Art), as well as an 'Integrator' module that connects at the C-code level to the LSODE, IDA and DOPRI5 integrators. However the syntax for writing these models is not straightforward, so perhaps with the help of the propose LINK semantics we want to implement a new way of running dynamic models and showing the results etc.

Mahesh Narayanamurthi:

Non-proprietary Optimisation Add an optimization capability that does not require the use of proprietary software. We have identified the free open source solver IPOPT as a candidate package.
  • fix current segfaults in asc_ipopt.c
  • fix IPOPT to work with numerically-approximated second derivatives
  • implement routines in libasccend for calculation of exact second derivatives
  • add support for these auto-diff calculation of Hessian matrices in IPOPT, using the above 2nd derivatives.

Jose Zapata:

Energy system modelling with ASCEND
  • Completing implementation of the <a href="/Data_reader" title="Data reader">Data reader</a> to load weather data for solar energy simulations
  • Component models for thermal power systems, including turbines, pumps, condensers, boilers, solar collectors
  • Implementing an updated sun-position algorithm.

Dipak Chirmade:

  • Interfacing real-time data acquisition hardware with ASCEND
  • Implementing a solver that is able to update calculated parameters in real-time in response to changing input data (maybe steady-state, but hopefully dynamic, including integration)

Arijit Chakraborty:

Experimental features

Please try out the experimental features that are under development. Let us know what you find.

Longer-term and backburner projects

The following are bigger areas where we would like to be making progress, but for whatever reason, currently are not.

Core architecture and design

  • Some refactoring of libascend to ensure cleaner separation of concerns, and more helpful doxygen code docs. (John Pye, Ben Allan)
  • Some discussions about possible next-generation ASCEND syntax (Ben Allan)
  • Controlling the solvers from within METHODS. There may still be some bugs in this new code. (John Pye)
  • Removing global variables (Ben Allan)
  • Grey-box Models John Pye and Ben Allan have been talking about this. A way to write equations without all of the variables being added to the system Jacobian.
  • SyntaxImprovement Of course this one is here. It is a fun part to thinking about ASCEND, but it takes a lot of very careful thought.
  • ComponentizingAscend Convert ASCEND into components. For example make a component out of the compiler that can create input from the ASCEND input language into data files that solvers could use as input. Another would be to make a component out of the solver. Jon Shao is working on aspects of this task
  • Conditional modelling This is a continuation of Vicente Rico-Ramirez' doctoral work that would allow ASCEND to dynamically change the model as the solving/optimizing proceeds.
  • External libraries Ben Allan and John Pye are working on rejuvenating ASCEND's support for external functions, so that things like weather data and perhaps water/steam properties can accessed from a simulation.
  • DOPRI5 Integrator. John Pye is adding support for this ODE solver.
  • Parallelize solvers 8-core machines are now routine for engineering compute work. Take an ascend solver (or several) and parallelize (openmp or directives) the evaluation of jacobians and rhs calculations. This step should provide a big bang in performance terms. In conjunction with ascend's C-compiled equation code, it could produce something like a 100x speedup in rhs evaluation for large equation systems.
  • Establishing the Coding style for ASCEND is something we want to do before the current GSOC starts.

Porting, building, testing

  • TestSuite Set up a test suite that all developers can use when making modifications to ASCEND.
  • Model Self-testing Add the capability for ASCEND models to report when they have been broken, by instrumenting them with a self_test method for use with automated tools.
  • PythonGUIOnWindows You can run the new PyGTK GUI under Windows. We're working on expanding this GUI and making it easier to install
  • BuildBot Nightly testing for regression, coverage, results from the model library,...
  • CoverageTesting Analyse the ASCEND codebase and ensure that as much of the code as possible has been run and performed as expected.
  • DebuggingAscend Yes, just plain debugging and bug reporting database.
  • Tcl-config, a script for robust detection of Tcl/Tk on different platforms: Ubuntu, Fedora, Mandriva, Windows and hopefully Mac.

Interfacing with other systems

  • Radiation View Factors - we can import view factor data from the View3D program.
  • Can we implement a CAPE-OPEN interface for thermodynamic properties and/or flowsheet components?
  • AgentBasedOptimization Very long term - have ASCEND create agents for John Siirola's agent-based system.
  • OpenGL visualisation - we have some models that use OpenGL to visualise networks of 3D points
  • We have thought about interfacing with Cairo as an animation engine for dynamic models...
  • Steam properties: support for IAPWS-IF97 in ASCEND. This is all working, but we continue to ponder possible improvements that might make use of conditional modelling features in ASCEND. (John Pye)

Developing the user interface

  • Continuing work on the canvas-based modeller for ASCEND (User:Arijit)
  • Graphical block debugging. John Pye proposes to provide output of relationships between variables and relations within a block in the PyGTK GUI using GraphViz to represent the directed acyclic incidence graph. Possibly it will be made cyclic by reversing the direction of arrows from relations to on-diagonal variables. This would be part of the current Diagnose tool
  • DesktopIntegration. John Pye has contributed some files that help to integrate ASCEND into the GNOME/KDE desktop, including syntax highlight definitions for the 'gedit' editor in GNOME. See [1].
  • PlottingInAscend. Getting the plot packages to plot on both linux and windows.
  • PythonWrapper. John Pye has been working on SWIG wrappers for ASCEND which will allow ASCEND to be called from range of other scripting languages including Python, Ruby, C# and Java. There is also a new GUI underway implemented with PyGTK.
  • Useful resources. A list of reference materials likely to be of use when building ASCEND models.
  • Python console support. Adding a way for the user to run scripting commands on their models via the PyGTK GUI.
  • Syntax highlighting for various tools.
  • Spreadsheet interface (not started) This should be a fun project. The idea is to develop a spreadsheet style of interactive user interface for ASCEND. Programming is by knowing where things are rather than by knowing what one has named them - as when programming a spreadsheet model.

Specific applications

  • Referenced examples. A number of the models in our ModelLibrary are implementations of models discussed in published papers and theses. This page will contain a list of such models.
  • ASCEND Model Library. As well as being useful as part of the core TestSuite, the ASCEND Model Library serves to demonstrate the use of ASCEND for several important chemical engineering problems, and hopefully others too, as we expand on them.

General Information

  • Documenting ASCEND Conversion of the legacy in-source documentation to doxygen format, and appropriate upgrades & extensions thereto.
  • CHM version of ASCEND manual needs to be created
  • ASCEND capabilities A list of the (hopefully growing) core features of the ASCEND modelling system
  • Helpful tools Here are a few helpful tools to use when working with ASCEND.
  • Other modelling tools Notes about related modelling tools that we've come across, how ASCEND is different, features that we've seen elsewhere that we'd like to emulate, things that we do better and worse. Emphasis on FOSS alternatives.
  • Modelling techniques A brief catalog of some of the mathematical techniques and algorithms commonly used in the field of modelling and simulation of non-linear systems.
  • WebPages This one is essentially finished. Art Westerberg converted many of the pages to have a common formatting, updated the list of developers, and moved everything from the CS computer environment to the PSE computer, our new home for this project.
  • How do I fix my model Wiki page to aid users to debug a model - perhaps in form of FAQ page.