The details in this, and the following, sections link to the Fortran API documentation. For all other interfaces, please read through The public API of CONOPT.

The call to CONOPT is through the coi_solve() entry point in the Library. Before CONOPT can be called, the modeler must provide information about basic model sizes and interface options by defining a so-called Control vector.

While CONOPT is running it needs various types of information about the model, both static information about sizes and about the structure of the model, and dynamic information about the nonlinear functions in the model. The dynamic information must be provided through a set of callback routines that CONOPT can call. Before coi_solve() is called the modeler must register the static size information and pointers to the callback routines using a set of registration routines called COIDEF_Xx, where Xx corresponds to the routine purpose. Throughout the section under INTRODUCTION, we will describe the basic coi_solve() call, the callback routines, and their registration calls. A utility routine that defines the library version is also described.

The main routines in the CONOPT Library fall into six groups:

Before the optimization is started the modeler must create and initialize a so-called “Control vector” that is used define most aspects of the model to CONOPT. This phase is described in The Control Vector section.
The Control vector must be filled with a lot of static information about the model such as sizes, calling conventions, objective, licensing, and options. This is all performed using some COIDEF_Xx routines that operate on the Control vector. The routines for registering the sizes are described in the Registration of problem sizes section. While the routines for registering the options are described in the Registration of options and section.
In addition to sizes and options, CONOPT needs some routines that define the structure of the model and the nonlinearities and other routines for communication. These routines must be provided by the modeler as a set of callback routines and the entry-points must be stored in the Control vector using some COIDEF_xx routines described in Registration of callback routines section.
Before the optimization starts CONOPT can receive non-default option values from either a file or an option routine. These are defined through the use of optional callback routines coidef_optfile() and coidef_option().
To define a particular model CONOPT will call a model-defining routine called ReadMatrix and described in Defining the Model section. The callback routines must be provided by the modeler and registered before coi_solve() is called. The arguments to the model defining routines are arrays allocated and owned by CONOPT, and the modeler must enter the data describing the model into these arrays.
During the optimization, CONOPT will repeatedly call a routine called FDEval that must be able to return function and gradient values. Again, the implementation of this callback routine must be provided by the modeler and registered before coi_solve() is called. Section Evaluating Non-linear Function Values and Derivatives describes the routine in detail. The section also describes an optional callback routine for computing intervals of functions and gradients. Section Defining Second Order Information describes three optional callback routines for second order information. When the optimization has finished but before CONOPT returns, it will call two output routines with the solution values as arguments. These mandatory call routines are described in section Returning the Solution. During the optimization, CONOPT will also call some message passing routines. The mandatory Message routine is used to transmit general messages in text form from CONOPT to the modeler and the mandatory ErrMsg transmits messages that refer to variables and/or constraints. In addition, an optional Progress routine is called once per iteration. These callback routines are described in section Message Passing and Error Reporting.

There are no restrictions on the form or content of the many user-provided callback routines. They can be hand-coded implementations of a particular model (as shown in the Examples using CONOPT). Alternatively, they can be general-purpose routines that call routines in the modeling system that called CONOPT in the first place. The individual modeler routines may call other routines and may communicate with each other, for example through common blocks or global variables. A vector of user controlled memory called USRMEM that CONOPT passes to all the modeler’s routines can also be used for communication in a thread-safe environment. The CONOPT DLL itself is thread-safe.

The rest of the document discusses various topics: Section Non-default Options shows how to define non-default options and section Utility Routines describes some utilities. The Additional Information provides a summary over the routines, an overview over their relative order, a list of the available options, and a list of error codes.