ASCEND capabilities
From ASCEND
Contents |
ASCEND Overview
The purpose for this overview is to provide guidance that will allow you to determine if the ASCEND modeling system can be useful for your modeling needs. After you have read this page, you may wish to visit the page ASCEND capabilities.
Please note that ASCEND is now in its fourth generation, and we often refer to it as 'ASCEND IV'.
Check out the screenshots for our two interface options: PygtkScreenshots and TcltkScreenshots.
ASCEND is really good at
- Creating models as one might do now in a spreadsheet but where (1) the model involves solving a few to tens of thousands of simultaneous equations and/or (2) where one wishes to discover the value for several inputs so the spreadsheet model computes specified values for several of its outputs.
- Creating and debugging complex highly structured models (built out of parts which themselves are built out of parts, etc.) expressed in terms of algebraic equations.
- Setting up and solving initial value dynamic models involving a few tens of ODEs and thousands of algebraic equations - if it is your time to create the model that matters and not the final computation, our approach to solving initial value differential algebraic equation (DAE) models is good enough.
- Setting up and solving dynamic optimisation problems involving a few ODEs and hundreds of algebraic equations - the problem becomes a two point boundary value problem that ASCEND is good at expressing and solving. To solve optimisation problems, you will have to license the CONOPT optimizer we have coupled to ASCEND.
- Using superior model-debugging capabilities to create with understanding new 'building block' sub-models that might then be ported for use in other modeling systems. We have found it can be faster to get the new model right in ASCEND and then rewrite it for the other system.
- Correctly handling models involving mixed units of measurement (ft, m, kg, ounces, Pascals, etc.). ASCEND knows all about dimensionality and units. It reports when equations are written with incorrect dimensionality, or variables are entered with incorrect units.
- Solving many undergraduate homework problems - the tools allow students to play. (One of our developers uses ASCEND extensively in his chemical engineering classroom. To quote him: "For cubic equations of state, ASCEND is easier to use." - Krishnan. Our message here is only that you might find ASCEND to be quite good for students to use on small, solve from scratch, homework problems.
- Doing the one-off modeling for a thesis project - we have had students cut times from months to weeks.
- Solve conditional models in which certain equations are used or not used depending on the values of boolean variables in the system - we are well along on reinstating this functionality. It requires CONOPT (license required).
- Literate programming: you can include code comments as well as NOTES that allow you to make a highly readable model file that is easily understood by other modellers.
ASCEND also okay at BUT
- Creating a one-off model that solves without iteration in a spreadsheet - a spreadsheet would be better (unless those unit conversions worry you).
- Simulating a conventional engineering system for which a commercial simulator exists. Hey, this is their specialty. They know how to "hammer home" a solution and have all sorts of nice input and display options you would not want to create in ASCEND. (However, from a pedagogical viewpoint, we might again quote Krishnan "If I could, I'd BAN commercial simulators from undergraduate hands - AT LEAST watch them like a hawk when they use them - have them use ASCEND." The implication: often the understanding of what is in the model is as important as the answers for students.)
- Solving large DAE problems where solve time matters - others have better solvers than we do for that problem. However, our work with IDA is remedying this problem. (see Dynamic modelling).
ASCEND cannot
- Carry out symbolic manipulations (although it does support 'direct solve' of equations when there is only one unknown)
- Compute eigenvalues and eigenvectors (although we have developed a means of doing this using SciPy as an external module).
- Solve integer (IP, MILP, MINLP) optimization problems (we need the solvers).
- Solve higher-order DAEs and ODEs directly (although we do provide the means to detect an index problem; you need to reduce the order manually).
- Perform index reduction on systems of DAEs. Having said that, with tools available, ASCEND can guide one in how to change degrees of freedom to eliminate an index problem.
Broken functionality
- Export models to other formats (e.g., GAMS).
Examples of specific uses of ASCEND
- Performing heat and material balances using rigorous physical property calculations for a miniature hydrogen plant.
- Optimizing a system of distillation columns to separate azeotropic mixtures.
- Solving homework problems for undergraduate chemical engineering courses ("Far easier in ASCEND to solve Bubble Point T calculations when liquid is non-ideal!" - Krishnan).
- Generating and analyzing alternative architectural structures.
- Analysing batch distillation processes.
You might benefit from reading more about ASCEND capabilities.
ASCEND capabilities
This is intended to be a succinct list of the core capabilities of ASCEND. It's supposed to address what types of numerical problems can be solved and what algorithms it uses, rather that all the glories of the GUI(s) and API(s) etc. More of what and less of how. No mention of any purely GUI features here eg plotting, sparsity maps etc.
The items I can confidently state include:
- Solves real-valued systems of non-linear equations (i.e. steady state)
- Allows models to be built up as combinations of interconnected smaller sub-models (Object-oriented modelling)
- Polymorphism allows models to be specialised instances of more general models
- Parameterised models allows for flexible interconnection of components, and more reusable model code
- Tracks, outputs and converts units of measurement
- Efficiently manage arrays of subcomponents (submodels, or just equations or variables) declared with 'for loop' style syntax.
- Decomposes hierarchical models into 'flat' systems of relations and variables
- Decomposes systems of relations and variables into 'blocks' of self-contained subsystems
- Compiles 'flat' systems into machine-code for fast evaluation during solving (optional)
- Normalises variables according to user preference
- Implements an efficient equation reordering algorithm that improves convergence, similar to 'tearing'
- Dynamic modelling with the LSODE ODE integrator (using a rather laborious syntax at present) for defined timestep sequences
- 'Creep up on solutions': solver keeps its results, allows modifications to system then re-analyse and re-solve.
- Model initialisation performed by arbitrary 'METHOD' statements; so models can be given with multiple 'starting states'.
- Efficiently recognises repeating sub-sections of large models, and uses this to aid in the pre-ordering analysis('anonymous class') and solution.
- Solves 'conditional models' in which certain equations are used or not used depending on the values of boolean variables in the system.
- Allows equations written in other languages/tools to be linked with ASCEND solver using 'external library' code.
Partial support:
- Dynamic modelling (Integration) with IDA solver for DAEs (still under development)
- Boundary detection in dynamic modelling (still under development)
- Detection of index problems in DAE problems.
Some things which I think ASCEND can do, but which I can't say for sure are:
- Performs some basic symbolic manipulation to allow direct solution of certain simple equations.
- Uses dog-leg Newton solver techniques to converge
- Solve deterministic (one variable per block) boolean/logical systems LRSlv
Broken functionality:
- Export models to other formats (eg GAMS)
It just can't:
- Solve higher-order DAEs and ODEs (you need to reduce the order manually)
- Perform index reduction on systems of DAEs
- Automatically 'tear' systems of equations (although the preordering has a similar effect?)
Some strictly architectural features include:
- 'Model library' architecture for common model components
- Scripting with Tcl/Tk and with Python (two different APIs though)
- Values can be modified interactively
- Constants (fixed values) and variables (free values) can be interchanged interactively at any stage (not just in the original model declaration file).
- A structured self-documentation format ('NOTES') a la doxygen.

