|
|
| Line 83: |
Line 83: |
| * Priority: High | | * Priority: High |
| * Languages: Flex/Bison, C | | * Languages: Flex/Bison, C |
|
| |
|
| |
|
| == Automated parameter-setting for dynamic models == | | == Automated parameter-setting for dynamic models == |
| Line 112: |
Line 111: |
| * Priority: Medium | | * Priority: Medium |
| * Languages: C | | * 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 [http://lancet.mit.edu/ga/ GAlib], [http://www.coin-or.org/projects/Bonmin.xml BonMin], perhaps [http://code.google.com/p/ceres-solver/ 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 == | | == Bug Squashing == |
| Line 140: |
Line 129: |
| * Level of difficulty: Low-medium | | * Level of difficulty: Low-medium |
| * Languages: C, Python, possibly some Tcl. | | * 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 [http://www.cuter.rl.ac.uk/ 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 | | * Priority: Medium |
|
| |
|
| == Packaging for Mac == | | == Packaging for Mac == |
|
| |
|
| ASCEND has now been [[Porting_to_Mac|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. | | 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. |
|
| |
|
| 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]] |
| | |
| * Contact person: [[John Pye]],[[Art Westerberg]] | |
| * Level of difficulty: low-medium | | * Level of difficulty: low-medium |
| * Priority: Medium | | * Priority: Medium |
| * Languages: C, Python, plus maybe some need for Apple-specific languages like Objective C. | | * Languages: Python, C, and a fair bit of general Mac OSX knowhow |
|
| |
|
| == New Compiler == | | == 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]]
| | 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]] | | * Contact person: [[Ben Allan]], [[John Pye]] |
| * Level of difficulty: very high | | * Level of difficulty: very high |
| * Languages: flexible, would need to interface with current instance hierarchy C code | | * Languages: flexible, would need to interface with current instance hierarchy C code |
| * Priority: Medium | | * 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!) == | | == Model Export Engine Experiments (MEEE!) == |
| Line 205: |
Line 164: |
| See also: Persistence, Openoffice below. | | See also: Persistence, Openoffice below. |
|
| |
|
| * Contact person: [[Ben Allan]] | | * Contact person: [[Ben Allan]], [[John Pye]] |
| * Level of difficulty: medium | | * Level of difficulty: medium |
| * Language: C / ANTLR / others | | * Language: C / ANTLR / others |
| * Priority: Medium/Low | | * 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!)
| |
| <!--
| |
| == Parallelising ASCEND computations ==
| |
|
| |
| ...arash currently working in similar area...
| |
|
| |
| 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 [[Solvers|Solver]] based on [[QRSlv]] that incorporated message passing using [http://en.wikipedia.org/wiki/OpenMP 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)
| |
| -->
| |
|
| |
| == [[Reaction kinetics data]] support ==
| |
|
| |
| Currently, reaction rate models in ASCEND are done on an ad hoc basis. Assorted tools, notably [http://en.wikipedia.org/wiki/CHEMKIN CHEMKIN], define and support a widely used [http://www.frad.t.u-tokyo.ac.jp/public/chemkin/CKm_man.html.en text input format] for describing chemical reaction rate equations. This project would include:
| |
| # creating or adapting an open-source parser of the CHEMKIN data format to generate a data representation suitable for machine transformations.
| |
| # defining a transformation instance that maps the equations into ASCEND equation code.
| |
| # defining a transformation instance that maps the equations into python, C or C++ code for performance comparisons.
| |
| # demonstrating the use of the tool on test problems related to renewable energy systems: H<sub>2</sub>-air or methane-water.
| |
| # [https://github.com/OpenCFD/OpenFOAM-1.7.x/tree/master/src/thermophysicalModels/reactionThermo/chemistryReaders/chemkinReader 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 [http://www.sqlite.org 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 [http://co-lan.org 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 == | | == Internationalisation == |
| Line 275: |
Line 184: |
|
| |
|
| * Contact person: write to the 'users' mailing list (see [[Support]]). | | * 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]].
| |
|
| |
|
| |
| == 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 {{src|models/thermodynamics.a4l}} 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.
| |
|
| |
| * Contact: [[Kannan Moudgalya]], [[Krishnan Chittur]]
| |
| * Languages: ASCEND, C
| |
| * Difficulty: Hard
| |
| * Priority: High
| |
|
| |
| == 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 [http://griffith.cc 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
| |
|
| |
| == 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.
| |
|
| |
| * Contact: [[John Pye]], [[Krishnan Chittur]]
| |
| * Languages: C and maybe a little Python
| |
| * Difficuly: Medium
| |
| * Priority: High
| |
|
| |
| == GUI update to GTK3 (completed) ==
| |
|
| |
| 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
| |
|
| |
| == [[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 [http://hsl.rl.ac.uk/cuter-www/ 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, <u>Solving Index and Near Index Problems in Dynamic Simulation</u>, 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, [[Calculation_of_sun_position|sun position]], [[Data_reader|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 ([[Special:BookSources/0471698679|ISBN 0471698679]]), Flynne ([[Special:BookSources/0852964196|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_modelling|dynamic systems]]. You can specify variables that are the derivatives of other variables, and then use a special [[External_Integrators|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 [http://flex.sourceforge.net/ Flex] and [http://www.gnu.org/software/bison/ 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 [[Canvas-based_modeller_for_ASCEND|already taken place]] within the ASCEND project to implement a GUI, using [http://gaphor.devjavu.com/wiki/Subprojects/Gaphas 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 [[MODEL|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 <tt>SET</tt> and <tt>SOLVER</tt> (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. [http://chapel.cray.com/ 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.
| |
|
| |
| * Contact person: [[John Pye]]
| |
| * Languages: C
| |
|
| |
| [[Leon Kwek]] completed large parts of this project as work towards a final-year engineering honours project [http://cecs.anu.edu.au 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.
| |
|
| |
| * Contact person: [[Kannan Moudgalya]] and [[John Pye]]
| |
| * Languages: Python, C, ASCEND.
| |
|
| |
| == [[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 {{srcbranchdir|fprops-ideal|}} 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 [http://en.wikipedia.org/wiki/Boolean_satisfiability_problem 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 [http://cecs.anu.edu.au/ 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 [[Renewable_energy_systems_modelling|here]] and [[Energy_system_modelling_with_ASCEND|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.
| |
|
| |
|
| [[Category:Development]] | | [[Category:Development]] |
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 GSOC2016 projects, or possibly undergrad or post-grad research projects, such as for engineering final-year students. Our contact details are here.
Last updated Feb 2016.
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.
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
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. We can discuss how best to approach this. Essentially, this GUI parses data embedded in NOTES for each MODEL type, and based on that metadata, allows the users to draw and connect units in a flowsheet. The difficulty currently is in providing the user with a nice way to enter and edit information associated with each unit in the flowsheet, and then to load/solve/save the resulting model and/or model scenarios.
- Contact person: John Pye
- Level of difficulty: Medium
- Priority: Medium/High
- Languages: Python
- Also useful: Cairo/PyGTK/PyGI, design patterns for GUI programming
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
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.
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. 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 projct.
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.
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
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.
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
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
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
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).