External Integrators: Difference between revisions
Restored page from Google Cache, uploaded by John Pye |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{experimental}} | |||
Integrators are loaded dynamically ('dlopened') from DLL/SO files at runtime. This will allow us to offer a wider range of such tools, without requiring that a new release of ASCEND be made each time a new integrator or solver is to be added. | Integrators are loaded dynamically ('dlopened') from DLL/SO files at runtime. This will allow us to offer a wider range of such tools, without requiring that a new release of ASCEND be made each time a new integrator or solver is to be added. | ||
The API for integrators is a reasonably 'narrow' one; its documentation can be seen in {{src|ascend/integrator/integrator.h}} (or via [http://ascend.cheme.cmu.edu/dox/integrator_8h.html doxygen]). | The API for integrators is a reasonably 'narrow' one; its documentation can be seen in {{src|ascend/integrator/integrator.h}} (or via [http://ascend.cheme.cmu.edu/dox/integrator_8h.html doxygen]). | ||
== A sketch of the Integrator API as seen by external integrators == | == A sketch of the Integrator API as seen by external integrators == | ||
Loading of an integrator DLL can be triggered by an <tt>IMPORT</tt> statement in your model file. As with all <tt>IMPORT</tt>ed files, this could be a python script, a DLL, or some other yet-to-be-implemented file-type with an [[Import_handlers|import handler]]. | Loading of an integrator DLL can be triggered by an <tt>IMPORT</tt> statement in your model file. As with all <tt>IMPORT</tt>ed files, this could be a python script, a DLL, or some other yet-to-be-implemented file-type with an [[Import_handlers|import handler]]. | ||
The DLL will contain a <tt>yourdllname_register</tt> method, which will do the job of registering the Integrator. | The DLL will contain a <tt>yourdllname_register</tt> method, which will do the job of registering the Integrator. | ||
| Line 16: | Line 13: | ||
The <tt>integrator_register</tt> function will then add the integrator to the list of registered integrators, and from that point on it will be available in the user interface list of interators (PyGTK GUI only). Parameters defined for the integrator will be visible via the Integrator dialog, and output from the integrator will be available in the usual way. You can provide a statistics-reporting function as well, although this has not yet been incorporated into the GUI. | The <tt>integrator_register</tt> function will then add the integrator to the list of registered integrators, and from that point on it will be available in the user interface list of interators (PyGTK GUI only). Parameters defined for the integrator will be visible via the Integrator dialog, and output from the integrator will be available in the usual way. You can provide a statistics-reporting function as well, although this has not yet been incorporated into the GUI. | ||
If your integrator follows the protocol of the LSODE integrator, you can use <tt>integrator_analyse_ode</tt> to analyse your problem and create the standard lists of variables and equations. Otherwise you can define your own 'analyse' function that accesses the <tt>slv_system_t</tt> directly in order to define the integration problem. | If your integrator follows the protocol of the LSODE integrator, you can use <tt>integrator_analyse_ode</tt> to analyse your problem and create the standard lists of variables and equations. Otherwise you can define your own 'analyse' function that accesses the <tt>slv_system_t</tt> directly in order to define the integration problem. | ||
| Line 22: | Line 18: | ||
The basic flow of information from your model file to the integrator is something like: | The basic flow of information from your model file to the integrator is something like: | ||
model_file --> instance_hierarchy --> prob_t --> slv_system_t --> IntegratorSystem | |||
Your 'analyse' function takes care of just the last step. | Your 'analyse' function takes care of just the last step. | ||
== Current external integrators == | == Current external integrators == | ||
| Line 34: | Line 27: | ||
Currently, we offer: | Currently, we offer: | ||
* [[LSODE]] provides [[ODE]] solution using Adams-Moulton and Backwards Difference Formula techniques. | * [[LSODE]] provides [[ODE]] solution using Adams-Moulton and Backwards Difference Formula techniques. | ||
| Line 41: | Line 33: | ||
We also propose to add [http://www.netlib.org/ode/rksuite/ RKSUITE] for a range of explicit Runge-Kutta integrators, and perhaps [http://www.unige.ch/~hairer/software.html RADAU5] for an implicit one-step integrator. | We also propose to add [http://www.netlib.org/ode/rksuite/ RKSUITE] for a range of explicit Runge-Kutta integrators, and perhaps [http://www.unige.ch/~hairer/software.html RADAU5] for an implicit one-step integrator. | ||
A blended explicit-implicit integrator might be worth looking at also, such as [http://web.math.unifi.it/users/brugnano/BiM/index.html BIMD]. | A blended explicit-implicit integrator might be worth looking at also, such as [http://web.math.unifi.it/users/brugnano/BiM/index.html BIMD]. | ||
| Line 47: | Line 38: | ||
See also [[External Solvers]] and [[Integrator API]]. | See also [[External Solvers]] and [[Integrator API]]. | ||
[[Category:Development]] | [[Category:Development]] | ||
Latest revision as of 08:10, 29 March 2011
Integrators are loaded dynamically ('dlopened') from DLL/SO files at runtime. This will allow us to offer a wider range of such tools, without requiring that a new release of ASCEND be made each time a new integrator or solver is to be added.
The API for integrators is a reasonably 'narrow' one; its documentation can be seen in ascend/integrator/integrator.h (or via doxygen).
A sketch of the Integrator API as seen by external integrators
Loading of an integrator DLL can be triggered by an IMPORT statement in your model file. As with all IMPORTed files, this could be a python script, a DLL, or some other yet-to-be-implemented file-type with an import handler.
The DLL will contain a yourdllname_register method, which will do the job of registering the Integrator.
Registering an integrator is done by creating (allocated) an IntegratorInternals object and filling in its details, then passing it (as a pointer) to the function integrator_register. The IntegratorInternals struct contains pointers to various functions required for the implementation of the new Integrator. It also includes the name of the new integrator, and a ID number (whether this last has any use is yet to be seen).
The integrator_register function will then add the integrator to the list of registered integrators, and from that point on it will be available in the user interface list of interators (PyGTK GUI only). Parameters defined for the integrator will be visible via the Integrator dialog, and output from the integrator will be available in the usual way. You can provide a statistics-reporting function as well, although this has not yet been incorporated into the GUI.
If your integrator follows the protocol of the LSODE integrator, you can use integrator_analyse_ode to analyse your problem and create the standard lists of variables and equations. Otherwise you can define your own 'analyse' function that accesses the slv_system_t directly in order to define the integration problem.
The basic flow of information from your model file to the integrator is something like:
model_file --> instance_hierarchy --> prob_t --> slv_system_t --> IntegratorSystem
Your 'analyse' function takes care of just the last step.
Current external integrators
See Solvers for the full list of external solvers in ASCEND.
Currently, we offer:
- LSODE provides ODE solution using Adams-Moulton and Backwards Difference Formula techniques.
- IDA provides DAE solution using Backwards Difference Formula.
- DOPRI5 provides explicit one-step integration using Dormund-Prince equations.
We also propose to add RKSUITE for a range of explicit Runge-Kutta integrators, and perhaps RADAU5 for an implicit one-step integrator.
A blended explicit-implicit integrator might be worth looking at also, such as BIMD.
See also External Solvers and Integrator API.