View source for Developer's Manual

<div>''This article is incomplete or needs expanding. Please help out by adding your comments.''</div>
This document contains some partial high-level documentation of the ASCEND system for use by developers. It attempts to describe all the major functionality and how it all fits together, because that is the one thing that it is hard to comprehend just from reading the source code.

In addition to these notes, there is a lot of descriptive material embedded in the source code, accessible via doxygen at [http://ascend.cheme.cmu.edu/dox/]

Some very good, although outdated, information is also available in the document [[Media:Ascendimpl.pdf|Implementation of an ASCEND interpreter]] by Tom Epperly. See also more information in the [http://ascend.cheme.cmu.edu/ascend_bibliography.htm ASCEND bibliography].

See also the [[Media:Book.pdf|user's '''manual''' (1 MB .pdf)]] for user-level information including description of the modelling language and syntax.

= Getting started =

ASCEND is primarily a program for solving systems of equations. These could be systems of non-linear equations, or systems of differential equations, or mixtures of both. Equations and variables are specified using a bespoke modelling language, then ASCEND compiles them into a form that it can solve. It exposes that form to a number of different solvers that the user can run depending on the type of problem they are solving: solution, optimisation, dynamic simulation, etc. Most of the 'core' of ASCEND is written in C code, but there are bits of Python (for the PyGTK GUI and Python language bindings), as well as Tcl/Tk (for the Tcl/Tk GUI and language bindings), as well as C++ (part of the Python language bindings).

See [[Building ASCEND]] for information on building from source code (either our subversion repository or a source code tarball)

See [[Debugging ASCEND]] for some information on ways of tracking down errors in the ASCEND code, including how to run a 'local copy' of ASCEND using the 'ascdev' script.

One you have built the code, you can test bits of the 'core' code using our CUnit test suite: <tt>scons test &amp;&amp; test/test</tt>.


There are also many model files that include self-test methods. Open those files with ASCEND, run the 'on_load' method, then solve, then run 'self_test'.


= libascend =

<tt>libascend</tt> is the 'core' ASCEND engine. It is written entirely in C, although some of this code is auto-generated using Flex and Bison. It contains all of the routines that load a model file and any dependent files that it calls, allows [[METHOD|METHODs]] to be run on the model tree, and creates a 'flat' version of the model that can be passed to solvers. Several kinds of [[external libraries]] can be plugged in to libascend; this is how solver functionality is provided, for example.

So, libascend includes two main parts, the 'compiler' and the 'solver'. These are organised in directories in the <tt>ascend/</tt> subdirectory of the source distribution. There are also 'utilities', 'general' and 'packages' subdirectories.


The <tt>utilities</tt> directory is intended to contain utility routines that only really of use to ASCEND but which are linked specifically neither to the compiler nor the solver. The <tt>general</tt> directory contains general purpose routines which would be of use in any similar software project, with no specific dependencies on the other ASCEND code.

The <tt>packages</tt> directory contains a few so called 'internal packages'. These provide functionality that is outside the compiler and solver, but which is important for basic standard-case use of ASCEND. As example is the code which performs the 'ClearAll' function to reset the values the 'fixed' flag.

Finally, there is the ASCEND GUI. There is currently a Tcl/Tk GUI as well as a PyGTK GUI. These can be used independently; there is not interdependency.

<div class="thumb tnone"><div class="thumbinner" style="width:452px;">[[Image:Ascend-arch.png]] <div class="thumbcaption"><div class="magnify">[[File:Ascend-arch.png|<img src="/skins/common/images/magnify-clip.png" width="15" height="11" alt="" />]]</div>Diagram showing the architecture of ASCEND with some 'cuts' into modules (some cuts of which are yet to be completed)</div></div></div>

== Compiler ==

The compiler includes a '''parser''' which constructs a '''types hierarchy''' which is stored in a '''library'''. When a model (or '''instance''') of a specific type is '''instantiated''', it creates an <tt>Instance</tt> tree, the top node of which is a 'simulation' instance, and underneath which is a '''simulation root''' corresponding in structure to the type that was instantiated.



=== The Library, and TypeDescriptions ===

As files are loaded into ASCEND, they are added as 'modules' to the in-memory 'library' structure. It is possible to have multiple models active and instantiated from a single in-memory library, although the current PyGTK interface does not yet support this. 

Each of the MODELs and ATOM descriptions in the modules resides within the library in the form of a TypeDescription object, which in turn is composed of Statements objects.


=== Parser, and how to add to the language ===

ASCEND uses Flex and Bison to implement a scanner/parser for the ASCEND modelling language (see also documentation on [[Category:Syntax|Syntax]]). The files that define the language are {{src|ascend/compiler/ascParse.y}} and {{src|ascend/compiler/scanner.l}}.


On machines that don't have Flex and/or Bison, the source code contains some reasonably up-to-date copies of the compiled output from these files (the files *_no_yacc.* and *_no_flex.*, in particular).

These parsers basically 'read' the input file and for each statement, they add a Statement object within a TypeDescription object. This effectively reassembles a machine-readable form of the input file. Parsing is only a small part of the job of making a working model; instantiation is probably the bigger part.

Adding new statements to the language requires that the Statement struct be expanded to contain the necessary extra fields, and then requires functions to be implemented that can store parsed statements into the TypeDescription, and then more functions that actually run the statements. See {{src|ascend/compiler/statement.h}}, eg CreateFREE.

Note the 'families' of functions around each statement type, eg, 'run', 'do', 'create'.


=== Instantiation ===

When the user requests to create a model from a given TypeDescription, this is when ASCEND starts the process of MODEL '''instantiation'''. This is a very complicated process, because of the process of creating sub-models, and then handling all of the relationships between instances such as [[ALIASES]], [[ARE_THE_SAME]] as well as the rigours of [[Object-oriented_modelling#Parameterised_models|parameterised models]]. There is also very sophisticated processing called 'anonymous merging' that helps large repetitive models (eg arrays of similar equations) to not use more memory than they have to. Start by reading {{src|ascend/compiler/instantiate.h}}.


The phases of instantiation are as follows (text from [[User:DanteStroe]]):


# Models (instantiate models and disregard any other type of statements)
# Relations (instantiate "relations" and disregard any other type of statements)
# Logical Statements (instantiate logicals and disregard any other type of statements)
# When Statements (instantiate "when"s and disregard any other type of statements)
# LINK Statements (instantiate LINKS and disregard any other type of statements) - Added
# default (visit instance tree once more and if it is the case warn about any un-executed statements).
<div>''This article is incomplete or needs expanding. Please help out by adding your comments.''</div>

=== Bintokens ===

ASCEND includes the ability to compile machine-language representation of equations in the model you have written. This functionality has been found to be only marginally faster than the current expression evaluation engine, and is currently not operational, although it would not take a huge amount of work to reinstate it.

Bintokens only function when 'relation sharing' is turned on.

The code in {{src|ascend/compiler/bintoken.c}} does the job of writing a C source code file to <tt>/tmp/asc_bintoken.c</tt> and then compiling it and loading it using ascDynaLoad, and linking the evaluation routines into the instance tree. The code in {{src|ascend/bintokens/btprolog.h}} is a special header file designed to provide the minimum necessary data structures to allow ASCEND to communicate with the binary-compiled relations. Currently, this header file still depends on a couple of other ASCEND header files, which will impact on how we package this functionality (for Debian, RPM, Windows etc).


For the PyGTK GUI, {{src|pygtk/compiler.cpp}} defines some default pathnames for passing to the bintoken routines. The PyGTK GUI also currently fails to warn the user about the need to reload a model in order to force bintokens to be built.


=== Instance hierarchy ===

An instantiated MODEL (i.e. one which is loaded into memory but which has not yet been sent to a solver) in comprised of a tree of <tt>struct Instance</tt> objects arranged in a parent-child hierarchy (although there are other relationships between variables, such as <tt>ALIASES</tt> which transcend the parent-child structure). These 'struct Instance' objects are complicated assemblies of 'structs' and 'unions'; make sure you are completely familiar with these things if you start to play around with this code. See {{src|ascend/compiler/instance_types.h}} for the details.


Key instance types include


* relations
* variables
* constants
* arrays
* sets
* [[MODEL|MODELs]]
* simulation (the 'root' instance object)

Relations are stored in the compiler in the following data structures:

<div class="thumb tnone"><div class="thumbinner" style="width:1202px;">[[Image:Structrelation_coll_graph.png]] <div class="thumbcaption"><div class="magnify">[[File:Structrelation_coll_graph.png|<img src="/skins/common/images/magnify-clip.png" width="15" height="11" alt="" />]]</div><tt>Relation</tt> data structures in the ASCEND compiler</div></div></div>

===  METHODs ===

[[METHOD|METHODs]] run at the level of the ASCEND compiler, not at the level of the solver, so functions relating to the execution of METHODs revolve around manipulations of the instance tree. Start by reading the function <tt>Initialize</tt> in the file {{src|ascend/compiler/initialize.h}}.



=== Relationships ===

The following explicit relationships are tracked by the Compiler


* Part-whole (model members), including relations in models.
* structural isomorphism (are-alike clique), stored in the <tt>alike_ptr</tt> of Instance structs, see {{src|ascend/compiler/instance_types.h}}
* structural identity (are-the-same clique, parameter passing, aliasing), can be revisited using the <tt>AllPaths</tt> and <tt>WriteAliases</tt> functions (see {{src|ascend/compiler/instance_io.h}}.
* continuous variable referenced by equation or boundary.
* discrete variable referenced by logical equations and WHENs.
* discrete constants determining compilation alternatives (SWITCH).
* satisfaction of a nonlinear equation/inequality to a tolerance.
* units and dimensionality of variables, equations.
* a variety of stuff about sets of discrete values.
* variable values.
* interpretation of names in methods in one or more object scopes.

The following implicit relations are tracked:


* bounds, scaling, ode-classification on variables, scaling on relations.
* semi-continuous variable treatment for mixed-IP (solver_semi).
* relation inclusion in a model to be solved (.included, WHEN).
* model inclusion (WHEN).
* time dependent/event state-transition would be if we had the solver to manage it.
* objective functions.
* output file logging.

Note that the implicit (soft) nature of the relationships is precisely what we intended. It serves to separate model definition (which is simply listing a set of equations we assert to be true) from the model solution process. As soon as one gets overly aggressive, the compiler turns into a solver and this is a bad idea.


== Analyser ==

The <tt>analyze.c</tt> code lies in the <tt>base/generic/system</tt> directory and is reponsible for 'visiting' the instance hierarchy maintained in memory by the Compiler and turning it into a 'flat' '''system''' that can be passed on the the [[Solvers]].


First, the GUI calls the routine <tt>system_build</tt> which allocates space for <tt>slv_system_t</tt> object and then calls <tt>analyze_make_problem</tt>. 


=== analyze_make_problem ===

This is where the main work begins. 

Space is allocated for a temporary object of type <tt>problem_t</tt>. First the instance hierarchy is visited by the <tt>CountStuffInTree</tt> method, which accumulates counts of the various types of variables. 



==== analyze_make_master_lists ====

Next there is a called to <tt>analyze_make_master_lists</tt>, which allocates memory for lists of each type of variable (according the counts made), then calls <tt>PushInterfacePtrs</tt>, which seems to somehow fish out the correct links to items in the instance hierarchy and create the interim items in the lists inside the <tt>problem_t</tt> object. ''This is where variables are flagged as [[FIXED]] and [[FREE]], etc, and where derivatives are identified as such?''

(''a bit vague here'') After that <tt>CollectRelsAndWhens</tt>. This seems to do the job of organising the lists of WHEN statements, including the possibility of nested and conditional parts of the moment.

Next all variables in the found relations are marked ''incident''. Variables found in ''objective relations'' are also marked incident, as are real variables in <tt>CONDITIONAL</tt> relations, and boolean variables in logical relations and [[CONDITIONAL]] logical relations. [[WHEN|WHENs]] are numbered. 


Variables that did not get marked ''incident'' in the above process are moved off to separate 'unattached' lists. This completes the call to <tt>analyze_make_master_lists</tt>.

Note that objective relations ([[MINIMIZE]] an [[MAXIMIZE]]) are kept in a separate list. Lists of 'normal' relations, objective relations and conditional relations are mutually exclusive.


==== analyze_make_solvers_lists ====

Next, <tt>analyze_make_solvers_lists</tt> is called. (This seems to be a bit muddy: stuff seems to be done here to both the master list as well as the solver's list.)


==== system_generate_diffvars ====

Next <tt>system_generate_diffvars</tt> is called, which '''if any derivatives were found''', creates a set of ''derivative chains''. This gives the relationship between variables declared in the model, to identify which vars are supposed to be derivatives of which other vars. 



==== analyze_configure_system ====

The routine <tt>analyze_configure_system</tt> does the job of passing off the lists from the <tt>problem_t</tt> and giving them to the <tt>slv_system_t</tt>. <tt>NULL</tt>s are assigned in the <tt>problem_t</tt> in order to make it clear that a list has been 'disowned' by the temporary problem_t structure.


''PopInterfacePtrs''?


==== analyze_free_lists ====

Finally <tt>analyze_free_lists</tt> cleans up any not-disowned stuff still in the <tt>problem_t</tt> structure. The result is that the <tt>slv_system_t</tt> contains everything you need to solve your problem, but in such a way that you don't need to 'talk' directly to the ASCEND instance hierarch. This way your solver only needs to speak the reduced vocabulary of the <tt>slv_system_t</tt> and can safely ignore the implementation details of the Compiler.



== System ==

The '''system''' is the 'flat' representation of the '''instance tree''', generated by the '''analyser''' (above). It is (in essence) a set of lists of '''relations''' and '''variables''' (there are various types of variables; the main one is the real-valued <tt>solver_var</tt>, but boolean, integer, 'symbol' variables are possible, and conditional modelling constructs are provided for also). The system also keeps lists of '''boolean variables''', '''logical relations''', '''conditionals''' and '''when''' disjunctions.


The '''system''' code is intended to cover all aspects of creating and retrieving data from the 'flat' system representation created by the analysis steps above. It is intended that solvers will 'talk' only to the system representation of a model, and never to the instance tree directly. In principle, it should be possible to use ASCEND in a different way, by create a new 'system provider' to replace the current instance tree implementation, this could be for example some kind of CFD code, or something like that.

In user interface terms, it is desirable to be able to solve different sub-models independently. For example, in a whole flowsheet of a power station, it may be of interest to be able to, in isolation, solve what is happening just in the turbine, for a given set of turbine inputs and parameters. This is especially useful in hard-to-solve (hard-to-converge) models. In this use case, ASCEND would create a number of different 'system' objects all linked back to a common instance tree. Then solvers would in turn be able to 'visit' these system and run their algorithms upon them.

Some key 'system' functions include


* <tt>relman_eval</tt> (residual of a relation)
* <tt>relman_diff</tt> (derivative of a residual with respect to the variables in the relation)
* <tt>relman_diff2</tt>, <tt>relman_hess</tt> (second derivatives, hessian matrix elements)
* <tt>bndman_real_eval</tt>, <tt>bndman_log_eval</tt> (for evaluation of boundary crossings)

=== Flags and Filters ===

Each of the relations and variables present in the system have some memory associated with them in which a set of flags can be stored. These are used to pass information from the solver back to the user interface, and vice versa. Some of these flags include:


* REL_INCLUDED: set to true when a relation is 'included' in the current system. This is a user-controllable thing. It can be set using the GUI, or in a [[METHOD]] with code like <tt>myrel.included&nbsp;:= TRUE;</tt>.
* REL_EQUALITY: set to true when a relation is an equality relation, as opposed to an inequality.
* VAR_ACTIVE: set to true when a variable is in the currently-being-solved 'block'.
* VAR_FIXED: set to true when a variable was set [[FIX|FIXed]] by the user (either via a [[METHOD]], or manually using the GUI).

When implementing a new solver, it is critical that you make use of these flags and the associated filter methods (see <tt>rel_apply_filter</tt> in {{src|ascend/system/rel.h}} and <tt>var_apply_filter</tt> in {{src|ascend/system/var.h}}), because in complex ASCEND models, there will often be variables and relations that you should not include in your solver calculations.



== Solver ==

Add:


* solver interface: what the solver sees, and what the ASCEND compiler sees.
* mtx routines

The system module hands off the <tt>slv_system_t</tt> to the '''slv server''' and allows it to be queried by one of the '''slv clients''' that actually does the solving work.


The slv server also implements a general-purpose way of getting and setting '''solver parameters''' for the various solvers.

The solver performs '''blocking''' of equations. This means dividing the overall system into sequences of subsystems that can be solved without knowledge of any other as-yet-unsolved variables. The allows the Newton iteration to work on smaller matrices, for great speed and improved convergence.


=== Solver API ===

Communication between solvers and ASCEND is a two-way process. When the solver is first loaded, ASCEND looks for a 'register' function that tells ASCEND what functions its provides. A <tt>struct slv_registration_data</tt> is passed to ASCEND containing various function points. Then, when ASCEND wants to solve its problem, it calls these various functions in sequence. The essential functions are:



* '''ccreate''' Create solver-specific data structures (invoked via <tt>slv_select_solver</tt> and <tt>slv_switch_solver</tt>)
* '''cdestroy''' Destroy solver-specific data structures (invoked via <tt>slv_destroy</tt> and <tt>slv_destroy_client</tt>)
* '''celigible''' Determines whether or not the solver is capable of solving the given <tt>slv_system_t</tt> as it is currently set up (e.g. some solvers cannot do optimization, or inequalities, etc). (invoked via <tt>slv_elegible_solver</tt>)
* '''getdefparam''' Copies the solver's default parameters values into the given structure (invoked via <tt>slv_get_default_parameters</tt>)
* '''get_parameters''' Copies the current solver parameters to the given structure (invoked via <tt>slv_get_parameters</tt>)
* '''set_param''' Sets the current system parameters to the values contained in the given structure.  It is recommended that one gets the parameters first, before one modifies them and sets them,

	especially if not all of the parameters are to be modified (and you never know when that might suddenly become true because a new parameter was added to the structure).  Parameters will only be accepted by an engine if they came from that engine, so fetching before setting is not only a good idea, it's the law (gas engines don't run on diesel very well...). @par (invoked via <tt>slv_set_parameters</tt>)


* '''getstatus''' Copies the current system status into the given structure (invoked via <tt>slv_get_status</tt>)
* '''solve''' Attempts to solve the entire system in one shot (i.e. performs as many iterations as needed or allowed).  For some solvers, slv_iterate() and slv_solve() may mean the same thing. Returns 0 on success (invoked via <tt>slv_solve</tt>)

See {{src|ascend/solver/solver.h}} for the full function prototypes above. For sample implementations, see the {{srcdir|solvers}} directory, perhaps starting with QRSlv, IPOPT and CONOPT.

The '''solve''' function above (as well as the other methods) make various calls back to the '''system''' API (above), which allows list of equations to be obtained, residuals of equations to be calculated, etc.


=== Integrator ===

The integrator sits aside the solver and coordinates a time-stepping process that may be imeplemented using whatever additional logic you want. We currently have the LSODE integrator as well as a an alpha-quality implementation with the IDA solver. The IDA solver is capable of doing conditional model switching, but the ASCEND wrapper doesn't yet fully implement that.

The Integrator API permits you to implement your own blocking/solving algorithms, or to re-use the main solvers, as desired. The LSODE implementation currently uses the ASCEND solver to perform block solution. The IDA implementation isn't quite as clever.

See [[Integrator API]] for more details.


== Utility and General Routines ==

There are various list and string and collection 'classes' in these directories that support the solver and compiler functionality, as well as some of the GUI functions.


=== Error, warning, and message reporting ===

Error, warning and message reporting in ASCEND is achieved via {{src|ascend/utilities/error.h}}. Calls to this function work like calls to 'printf', except that error output is channeled to an appropriate place in the PyGTK GUI, via Python, or else goes to the console in the case of the Tcl/Tk GUI.

Some typical usage would be:

<source lang="c">if(something){
    ERROR_REPORTER_HERE(ASC_USER_ERROR,"You did something wrong");

    return 1;
}
ERROR_REPORTER_HERE(ASC_PROG_NOTE,"Value myvar =&nbsp;%d",myvar);

if(somethingelse){
    ERROR_REPORTER_HERE(ASC_USER_WARNING,"Something is going on, and I don't what it is");
}</source>

Sometimes it is necessary to compact several 'fprintf' style calls into a single error message, sometimes because of the way old ASCEND output functions were written. For example, from statio.c,

<source lang="c">error_reporter_start(sev,filename,line,NULL);
  FPRINTF(ASCERR,"%s\n",message);

  if(stat!=NULL){
    /* write some more detail */
    g_show_statement_detail = ((noisy!=0)&nbsp;? 1 : 0);

    WriteStatement(ASCERR,stat,2);
    g_show_statement_detail = 1;

    if (GetEvaluationForTable()!=NULL) {
      WriteForTable(ASCERR,GetEvaluationForTable());

    }
  }else{
    FPRINTF(f,"NULL STATEMENT!");
  }

  error_reporter_end_flush();</source>

In addition, we have some ways to cache many different error messages, and only to output them if we decide we want them later. In this case, we use the 'error_reporter_tree' functionality:

<source lang="c">
bool has_error = 0;
error_reporter_tree_start();
do_subordinate_tasks();
if(error_reporter_tree_has_error()){
	has_error = 1;
}else{
	has_error = 0
}
if(has_error){
	error_reporter_tree_end();
	ERROR_REPORTER_NOLINE(ASC_USER_ERROR,"failed");
}else{
	ERROR_REPORTER_NOLINE(ASC_USER_SUCCESS,"success");
}</source>

This allows us to make use of the error reporter mechanism to track errors occurring in deeply nested code without needing to use an exception-like mechanism. This is particularly useful in code that transcends python and C and C++, such as when solvers are integrating models containing external relations.

Note that in ASCEND, we usually use <tt>FPRINTF</tt> instead of <tt>fprintf</tt>. FPRINTF is a macro which effectively wraps the above error_reporter mechanism, ensuring that we can capture all console output and display it in the GUI.

For messages which are genuinely only of interest to developers, please use the <tt>CONSOLE_DEBUG</tt> macro. This includes automatic output of the file, line, and function in which the statement is located, aiding debugging.

You should also note that some external solvers make use of error reporting callback functions. An example of how to hook these functions into ASCEND is given in {{src|solvers/ida/ida.c}} with the function <tt>integrator_ida_error</tt>.

=== File pathname handling: ospath.h ===

In order to address the demands of locating and opening files in a cross-platform code environment, we have implemented a small set of routines that can deal with both Windows/DOS file paths as well as Linux/Unix style paths. This was inspired somewhat by the Python 'import os.path' module, but is a completely different implementation. The code is outlined in {{src|ascend/general/ospath.h}}. Note that correct use of this module requires that returned paths be carefully freed using <tt>ospath_free</tt>, because these functions use dynamically allocated memory.


= External Libraries =

[[External libraries]] are supported. You can use both 'black box' external relations (for computation) or 'external methods' for doing special things to the model hierarchy (model setup and reporting).


The architecture is there for <tt>dlopen</tt>ing of whatever module you need at runtime. And example of how to build and link an external package is given in the <tt>models/johnpye/extfn</tt> directory.


= Python wrapper =

The '''Python interface''' to ASCEND is implemented as a thin C++ layer on top of the core C code. This C++ layer is then wrapped with SWIG to provide an object-oriented interface to the ASCEND library, types, simulation, instance tree, variables and relations, and so on. There is only mimimal code required to interface the C++ layer with Python, since SWIG does most of this work (and also permits ASCEND to be linked to other languages if desired).

The use of C++ in ASCEND is actually rather unfortunate, as it results in a much larger binary than would be required if only C had been used. Use of C++ was helpful in the wrapping however, because it makes it easier to create object-oriented wrappings, and also provides some useful memory management via the STL libraries of C++ (map, list, vector, etc). But we would like to get rid of the C++ wrapper one day and wrap libascend for Python using just plain C.

The key file for understanding how libascend functionality is exposed in Python is pygtk/ascpy.i, which in turn makes use of many pygtk/*.h C++ header files. You will need to understand basic usage of SWIG first.


The Python wrapper is binary dependent on Python; if you want to use ASCEND from a new version of Python, you need to recompile the Python wrapper.


= GUI interfaces =

GUIs talk to the '''solver''' and the '''compiler''' depending on what they're doing. All GUI function '''should''' be designed such that the internals of the data structures used by the solver and or compiler are not depended on: a proper API.


== PyGTK interface ==

The PyGTK interface (see [[PygtkScreenshots]]) implements a fully object-oriented interface on top of the Python wrapper ('import ascpy') of libascend.

An important distinction in the PyGTK code is that the 'library', which holds details of the currently open models and external packages, etc, is considered to be subordinate to the model which is being worked on. In the Tcl/Tk GUI, the library is an entity that stands aside regardless of the currently instantiated model.

Another distinction is that the 'solver' in the PyGTK interface is kept as a somewhat distributed concept. Unlike the Tcl/Tk interface, there is not a dedicated 'solver' window. You can edit the parameters for the solver via the menus, and you can examine its blocking and solving via the 'diagnose' window. It was thought that by tying the solver more tightly with the model browser it would lead to a more intuitive interface.

Because the PyGTK GUI is totally implemented as Python code, with no compiled code associated with GUI elements, there is no need to have PyGTK installed on your system at the time of building ASCEND. This means that you can upgrade PyGTK on your machine and there should be no need to recompile ASCEND.


== Tcl/Tk interface ==

The '''Tcl/Tk interface''' is implemented via directly-coded access to the Tcl/Tk interpreter using the C-language bindings provided by Tcl. The Tk graphical interface is defined via a series of Tcl scripts. This implements full access to the ASCEND C functionality, but expanding the interface is rather laborious due to leg-work of transferring string and numerical values to and from Tcl/Tk.



= Extending ASCEND =

* [[External libraries]]
* 'packages'



 [[Category:Incomplete]]
[[Category:Development]]