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.

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)