Server-Solvers-Interacter-Interfacer-Modeler-Presolver Libraries and Executable (SSIIMPLE)
0 likes501 views
The document serves as a reference manual for the 'ssiimple' system architecture created by Industrial Algorithms LLC, which focuses on a portable framework for solving industrial problems using modular libraries and executables. It describes the key components including the impl server, interacter, interfacer, modeler, and presolver, detailing the management of sparse data resources and the integration of various solvers. The manual also outlines server routines for memory management, initialization, and data manipulation specific to the impl architecture.
Server-Solvers-Interacter-Interfacer-Modeler-Presolver Libraries and Executable (SSIIMPLE)
- 1. i M P l Server-‐Solvers-‐Interacter-‐Interfacer-‐Modeler-‐ Presolver Libraries and Executable (SSIIMPLE) "Reference Manual" i n d u s t r I A L g o r i t h m s LLC. www.industrialgorithms.com Version 1.0 July 2014 IAL-‐IMPL-‐SSIIMPLE-‐RM-‐1-‐0.docx Copyright and Property of Industrial Algorithms LLC.
- 2. Introduction The term SSIIMPLE is used to describe IMPL’s system architecture which stands for Server-‐Solvers-‐ Interacter-‐Interfacer-‐Modeler-‐Presolver Libraries and Executable. IMPL is an acronym for Industrial Modeling and Programming Language provided by Industrial Algorithms LLC. SSIIMPLE is designed to be portable to both Windows and Linux operating systems on 32 and 64-‐bit platforms and to have the smallest footprint as possible in order to allow what we call “poor man’s parallelism” (PMP). This essentially means running as many IMPL problem instances as there are CPU’s or threads where each IMPL problem instance would essentially use the same model data but with different solver settings, solvers, initial-‐values, column orderings, etc. However, it is also possible to modify either or both of static and dynamic model data as well as the solver settings within a given problem instance thread. The IMPL Server is the main library that contains IMPL’s sparse data memory in the form of several one-‐ dimensional (1D) arrays of integers, reals and strings we call “resources” and many data manipulation “routines” to insert, update, view and delete the resource data as well as specialized numerical routines. These diverse sparse data resources enable IMPL to receive and retrieve the problem data (i.e., model and solution data) quickly and efficiently and is unique to IMPL. IMPL supports eleven (11) different resources as follows: series-‐set (head, tail and stride integers), simple-‐set (integer key, real values), symbol-‐set (string key, integer values), catalog (integer key, string values), list (integer keys, integer values), parameter (integer keys, real values), variable (integer keys, complex values), constraint (integer keys, complex values), derivative (integer and real values), expression (integer and real values) and formula (integer keys, integer and real values). Each resource is broken-‐down into one or more “rosters” such as a parameter or variable identifier or name where each roster is broken-‐down further into one or more “references” or “records” accessed using a “rack of keys”; the maximum number, degree or rank of the keys is eight (8). Each reference or record has a “range” of values usually used to manage the vector of time-‐period profiles. The resources and rosters are referred to using integer numbers where ultimately the “row” is the final element in the 1D resource arrays also indexed by an integer number. In summary, a resource has one or more rosters, a roster has one or more references/records, a reference/record has one or more rows where the number of rows for a reference/record is defined by its range and to refer to a reference/record it requires one or more keys and a “cursor”. The term cursor, which is also a relational database term, is used to describe the internal row-‐element index within the reference/record.
- 3. The IMPL Interacter and the IMPL Interfacer details can be found in the IPL and IML reference manuals respectively where these provide the integration of static and dynamic model data and solution data. The IMPL Modeler creates or generates the necessary dependent sets, lists, catalogs and parameters and the required variables, constraints, derivatives and expressions where all of the resource rosters can be found in the IMPL.imp, IMPL.imv and IMPL.imc files. The IMPL Modeler is also responsible for performing the digitization into discrete-‐time and distributed-‐time i.e., creating the time-‐dimension for the parameters, variables and constraints. The IMPL Presolver binds all of the third-‐party open-‐source and commercial linear, mixed-‐integer and nonlinear solvers and converts the “original” model into the “optimizable or organized” model via IMPL’s own primal presolving routine. The IMPL Presolver is also responsible for managing the computation of the first-‐order partial derivatives using the Complex-‐Step Method (CSM) (hence the reason the variable and constraint resource values are complex numbers) and manipulating the sparse matrix of derivatives (Jacobian) into either sorted row or column storage. The IMPL Solvers contains several specialized algorithms to perform for example steady-‐state detection, nonlinear simulation (zero degrees-‐of-‐freedom), nonlinear data reconciliation and regression and bounds testing for infeasibility diagnostics. The Executable is any main program that calls IMPL from any computer programming language that can bind to dynamic link or shared libraries such as our Console program programmed in Intel Fortran 2008. The next section to follow describes the IMPL Server routines which are used to initialize, allocate and deallocate IMPL’s sparse data memory. The last section simply details how to call the IMPL Interfacer, Modeler and Presolver where there is a separate reference manual to document the IMPL Interacter routines. All of the valid enumerations or entries for the arguments found below can be located in the header file IMPL.hdr. Server Routines Initialize IMPL’s settings from the IMPL.set file, signals and statistics and verify the IMPL license in the IMPL.lic file. Both the IMPL.set and IMPL.lic files are expected to be in the same directory as the IMPL binaries. The “subject” argument is also known as the “fact” flag in the other routines and contains both the path and file names for the problem to be modeled and solved.
- 4. integer function IMPLroot(subject: string) Allocate and initialize IMPL’s memory per resource from the IMPL.mem file which is expected to be in the same directory as the IMPL binaries. The “type” argument is the resource number. integer function IMPLreserve(subject: string, type: integer) De-‐allocate IMPL’s memory per resource. integer function IMPLrelease(type: integer) Re-‐initialize IMPL’s memory per resource. integer function IMPLrefresh(type: integer) Re-‐allocate IMPL’s memory per resource. See the memory file IMPL.mem for examples of the arguments. integer function IMPLresize(type: integer, num: integer, rank: integer, range:integer, len: integer, lenprime: integer, lenprime2: integer, lenkey: integer, lenval: integer) Serialize (marshalling) IMPL’s memory per resource. The resource will be saved to a binary or unformatted *.bdt file. integer function IMPLrender(subject: string, type: integer) De-‐serialize (unmarshalling) IMPL’s memory per resource from the *.bdt file. integer function IMPLrestore(subject: string, type: integer)
- 5. Output a message to IMPL’s log file. integer function IMPLwritelog(message: string) Output IMPL memory per resource to a formatted file i.e., *.dtr (series-‐set), *.dt s (simple-‐set), *.dty (symbol-‐set), *.dtg (catalog), *.dtl (list), *.dtp (parameter), *.dtv (variable), *.dtc (constraint) and *.dtf (formula). The “begin” and “end” arguments if both zero (0) will output all rosters in the resource else selected roster numbers can be specified. integer function IMPLwriteall(subject: string, type: integer, begin: integer, end: integer) Output IMPL’s resource memory metrics. integer function IMPLreport(subject: string) Find the row-‐element index number for a given roster name (or identifier) and the rack (or tuple) of keys. The roster number and resource number are inferred from the roster name. integer function IMPLrow(name: string, keys: integer*numkeys) Get (view) a single resource row-‐element value using the row-‐element index number. The “item” argument specifies which item of the resource to select. real function IMPLreview1(type: integer, row: integer, item: integer) Get (view) multiple resource row-‐element values using the “row” as the start or begin index and “nrow” as the number of rows. subroutine IMPLreview2(type: integer, nrow: integer,
- 6. row: integer, item: integer, value: real*nrow) Set (update) a single resource row-‐element value. integer function IMPLrevise1(type: integer, row: integer, item: integer, value: real) Set (update) multiple resource row-‐element value. integer function IMPLrevise2(type: integer, nrow: integer, row: integer, item: integer, value: real*nrow) Set an IMPL setting. integer function IMPLreceiveSETTING(setting: string, value: real) Get an IMPL setting, signal or statistic. real function IMPLretrieveSETTING(setting: string) real function IMPLretrieveSIGNAL(setting: string) real function IMPLretrieveSTATISTIC(setting: string) Output IMPL’s model statistics which summarizes the original and optimizable/organized model’s details as well as IMPL’s presolving and solving statistics. integer function IMPLsummary(subject: string) Output IMPL’s model sensitivity data to a *.jdt which is essentially the Jacobian of the problem i.e., sparse matrix of first-‐order partial derivatives. This file is essentially the output of the derivatives resource.
- 7. integer function IMPLwritesensitivity(subject: string, modelpointer: integer, flag: integer) Output IMPL’s model symbology data to a *.ndt file similar to the CPLEX LP file format for both linear, mixed-‐integer and nonlinear problem. The “modelpointer” argument is an integer pointer referencing the IMPL Modeler. This file is essentially the output of the expressions resource. integer function IMPLwritesymbology(subject: string, modelpointer: integer, flag: integer) Interfacer, Modeler and Presolver Routines The IMPL Interfacer routine is separated into two routines suffixed with an “i” and an “e” with identical arguments as below in order to reduce the stack-‐size of the call. These routines implement the functionality of IML (and OML). The argument “fob” is a 64-‐bit integer and is used to encrypt or obscure the IML file if non-‐zero. integer function IMPLinterfacer(fact:string, form: integer, fit: integer, filter: integer, focus: integer, face: integer, factor: real, fob: integer*integer, frames: string) The IMPL Interfacer routine is also separated into two routines suffixed with an “v” and an “c” with identical arguments as below in order to reduce the stack-‐size of the call. These routines create or generate the dependent sets, lists, catalogs and parameters (“v” suffix with force = PARAMETER), the variables (“v” suffix with force = VARIABLE) and constraints (“c” suffix with force = CONSTRAINT). integer function IMPLmodeler(fact: string, form: integer, fit: integer, filter: integer, focus: integer, filler: integer, foreign: string, force: integer)
- 8. The IMPL Presolver routine performs the derivative calculations and the primal presolve as well as preparing the LP, QP, MILP and NLP sparse matrix data to be presented to the third-‐party solvers. integer function IMPLpresolver(fact: string, form: integer, fit: integer, filter: integer, focus: integer, factorizer: integer, fork: integer, fresh: integer, flashback: integer, feedback: integer)