Post processing interface

The post processing interface gives easy access to the internal database of Mosel. This database is composed of all model objects that are defined in a BIM file (like constants) or created during the execution of a model (like arrays). Obviously the dynamically created objects are only available after the model has been run.
Note that the dictionary is not available if the model has been compiled with the option ``s'' (strip symbols) and no identifier has been explicitly published (refer to the description of the public qualifier in declarations): such a model cannot be accessed through the post processing interface.

Lists

Lists are an ordered collection of objects. The functions available here allows to get properties of a list (size and type) as well as enumerate all elements it contains.

Sets

Sets are used to index arrays: any model using arrays also uses sets even if no set has been defined explicitly. Note that a range is a special case of a set of integers which contains all consecutive integers in a given interval.

Arrays

In Mosel, arrays are used to store any kind of object, including other arrays or sets. The type of the array is also the type of the collected objects. The storage class indicates how these objects are stored in memory. In most cases this information can be ignored as all functions accessing arrays automatically handle each special case.

The storage class is encoded in two bits:

XPRM_GRP_DYN

The array is a dynamic array: there is no range defined for its indexing sets ( i.e. there cannot be any ``out of range error'' for this array as the indexing sets may grow on demand).

XPRM_GRP_GEN

The array is a general (= dynamic bounded) array: the number of elements may be augmented up to the range limits specified at its creation.

Typically a ``sparse table'' uses a storage class of XPRM_GRP_DYN or XPRM_GRP_DYN|XPRM_GRP_GEN (dynamic or fixed ranges). The Mosel compiler may decide which storage class should be used for each array: even a ``dense table'' may be created using a storage class of XPRM_GRP_DYN if the model does not provide enough information for deciding the actual size of the array at compile time.

For dynamic arrays one may distinguish between logical and true entries. Assuming an array has been created with the range 1..5, but only entry 3 has been defined, this array has 5 logical entries but only a single true entry. This difference is mainly noticeable in the functions provided for enumerating arrays.

Note that at the library level all arrays are indexed by integers (negative value are allowed). To use text index values, the conversion from the text to the order number must be performed using the function XPRMgetelsetndx.

Records

Records are a special kind of user defined types that associate to a an entity a collection of fields. Thanks to the following functions one can enumerate these fields and get the value of a specific field of given record.

Problems

Like all statements of a model, the routines presented in this section are executed in the context of an active problem. By default, at the beginning of the processing of a model an initial problem is created: the ``main problem''. After the end of the execution of a model, this particular problem is active but a different problem can be selected using the routine XPRMselectprob. The following functions enable the user to access various information related to linear constraints and decision variables created or used in the context of the active problem. With the exception of the XPRMexportprob function, all operations in this section require the problem to be loaded into an optimizer either explicitly (e.g. procedure `loadprob' of the module ``mmxprs'') or implicitly by using an optimization operation (e.g. procedure `maximize' of the module ``mmxprs'') in the model. If no problem is available (model not run, no constraint created by the model or problem not loaded in an optimizer) a specific default value is returned by each function.

Miscellaneous