Tempest_in_Action/tempest-devel/resources/3rdparty/glpk-4.65/doc/glpk03.tex

%* glpk03.tex *%

\chapter{Utility API routines}

\section{Problem data reading/writing routines}

\subsection{glp\_read\_mps --- read problem data in MPS format}

\synopsis

\begin{verbatim}
   int glp_read_mps(glp_prob *P, int fmt, const glp_mpscp *parm,
                    const char *fname);
\end{verbatim}

\description

The routine \verb|glp_read_mps| reads problem data in MPS format from a
text file. (The MPS format is described in Appendix \ref{champs}, page
\pageref{champs}.)

The parameter \verb|fmt| specifies the MPS format version as follows:

\verb|GLP_MPS_DECK| --- fixed (ancient) MPS format;

\verb|GLP_MPS_FILE| --- free (modern) MPS format.

The parameter \verb|parm| is reserved for use in the future and should
be specified as \verb|NULL|.

The character string \verb|fname| specifies a name of the text file to
be read in. (If the file name ends with suffix `\verb|.gz|', the file
is assumed to be compressed, in which case the routine
\verb|glp_read_mps| decompresses it ``on the fly''.)

Note that before reading data the current content of the problem object
is completely erased with the routine \verb|glp_erase_prob|.

\returns

If the operation was successful, the routine \verb|glp_read_mps|
returns zero. Otherwise, it prints an error message and returns
non-zero.

\newpage

\subsection{glp\_write\_mps --- write problem data in MPS format}

\synopsis

\begin{verbatim}
   int glp_write_mps(glp_prob *P, int fmt, const glp_mpscp *parm,
                     const char *fname);
\end{verbatim}

\description

The routine \verb|glp_write_mps| writes problem data in MPS format to
a text file. (The MPS format is described in Appendix \ref{champs},
page \pageref{champs}.)

The parameter \verb|fmt| specifies the MPS format version as follows:

\verb|GLP_MPS_DECK| --- fixed (ancient) MPS format;

\verb|GLP_MPS_FILE| --- free (modern) MPS format.

The parameter \verb|parm| is reserved for use in the future and should
be specified as \verb|NULL|.

The character string \verb|fname| specifies a name of the text file to
be written out. (If the file name ends with suffix `\verb|.gz|', the
file is assumed to be compressed, in which case the routine
\verb|glp_write_mps| performs automatic compression on writing it.)

\returns

If the operation was successful, the routine \verb|glp_write_mps|
returns zero. Otherwise, it prints an error message and returns
non-zero.

\subsection{glp\_read\_lp --- read problem data in CPLEX LP format}

\synopsis

{\tt int glp\_read\_lp(glp\_prob *P, const glp\_cpxcp *parm,
const char *fname);}

\description

The routine \verb|glp_read_lp| reads problem data in CPLEX LP format
from a text file. (The CPLEX LP format is described in Appendix
\ref{chacplex}, page \pageref{chacplex}.)

The parameter \verb|parm| is reserved for use in the future and should
be specified as \verb|NULL|.

The character string \verb|fname| specifies a name of the text file to
be read in. (If the file name ends with suffix `\verb|.gz|', the file
is assumed to be compressed, in which case the routine
\verb|glp_read_lp| decompresses it ``on the fly''.)

Note that before reading data the current content of the problem object
is completely erased with the routine \verb|glp_erase_prob|.

\returns

If the operation was successful, the routine \verb|glp_read_lp| returns
zero. Otherwise, it prints an error message and returns non-zero.

\newpage

\subsection{glp\_write\_lp --- write problem data in CPLEX LP format}

\synopsis

{\tt int glp\_write\_lp(glp\_prob *P, const glp\_cpxcp *parm,
const char *fname);}

\description

The routine \verb|glp_write_lp| writes problem data in CPLEX LP format
to a text file. (The CPLEX LP format is described in Appendix
\ref{chacplex}, page \pageref{chacplex}.)

The parameter \verb|parm| is reserved for use in the future and should
be specified as \verb|NULL|.

The character string \verb|fname| specifies a name of the text file to
be written out. (If the file name ends with suffix `\verb|.gz|', the
file is assumed to be compressed, in which case the routine
\verb|glp_write_lp| performs automatic compression on writing it.)

\returns

If the operation was successful, the routine \verb|glp_write_lp|
returns zero. Otherwise, it prints an error message and returns
non-zero.

\subsection{glp\_read\_prob --- read problem data in GLPK format}

\synopsis

\begin{verbatim}
   int glp_read_prob(glp_prob *P, int flags, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_read_prob| reads problem data in the GLPK LP/MIP
format from a text file. (For description of the GLPK LP/MIP format see
below.)

The parameter \verb|flags| is reserved for use in the future and should
be specified as zero.

The character string \verb|fname| specifies a name of the text file to
be read in. (If the file name ends with suffix `\verb|.gz|', the file
is assumed to be compressed, in which case the routine
\verb|glp_read_prob| decompresses it ``on the fly''.)

Note that before reading data the current content of the problem object
is completely erased with the routine \verb|glp_erase_prob|.

\returns

If the operation was successful, the routine \verb|glp_read_prob|
returns zero. Otherwise, it prints an error message and returns
non-zero.

%\newpage

\para{GLPK LP/MIP format}

The GLPK LP/MIP format is a DIMACS-like format.\footnote{The DIMACS
formats were developed by the Center for Discrete Mathematics and
Theoretical Computer Science (DIMACS) to facilitate exchange of problem
data. For details see: {\tt <http://dimacs.rutgers.edu/Challenges/>}. }
The file in this format is a plain ASCII text file containing lines of
several types described below. A line is terminated with the
end-of-line character. Fields in each line are separated by at least
one blank space. Each line begins with a one-character designator to
identify the line type.

\newpage

The first line of the data file must be the problem line (except
optional comment lines, which may precede the problem line). The last
line of the data file must be the end line. Other lines may follow in
arbitrary order, however, duplicate lines are not allowed.

\para{Comment lines.} Comment lines give human-readable
information about the data file and are ignored by GLPK routines.
Comment lines can appear anywhere in the data file. Each comment line
begins with the lower-case character \verb|c|.

\begin{verbatim}
   c This is an example of comment line
\end{verbatim}

\para{Problem line.} There must be exactly one problem line in the
data file. This line must appear before any other lines except comment
lines and has the following format:

\begin{verbatim}
   p CLASS DIR ROWS COLS NONZ
\end{verbatim}

The lower-case letter \verb|p| specifies that this is the problem line.

The \verb|CLASS| field defines the problem class and can contain either
the keyword \verb|lp| (that means linear programming problem) or
\verb|mip| (that means mixed integer programming problem).

The \verb|DIR| field defines the optimization direction (that is, the
objective function sense) and can contain either the keyword \verb|min|
(that means minimization) or \verb|max| (that means maximization).

The \verb|ROWS|, \verb|COLS|, and \verb|NONZ| fields contain
non-negative integer values specifying, respectively, the number of
rows (constraints), columns (variables), and non-zero constraint
coefficients in the problem instance. Note that \verb|NONZ| value does
not account objective coefficients.

\para{Row descriptors.} There must be at most one row descriptor line
in the data file for each row (constraint). This line has one of the
following formats:

\begin{verbatim}
   i ROW f
   i ROW l RHS
   i ROW u RHS
   i ROW d RHS1 RHS2
   i ROW s RHS
\end{verbatim}

The lower-case letter \verb|i| specifies that this is the row
descriptor line.

The \verb|ROW| field specifies the row ordinal number, an integer
between 1 and $m$, where $m$ is the number of rows in the problem
instance.

The next lower-case letter specifies the row type as follows:

\verb|f| --- free (unbounded) row: $-\infty<\sum a_jx_j<+\infty$;

\verb|l| --- inequality constraint of `$\geq$' type:
$\sum a_jx_j\geq b$;

\verb|u| --- inequality constraint of `$\leq$' type:
$\sum a_jx_j\leq b$;

\verb|d| --- double-sided inequality constraint:
$b_1\leq\sum a_jx_j\leq b_2$;

\verb|s| --- equality constraint: $\sum a_jx_j=b$.

The \verb|RHS| field contains a floaing-point value specifying the
row right-hand side. The \verb|RHS1| and \verb|RHS2| fields contain
floating-point values specifying, respectively, the lower and upper
right-hand sides for the double-sided row.

If for some row its descriptor line does not appear in the data file,
by default that row is assumed to be an equality constraint with zero
right-hand side.

\para{Column descriptors.} There must be at most one column descriptor
line in the data file for each column (variable). This line has one of
the following formats depending on the problem class specified in the
problem line:

\begin{tabular}{@{}l@{\hspace*{40pt}}l}
LP class & MIP class \\
\hline
\verb|j COL f|           & \verb|j COL KIND f|           \\
\verb|j COL l BND|       & \verb|j COL KIND l BND|       \\
\verb|j COL u BND|       & \verb|j COL KIND u BND|       \\
\verb|j COL d BND1 BND2| & \verb|j COL KIND d BND1 BND2| \\
\verb|j COL s BND|       & \verb|j COL KIND s BND|       \\
\end{tabular}

The lower-case letter \verb|j| specifies that this is the column
descriptor line.

The \verb|COL| field specifies the column ordinal number, an integer
between 1 and $n$, where $n$ is the number of columns in the problem
instance.

The \verb|KIND| field is used only for MIP problems and specifies the
column kind as follows:

\verb|c| --- continuous column;

\verb|i| --- integer column;

\verb|b| --- binary column (in this case all remaining fields must be
omitted).

The next lower-case letter specifies the column type as follows:

\verb|f| --- free (unbounded) column: $-\infty<x<+\infty$;

\verb|l| --- column with lower bound: $x\geq l$;

\verb|u| --- column with upper bound: $x\leq u$;

\verb|d| --- double-bounded column: $l\leq x\leq u$;

\verb|s| --- fixed column: $x=s$.

The \verb|BND| field contains a floating-point value that specifies the
column bound. The \verb|BND1| and \verb|BND2| fields contain
floating-point values specifying, respectively, the lower and upper
bounds for the double-bounded column.

If for some column its descriptor line does not appear in the file, by
default that column is assumed to be non-negative (in case of LP class)
or binary (in case of MIP class).

\para{Coefficient descriptors.} There must be exactly one coefficient
descriptor line in the data file for each non-zero objective or
constraint coefficient. This line has the following format:

\begin{verbatim}
   a ROW COL VAL
\end{verbatim}

The lower-case letter \verb|a| specifies that this is the coefficient
descriptor line.

For objective coefficients the \verb|ROW| field must contain 0. For
constraint coefficients the \verb|ROW| field specifies the row ordinal
number, an integer between 1 and $m$, where $m$ is the number of rows
in the problem instance.

The \verb|COL| field specifies the column ordinal number, an integer
between 1 and $n$, where $n$ is the number of columns in the problem
instance.

If both the \verb|ROW| and \verb|COL| fields contain 0, the line
specifies the constant term (``shift'') of the objective function
rather than objective coefficient.

The \verb|VAL| field contains a floating-point coefficient value (it is
allowed to specify zero value in this field).

The number of constraint coefficient descriptor lines must be exactly
the same as specified in the field \verb|NONZ| of the problem line.

\para{Symbolic name descriptors.} There must be at most one symbolic
name descriptor line for the problem instance, objective function, each
row (constraint), and each column (variable). This line has one of the
following formats:

\begin{verbatim}
   n p NAME
   n z NAME
   n i ROW NAME
   n j COL NAME
\end{verbatim}

The lower-case letter \verb|n| specifies that this is the symbolic name
descriptor line.

The next lower-case letter specifies which object should be assigned a
symbolic name:

\verb|p| --- problem instance;

\verb|z| --- objective function;

\verb|i| --- row (constraint);

\verb|j| --- column (variable).

The \verb|ROW| field specifies the row ordinal number, an integer
between 1 and $m$, where $m$ is the number of rows in the problem
instance.

The \verb|COL| field specifies the column ordinal number, an integer
between 1 and $n$, where $n$ is the number of columns in the problem
instance.

The \verb|NAME| field contains the symbolic name, a sequence from 1 to
255 arbitrary graphic ASCII characters, assigned to corresponding
object.

\para{End line.} There must be exactly one end line in the data file.
This line must appear last in the file and has the following format:

\begin{verbatim}
   e
\end{verbatim}

The lower-case letter \verb|e| specifies that this is the end line.
Anything that follows the end line is ignored by GLPK routines.

\newpage

\para{Example of data file in GLPK LP/MIP format}

The following example of a data file in GLPK LP/MIP format specifies
the same LP problem as in Subsection ``Example of MPS file''.

\bigskip

\begin{center}
\footnotesize\tt
\begin{tabular}{l@{\hspace*{50pt}}}
p lp min 8 7 48   \\
n p PLAN          \\
n z VALUE         \\
i 1 f             \\
n i 1 VALUE       \\
i 2 s 2000        \\
n i 2 YIELD       \\
i 3 u 60          \\
n i 3 FE          \\
i 4 u 100         \\
n i 4 CU          \\
i 5 u 40          \\
n i 5 MN          \\
i 6 u 30          \\
n i 6 MG          \\
i 7 l 1500        \\
n i 7 AL          \\
i 8 d 250 300     \\
n i 8 SI          \\
j 1 d 0 200       \\
n j 1 BIN1        \\
j 2 d 0 2500      \\
n j 2 BIN2        \\
j 3 d 400 800     \\
n j 3 BIN3        \\
j 4 d 100 700     \\
n j 4 BIN4        \\
j 5 d 0 1500      \\
n j 5 BIN5        \\
n j 6 ALUM        \\
n j 7 SILICON     \\
a 0 1 0.03        \\
a 0 2 0.08        \\
a 0 3 0.17        \\
a 0 4 0.12        \\
a 0 5 0.15        \\
a 0 6 0.21        \\
a 0 7 0.38        \\
a 1 1 0.03        \\
a 1 2 0.08        \\
a 1 3 0.17        \\
a 1 4 0.12        \\
a 1 5 0.15        \\
a 1 6 0.21        \\
\end{tabular}
\begin{tabular}{|@{\hspace*{80pt}}l}
a 1 7 0.38        \\
a 2 1 1           \\
a 2 2 1           \\
a 2 3 1           \\
a 2 4 1           \\
a 2 5 1           \\
a 2 6 1           \\
a 2 7 1           \\
a 3 1 0.15        \\
a 3 2 0.04        \\
a 3 3 0.02        \\
a 3 4 0.04        \\
a 3 5 0.02        \\
a 3 6 0.01        \\
a 3 7 0.03        \\
a 4 1 0.03        \\
a 4 2 0.05        \\
a 4 3 0.08        \\
a 4 4 0.02        \\
a 4 5 0.06        \\
a 4 6 0.01        \\
a 5 1 0.02        \\
a 5 2 0.04        \\
a 5 3 0.01        \\
a 5 4 0.02        \\
a 5 5 0.02        \\
a 6 1 0.02        \\
a 6 2 0.03        \\
a 6 5 0.01        \\
a 7 1 0.7         \\
a 7 2 0.75        \\
a 7 3 0.8         \\
a 7 4 0.75        \\
a 7 5 0.8         \\
a 7 6 0.97        \\
a 8 1 0.02        \\
a 8 2 0.06        \\
a 8 3 0.08        \\
a 8 4 0.12        \\
a 8 5 0.02        \\
a 8 6 0.01        \\
a 8 7 0.97        \\
e o f             \\
\\
\end{tabular}
\end{center}

\newpage

\subsection{glp\_write\_prob --- write problem data in GLPK format}

\synopsis

\begin{verbatim}
int glp_write_prob(glp_prob *P, int flags, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_write_prob| writes problem data in the GLPK
LP/MIP format to a text file. (For description of the GLPK LP/MIP
format see Subsection ``Read problem data in GLPK format''.)

The parameter \verb|flags| is reserved for use in the future and should
be specified as zero.

The character string \verb|fname| specifies a name of the text file to
be written out. (If the file name ends with suffix `\verb|.gz|', the
file is assumed to be compressed, in which case the routine
\verb|glp_write_prob| performs automatic compression on writing it.)

\returns

If the operation was successful, the routine \verb|glp_read_prob|
returns zero. Otherwise, it prints an error message and returns
non-zero.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newpage

\section{Routines for processing MathProg models}

\subsection{Introduction}

GLPK supports the {\it GNU MathProg modeling language}.\footnote{The
GNU MathProg modeling language is a subset of the AMPL language. For
its detailed description see the document ``Modeling Language GNU
MathProg: Language Reference'' included in the GLPK distribution.}
As a rule, models written in MathProg are solved with the GLPK LP/MIP
stand-alone solver \verb|glpsol| (see Appendix D) and do not need any
programming with API routines. However, for various reasons the user
may need to process MathProg models directly in his/her application
program, in which case he/she may use API routines described in this
section. These routines provide an interface to the {\it MathProg
translator}, a component of GLPK, which translates MathProg models into
an internal code and then interprets (executes) this code.

The processing of a model written in GNU MathProg includes several
steps, which should be performed in the following order:

%\vspace*{-8pt}

%\begin{enumerate}
\Item{1.}{\it Allocating the workspace.}
The translator allocates the workspace, an internal data structure used
on all subsequent steps.

\Item{2.}{\it Reading model section.} The translator reads model
section and, optionally, data section from a specified text file and
translates them into the internal code. If necessary, on this step data
section may be ignored.

\Item{3.}{\it Reading data section(s).} The translator reads one or
more data sections from specified text file(s) and translates them into
the internal code.

\Item{4.}{\it Generating the model.} The translator executes the
internal code to evaluate the content of the model objects such as sets,
parameters, variables, constraints, and objectives. On this step the
execution is suspended at the solve statement.

\Item{5.}{\it Building the problem object.} The translator obtains all
necessary information from the workspace and builds the standard
problem object (that is, the program object of type \verb|glp_prob|).

\Item{6.}{\it Solving the problem.} On this step the problem object
built on the previous step is passed to a solver, which solves the
problem instance and stores its solution back to the problem object.

\Item{7.}{\it Postsolving the model.} The translator copies the
solution from the problem object to the workspace and then executes the
internal code from the solve statement to the end of the model.
(If model has no solve statement, the translator does nothing on this
step.)

\Item{8.}{\it Freeing the workspace.} The translator frees all the
memory allocated to the workspace.
%\end{enumerate}

%\vspace*{-8pt}

Note that the MathProg translator performs no error correction, so if
any of steps 2 to 7 fails (due to errors in the model), the application
program should terminate processing and go to\linebreak step 8.

\newpage

\para{Example 1}

In this example the program reads model and data sections from input
file \verb|egypt.mod|\footnote{This is an example model included in
the GLPK distribution.} and writes the model to output file
\verb|egypt.mps| in free MPS format (see Appendix B). No solution is
performed.

\bigskip

\begin{small}
\begin{verbatim}
/* mplsamp1.c */

#include <stdio.h>
#include <stdlib.h>
#include <glpk.h>

int main(void)
{     glp_prob *lp;
      glp_tran *tran;
      int ret;
      lp = glp_create_prob();
      tran = glp_mpl_alloc_wksp();
      ret = glp_mpl_read_model(tran, "egypt.mod", 0);
      if (ret != 0)
      {  fprintf(stderr, "Error on translating model\n");
         goto skip;
      }
      ret = glp_mpl_generate(tran, NULL);
      if (ret != 0)
      {  fprintf(stderr, "Error on generating model\n");
         goto skip;
      }
      glp_mpl_build_prob(tran, lp);
      ret = glp_write_mps(lp, GLP_MPS_FILE, NULL, "egypt.mps");
      if (ret != 0)
         fprintf(stderr, "Error on writing MPS file\n");
skip: glp_mpl_free_wksp(tran);
      glp_delete_prob(lp);
      return 0;
}

/* eof */
\end{verbatim}
\end{small}

\newpage

\subsubsection*{Example 2}

In this example the program reads model section from file
\verb|sudoku.mod|\footnote{This is an example model which is included
in the GLPK distribution along with alternative data file
{\tt sudoku.dat}.} ignoring data section in this file, reads alternative
data section from file \verb|sudoku.dat|, solves the problem instance
and passes the solution found back to the model.

\bigskip

\begin{small}
\begin{verbatim}
/* mplsamp2.c */

#include <stdio.h>
#include <stdlib.h>
#include <glpk.h>

int main(void)
{     glp_prob *mip;
      glp_tran *tran;
      int ret;
      mip = glp_create_prob();
      tran = glp_mpl_alloc_wksp();
      ret = glp_mpl_read_model(tran, "sudoku.mod", 1);
      if (ret != 0)
      {  fprintf(stderr, "Error on translating model\n");
         goto skip;
      }
      ret = glp_mpl_read_data(tran, "sudoku.dat");
      if (ret != 0)
      {  fprintf(stderr, "Error on translating data\n");
         goto skip;
      }
      ret = glp_mpl_generate(tran, NULL);
      if (ret != 0)
      {  fprintf(stderr, "Error on generating model\n");
         goto skip;
      }
      glp_mpl_build_prob(tran, mip);
      glp_simplex(mip, NULL);
      glp_intopt(mip, NULL);
      ret = glp_mpl_postsolve(tran, mip, GLP_MIP);
      if (ret != 0)
         fprintf(stderr, "Error on postsolving model\n");
skip: glp_mpl_free_wksp(tran);
      glp_delete_prob(mip);
      return 0;
}

/* eof */
\end{verbatim}
\end{small}

\newpage

\subsection{glp\_mpl\_alloc\_wksp --- allocate the translator
workspace}

\synopsis

\begin{verbatim}
   glp_tran *glp_mpl_alloc_wksp(void);
\end{verbatim}

\description

The routine \verb|glp_mpl_alloc_wksp| allocates the MathProg translator
work\-space. (Note that multiple instances of the workspace may be
allocated, if necessary.)

\returns

The routine returns a pointer to the workspace, which should be used in
all subsequent operations.

\subsection{glp\_mpl\_init\_rand --- initialize pseudo-random number
generator}

\synopsis

\begin{verbatim}
   void glp_mpl_init_rand(glp_tran *tran, int seed);
\end{verbatim}

\description

The routine \verb|glp_mpl_init_rand| initializes a pseudo-random number
generator used by the MathProg translator, where the parameter
\verb|seed| may be any integer number.

A call to the routine \verb|glp_mpl_init_rand| should immediately
follow the call to the routine \verb|glp_mpl_alloc_wksp|. However,
using of this routine is optional. If it is not called, the effect is
the same as if it were called with \verb|seed| equal to 1.

\subsection{glp\_mpl\_read\_model --- read and translate model section}

\synopsis

\begin{verbatim}
   int glp_mpl_read_model(glp_tran *tran, const char *fname, int skip);
\end{verbatim}

\description

The routine \verb|glp_mpl_read_model| reads model section and,
optionally, data section, which may follow the model section, from a
text file, whose name is the character string \verb|fname|, performs
translation of model statements and data blocks, and stores all the
information in the workspace.

The parameter \verb|skip| is a flag. If the input file contains the
data section and this flag is non-zero, the data section is not read as
if there were no data section and a warning message is printed. This
allows reading data section(s) from other file(s).

\returns

If the operation is successful, the routine returns zero. Otherwise
the routine prints an error message and returns non-zero.

\newpage

\subsection{glp\_mpl\_read\_data --- read and translate data section}

\synopsis

\begin{verbatim}
   int glp_mpl_read_data(glp_tran *tran, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_mpl_read_data| reads data section from a text
file, whose name is the character string \verb|fname|, performs
translation of data blocks, and stores the data read in the translator
workspace. If necessary, this routine may be called more than once.

\returns

If the operation is successful, the routine returns zero. Otherwise
the routine prints an error message and returns non-zero.

\subsection{glp\_mpl\_generate --- generate the model}

\synopsis

\begin{verbatim}
   int glp_mpl_generate(glp_tran *tran, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_mpl_generate| generates the model using its
description stored in the translator workspace. This operation means
generating all variables, constraints, and objectives, executing check
and display statements, which precede the solve statement (if it is
presented).

The character string \verb|fname| specifies the name of an output text
file, to which output produced by display statements should be written.
If \verb|fname| is \verb|NULL|, the output is sent to the terminal.

\returns

If the operation is successful, the routine returns zero. Otherwise
the routine prints an error message and returns non-zero.

\vspace*{-6pt}

\subsection{glp\_mpl\_build\_prob --- build problem instance from the
model}

\synopsis

\begin{verbatim}
   void glp_mpl_build_prob(glp_tran *tran, glp_prob *P);
\end{verbatim}

\description

The routine \verb|glp_mpl_build_prob| obtains all necessary information
from the translator work\-space and stores it in the specified problem
object \verb|P|. Note that before building the current content of the
problem object is erased with the routine \verb|glp_erase_prob|.

\newpage

\subsection{glp\_mpl\_postsolve --- postsolve the model}

\synopsis

\begin{verbatim}
   int glp_mpl_postsolve(glp_tran *tran, glp_prob *P, int sol);
\end{verbatim}

\description

The routine \verb|glp_mpl_postsolve| copies the solution from the
specified problem object \verb|prob| to the translator workspace and
then executes all the remaining model statements, which follow the
solve statement.

The parameter \verb|sol| specifies which solution should be copied
from the problem object to the workspace as follows:

\verb|GLP_SOL| --- basic solution;

\verb|GLP_IPT| --- interior-point solution;

\verb|GLP_MIP| --- mixed integer solution.

\returns

If the operation is successful, the routine returns zero. Otherwise
the routine prints an error message and returns non-zero.

\subsection{glp\_mpl\_free\_wksp --- free the translator workspace}

\synopsis

\begin{verbatim}
   void glp_mpl_free_wksp(glp_tran *tran);
\end{verbatim}

\description

The routine \verb|glp_mpl_free_wksp| frees all the memory allocated to
the translator workspace. It also frees all other resources, which are
still used by the translator.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newpage

\section{Problem solution reading/writing routines}

\subsection{glp\_print\_sol --- write basic solution in printable
format}

\synopsis

\begin{verbatim}
   int glp_print_sol(glp_prob *P, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_print_sol writes| the current basic solution to
an LP problem, which is specified by the pointer \verb|P|, to a text
file, whose name is the character string \verb|fname|, in printable
format.

Information reported by the routine \verb|glp_print_sol| is intended
mainly for visual analysis.

\returns

If no errors occurred, the routine returns zero. Otherwise the routine
prints an error message and returns non-zero.

\subsection{glp\_read\_sol --- read basic solution in GLPK format}

\synopsis

\begin{verbatim}
   int glp_read_sol(glp_prob *P, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_read_sol| reads basic solution from a text file
in the GLPK format. (For description of the format see below.)

The character string \verb|fname| specifies the name of the text file
to be read in. (If the file name ends with suffix `\verb|.gz|', the
file is assumed to be compressed, in which case the routine
\verb|glp_read_sol| decompresses it "on the fly".)

\returns

If the operation was successful, the routine \verb|glp_read_sol|
returns zero. Otherwise, it prints an error message and returns
non-zero.

\para{GLPK basic solution format}

The GLPK basic solution format is a DIMACS-like format.\footnote{The
DIMACS formats were developed by the Center for Discrete Mathematics
and Theoretical Computer Science (DIMACS) to facilitate exchange of
problem data.
For details see: {\tt <http://dimacs.rutgers.edu/Challenges/>}. }
The file in this format is a plain ASCII text file containing lines of
several types described below. A line is terminated with the
end-of-line character. Fields in each line are separated by at least
one blank space. Each line begins with a one-character designator to
identify the line type.

The first line of the solution file must be the solution line (except
optional comment lines, which may precede the problem line). The last
line of the data file must be the end line. Other lines may follow in
arbitrary order, however, duplicate lines are not allowed.

\newpage

\para{Comment lines.} Comment lines give human-readable information
about the solution file and are ignored by GLPK routines. Comment lines
can appear anywhere in the data file. Each comment line begins with the
lower-case character \verb|c|.

\begin{verbatim}
   c This is an example of comment line
\end{verbatim}

\para{Solution line.} There must be exactly one solution line in the
solution file. This line must appear before any other lines except
comment lines and has the following format:

\begin{verbatim}
   s bas ROWS COLS PST DST OBJ
\end{verbatim}

The lower-case letter \verb|s| specifies that this is the solution
line.

The three-character solution designator \verb|bas| identifies the file
as containing a basic solution to the LP problem instance.

The \verb|ROWS| and \verb|COLS| fields contain non-negative integer
values that specify the number of rows (constraints) and columns
(variables), resp., in the LP problem instance.

The \verb|PST| and \verb|DST| fields contain lower-case letters that
specify the primal and dual solution status, resp., as follows:

\verb|u| --- solution is undefined;

\verb|f| --- solution is feasible;

\verb|i| --- solution is infeasible;

\verb|n| --- no feasible solution exists.

The \verb|OBJ| field contains a floating-point number that specifies
the objective function value in the basic solution.

\para{Row solution descriptors.} There must be exactly one row solution
descriptor line in the solution file for each row (constraint). This
line has the following format:

\begin{verbatim}
   i ROW ST PRIM DUAL
\end{verbatim}

The lower-case letter \verb|i| specifies that this is the row solution
descriptor line.

The \verb|ROW| field specifies the row ordinal number, an integer
between 1 and $m$, where $m$ is the number of rows in the problem
instance.

The \verb|ST| field contains one of the following lower-case letters
that specifies the row status in the basic solution:\footnote{The row
status is the status of the associated auxiliary variable.}

\verb|b| --- inactive constraint;

\verb|l| --- inequality constraint active on its lower bound;

\verb|u| --- inequality constraint active on its upper bound;

\verb|f| --- active free (unounded) row;

\verb|s| --- active equality constraint.

The \verb|PRIM| field contains a floating-point number that specifies
the row primal value (the value of the corresponding linear form).

The \verb|DUAL| field contains a floating-point number that specifies
the row dual value (the Lagrangian multiplier for active bound).

\para{Column solution descriptors.} There must be exactly one column
solution descriptor line in the solution file for each column
(variable). This line has the following format:

\begin{verbatim}
   j COL ST PRIM DUAL
\end{verbatim}

The lower-case letter \verb|j| specifies that this is the column
solution descriptor line.

The \verb|COL| field specifies the column ordinal number, an integer
between 1 and $n$, where $n$ is the number of columns in the problem
instance.

The \verb|ST| field contains one of the following lower-case letters
that specifies the column status in the basic solution:

\verb|b| --- basic variable;

\verb|l| --- non-basic variable having its lower bound active;

\verb|u| --- non-basic variable having its upper bound active;

\verb|f| --- non-basic free (unounded) variable;

\verb|s| --- non-basic fixed variable.

The \verb|PRIM| field contains a floating-point number that specifies
the column primal value.

The \verb|DUAL| field contains a floating-point number that specifies
the column dual value (the Lagrangian multiplier for active bound).

\para{End line.} There must be exactly one end line in the solution
file. This line must appear last in the file and has the following
format:

\begin{verbatim}
   e
\end{verbatim}

The lower-case letter \verb|e| specifies that this is the end line.
Anything that follows the end line is ignored by GLPK routines.

\para{Example of solution file in GLPK basic solution format}

The following example of a solution file in GLPK basic solution format
specifies the optimal basic solution to the LP problem instance from
Subsection ``Example of MPS file''.

\bigskip

\begin{center}
\footnotesize\tt
\begin{tabular}{l@{\hspace*{50pt}}}
s bas 7 7 f f 296.216606498195   \\
i 1 s 2000 -0.0135956678700369   \\
i 2 u 60 -2.56823104693141       \\
i 3 b 83.9675090252707 0         \\
i 4 u 40 -0.544404332129962      \\
i 5 b 19.9602888086643 0         \\
i 6 l 1500 0.251985559566788     \\
i 7 l 250 0.48519855595668       \\
\end{tabular}
\begin{tabular}{|@{\hspace*{50pt}}l}
j 1 l 0 0.253624548736462        \\
j 2 b 665.342960288809 0         \\
j 3 b 490.252707581226 0         \\
j 4 b 424.187725631769 0         \\
j 5 l 0 0.0145559566787004       \\
j 6 b 299.638989169676 0         \\
j 7 b 120.57761732852 0          \\
e o f                            \\
\end{tabular}
\end{center}

\newpage

\subsection{glp\_write\_sol --- write basic solution in GLPK format}

\synopsis

\begin{verbatim}
   int glp_write_sol(glp_prob *P, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_write_sol| writes the current basic solution to
a text file in the GLPK format. (For description of the GLPK basic
solution format see Subsection ``Read basic solution in GLPK format.'')

The character string \verb|fname| specifies the name of the text file
to be written. (If the file name ends with suffix `\verb|.gz|', the
routine \verb|glp_write_sol| compresses it "on the fly".)

\returns

If the operation was successful, the routine \verb|glp_write_sol|
returns zero. Otherwise, it prints an error message and returns
non-zero.

\subsection{glp\_print\_ipt --- write interior-point solution in
printable format}

\synopsis

\begin{verbatim}
   int glp_print_ipt(glp_prob *P, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_print_ipt| writes the current interior point
solution to an LP problem, which the parameter \verb|P| points to, to
a text file, whose name is the character string \verb|fname|, in
printable format.

Information reported by the routine \verb|glp_print_ipt| is intended
mainly for visual analysis.

\returns

If no errors occurred, the routine returns zero. Otherwise the routine
prints an error message and returns non-zero.

\subsection{glp\_read\_ipt --- read interior-point solution in GLPK
format}

\synopsis

\begin{verbatim}
   int glp_read_ipt(glp_prob *P, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_read_ipt| reads interior-point solution from
a text file in the GLPK format. (For description of the format see
below.)

The character string \verb|fname| specifies the name of the text file
to be read in. (If the file name ends with suffix `\verb|.gz|', the
file is assumed to be compressed, in which case the routine
\verb|glp_read_ipt| decompresses it "on the fly".)

%\newpage

\returns

If the operation was successful, the routine \verb|glp_read_ipt|
returns zero. Otherwise, it prints an error message and returns
non-zero.

\para{GLPK interior-point solution format}

The GLPK interior-point solution format is a DIMACS-like
format.\footnote{The DIMACS formats were developed by the Center for
Discrete Mathematics and Theoretical Computer Science (DIMACS) to
facilitate exchange of problem data. For details see:
{\tt <http://dimacs.rutgers.edu/Challenges/>}. }
The file in this format is a plain ASCII text file containing lines of
several types described below. A line is terminated with the
end-of-line character. Fields in each line are separated by at least
one blank space. Each line begins with a one-character designator to
identify the line type.

The first line of the solution file must be the solution line (except
optional comment lines, which may precede the problem line). The last
line of the data file must be the end line. Other lines may follow in
arbitrary order, however, duplicate lines are not allowed.

\para{Comment lines.} Comment lines give human-readable information
about the solution file and are ignored by GLPK routines. Comment lines
can appear anywhere in the data file. Each comment line begins with the
lower-case character \verb|c|.

\begin{verbatim}
   c This is an example of comment line
\end{verbatim}

\para{Solution line.} There must be exactly one solution line in the
solution file. This line must appear before any other lines except
comment lines and has the following format:

\begin{verbatim}
   s ipt ROWS COLS SST OBJ
\end{verbatim}

The lower-case letter \verb|s| specifies that this is the solution
line.

The three-character solution designator \verb|ipt| identifies the file
as containing an interior-point solution to the LP problem instance.

The \verb|ROWS| and \verb|COLS| fields contain non-negative integer
values that specify the number of rows (constraints) and columns
(variables), resp., in the LP problem instance.

The \verb|SST| field contains one of the following lower-case letters
that specifies the solution status:

\verb|o| --- solution is optimal;

\verb|i| --- solution is infeasible;

\verb|n| --- no feasible solution exists;

\verb|u| --- solution is undefined.

The \verb|OBJ| field contains a floating-point number that specifies
the objective function value in the interior-point solution.

\para{Row solution descriptors.} There must be exactly one row solution
descriptor line in the solution file for each row (constraint). This
line has the following format:

\begin{verbatim}
   i ROW PRIM DUAL
\end{verbatim}

The lower-case letter \verb|i| specifies that this is the row solution
descriptor line.

%\newpage

The \verb|ROW| field specifies the row ordinal number, an integer
between 1 and $m$, where $m$ is the number of rows in the problem
instance.

The \verb|PRIM| field contains a floating-point number that specifies
the row primal value (the value of the corresponding linear form).

The \verb|DUAL| field contains a floating-point number that specifies
the row dual value (the Lagrangian multiplier for active bound).

\para{Column solution descriptors.} There must be exactly one column
solution descriptor line in the solution file for each column
(variable). This line has the following format:

\begin{verbatim}
   j COL PRIM DUAL
\end{verbatim}

The lower-case letter \verb|j| specifies that this is the column
solution descriptor line.

The \verb|COL| field specifies the column ordinal number, an integer
between 1 and $n$, where $n$ is the number of columns in the problem
instance.

The \verb|PRIM| field contains a floating-point number that specifies
the column primal value.

The \verb|DUAL| field contains a floating-point number that specifies
the column dual value (the Lagrangian multiplier for active bound).

\para{End line.} There must be exactly one end line in the solution
file. This line must appear last in the file and has the following
format:

\begin{verbatim}
   e
\end{verbatim}

The lower-case letter \verb|e| specifies that this is the end line.
Anything that follows the end line is ignored by GLPK routines.

\para{Example of solution file in GLPK interior-point solution format}

The following example of a solution file in GLPK interior-point
solution format specifies the optimal interior-point solution to the LP
problem instance from Subsection ``Example of MPS file''.

\bigskip

\begin{center}
\footnotesize\tt
\begin{tabular}{l@{\hspace*{10pt}}}
s ipt 7 7 o 296.216606851403                 \\
i 1 2000.00000290369 -0.0135956757623443     \\
i 2 60.0000001302903 -2.568231024875         \\
i 3 83.9675094251819 -8.85591445202383e-10   \\
i 4 39.9999999985064 -0.544404310443766      \\
i 5 19.9602886941262 -2.24817803513554e-09   \\
i 6 1500.00000199013 0.251985567257828       \\
i 7 250.000000244896 0.48519856304979        \\
\end{tabular}
\begin{tabular}{|@{\hspace*{10pt}}l}
j 1 3.3482079213784e-07 0.253624547432525    \\
j 2 665.342955760768 6.04613825351601e-11    \\
j 3 490.25271366802 5.8488360240978e-10      \\
j 4 424.187729774275 -2.54144550490434e-11   \\
j 5 1.46067738492801e-06 0.0145559574770786  \\
j 6 299.638985053112 1.49359074902927e-10    \\
j 7 120.577616852015 3.50297708781545e-10    \\
e o f
\end{tabular}
\end{center}

\subsection{glp\_write\_ipt --- write interior-point solution in GLPK
format}

\synopsis

\begin{verbatim}
   int glp_write_ipt(glp_prob *P, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_write_ipt| writes the current interior-point
solution to a text file in the GLPK format. (For description of the
GLPK interior-point solution format see Subsection ``Read
interior-point solution in GLPK format.'')

The character string \verb|fname| specifies the name of the text file
to be written. (If the file name ends with suffix `\verb|.gz|', the
routine \verb|glp_write_ipt| compresses it "on the fly".)

\returns

If the operation was successful, the routine \verb|glp_write_ipt|
returns zero. Otherwise, it prints an error message and returns
non-zero.

\subsection{glp\_print\_mip --- write MIP solution in printable format}

\synopsis

\begin{verbatim}
   int glp_print_mip(glp_prob *P, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_print_mip| writes the current solution to a MIP
problem, which is specified by the pointer \verb|P|, to a text file,
whose name is the character string \verb|fname|, in printable format.

Information reported by the routine \verb|glp_print_mip| is intended
mainly for visual analysis.

\returns

If no errors occurred, the routine returns zero. Otherwise the routine
prints an error message and returns non-zero.

\subsection{glp\_read\_mip --- read MIP solution in GLPK format}

\synopsis

\begin{verbatim}
   int glp_read_mip(glp_prob *P, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_read_mip| reads MIP solution from a text file in
the GLPK format. (For description of the format see below.)

The character string \verb|fname| specifies the name of the text file
to be read in. (If the file name ends with suffix `\verb|.gz|', the
file is assumed to be compressed, in which case the routine
\verb|glp_read_mip| decompresses it "on the fly".)

\returns

If the operation was successful, the routine \verb|glp_read_mip|
returns zero. Otherwise, it prints an error message and returns
non-zero.

\para{GLPK MIP solution format}

The GLPK MIP solution format is a DIMACS-like format.\footnote{The
DIMACS formats were developed by the Center for Discrete Mathematics
and Theoretical Computer Science (DIMACS) to facilitate exchange of
problem data. For details see:
{\tt <http://dimacs.rutgers.edu/Challenges/>}. }
The file in this format is a plain ASCII text file containing lines of
several types described below. A line is terminated with the
end-of-line character. Fields in each line are separated by at least
one blank space. Each line begins with a one-character designator to
identify the line type.

The first line of the solution file must be the solution line (except
optional comment lines, which may precede the problem line). The last
line of the data file must be the end line. Other lines may follow in
arbitrary order, however, duplicate lines are not allowed.

\para{Comment lines.} Comment lines give human-readable information
about the solution file and are ignored by GLPK routines. Comment lines
can appear anywhere in the data file. Each comment line begins with the
lower-case character \verb|c|.

\begin{verbatim}
   c This is an example of comment line
\end{verbatim}

\para{Solution line.} There must be exactly one solution line in the
solution file. This line must appear before any other lines except
comment lines and has the following format:

\begin{verbatim}
   s mip ROWS COLS SST OBJ
\end{verbatim}

The lower-case letter \verb|s| specifies that this is the solution
line.

The three-character solution designator \verb|mip| identifies the file
as containing a solution to the MIP problem instance.

The \verb|ROWS| and \verb|COLS| fields contain non-negative integer
values that specify the number of rows (constraints) and columns
(variables), resp., in the LP problem instance.

The \verb|SST| field contains one of the following lower-case letters
that specifies the solution status:

\verb|o| --- solution is integer optimal;

\verb|f| --- solution is integer feasible (non-optimal);

\verb|n| --- no integer feasible solution exists;

\verb|u| --- solution is undefined.

The \verb|OBJ| field contains a floating-point number that specifies
the objective function value in the MIP solution.

\para{Row solution descriptors.} There must be exactly one row solution
descriptor line in the solution file for each row (constraint). This
line has the following format:

\begin{verbatim}
   i ROW VAL
\end{verbatim}

The lower-case letter \verb|i| specifies that this is the row solution
descriptor line.

The \verb|ROW| field specifies the row ordinal number, an integer
between 1 and $m$, where $m$ is the number of rows in the problem
instance.

The \verb|VAL| field contains a floating-point number that specifies
the row value (the value of the corresponding linear form).

\para{Column solution descriptors.} There must be exactly one column
solution descriptor line in the solution file for each column
(variable). This line has the following format:

\begin{verbatim}
   j COL VAL
\end{verbatim}

The lower-case letter \verb|j| specifies that this is the column
solution descriptor line.

The \verb|COL| field specifies the column ordinal number, an integer
between 1 and $n$, where $n$ is the number of columns in the problem
instance.

The \verb|VAL| field contains a floating-point number that specifies
the column value.

\para{End line.} There must be exactly one end line in the solution
file. This line must appear last in the file and has the following
format:

\begin{verbatim}
   e
\end{verbatim}

The lower-case letter \verb|e| specifies that this is the end line.
Anything that follows the end line is ignored by GLPK routines.

\para{Example of solution file in GLPK MIP solution format}

The following example of a solution file in GLPK MIP solution format
specifies an optimal solution to a MIP problem instance.

\bigskip

\begin{center}
\footnotesize\tt
\begin{tabular}{l@{\hspace*{50pt}}}
s mip 8 8 o 1201500 \\
i 1 60      \\
i 2 8400    \\
i 3 -1200   \\
i 4 0       \\
i 5 9000    \\
i 6 -600    \\
i 7 0       \\
i 8 8000    \\
\end{tabular}
\begin{tabular}{|@{\hspace*{80pt}}l}
j 1 60      \\
j 2 6       \\
j 3 0       \\
j 4 60      \\
j 5 6       \\
j 6 600     \\
j 7 60      \\
j 8 16      \\
e o f       \\
\end{tabular}
\end{center}

\subsection{glp\_write\_mip --- write MIP solution in GLPK format}

\synopsis

\begin{verbatim}
   int glp_write_mip(glp_prob *P, const char *fname);
\end{verbatim}

\description

The routine \verb|glp_write_mip| writes the current MIP solution to
a text file in the GLPK format. (For description of the GLPK MIP
solution format see Subsection ``Read MIP solution in GLPK format.'')

The character string \verb|fname| specifies the name of the text file
to be written. (If the file name ends with suffix `\verb|.gz|', the
routine \verb|glp_write_mip| compresses it "on the fly".)

\returns

If the operation was successful, the routine \verb|glp_write_mip|
returns zero. Otherwise, it prints an error message and returns
non-zero.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newpage

\section{Post-optimal analysis routines}

\subsection{glp\_print\_ranges --- print sensitivity analysis report}

\synopsis

{\tt int glp\_print\_ranges(glp\_prob *P, int len, const int list[],
int flags,\\
\hspace*{134pt}const char *fname);}

\description

The routine \verb|glp_print_ranges| performs sensitivity analysis of
current optimal basic solution and writes the analysis report in
human-readable format to a text file, whose name is the character
string {\it fname}. (Detailed description of the report structure is
given below.)

The parameter {\it len} specifies the length of the row/column list.

The array {\it list} specifies ordinal number of rows and columns to be
analyzed. The ordinal numbers should be passed in locations
{\it list}[1], {\it list}[2], \dots, {\it list}[{\it len}]. Ordinal
numbers from 1 to $m$ refer to rows, and ordinal numbers from $m+1$ to
$m+n$ refer to columns, where $m$ and $n$ are, resp., the total number
of rows and columns in the problem object. Rows and columns appear in
the analysis report in the same order as they follow in the array list.

It is allowed to specify $len=0$, in which case the array {\it list} is
not used (so it can be specified as \verb|NULL|), and the routine
performs analysis for all rows and columns of the problem object.

The parameter {\it flags} is reserved for use in the future and must be
specified as zero.

On entry to the routine \verb|glp_print_ranges| the current basic
solution must be optimal and the basis factorization must exist.
The application program can check that with the routine
\verb|glp_bf_exists|, and if the factorization does
not exist, compute it with the routine \verb|glp_factorize|. Note that
if the LP preprocessor is not used, on normal exit from the simplex
solver routine \verb|glp_simplex| the basis factorization always exists.

\returns

If the operation was successful, the routine \verb|glp_print_ranges|
returns zero. Otherwise, it prints an error message and returns
non-zero.

\para{Analysis report example}

An example of the sensitivity analysis report is shown on the next two
pages. This example corresponds to the example of LP problem described
in Subsection ``Example of MPS file''.

\para{Structure of the analysis report}

For each row and column specified in the array {\it list} the routine
prints two lines containing generic information and analysis
information, which depends on the status of corresponding row or column.

Note that analysis of a row is analysis of its auxiliary variable,
which is equal to the row linear form $\sum a_jx_j$, and analysis of
a column is analysis of corresponding structural variable. Therefore,
formally, on performing the sensitivity analysis there is no difference
between rows and columns.

\newpage

\begin{landscape}
\begin{footnotesize}
\begin{verbatim}
         GLPK 4.42 - SENSITIVITY ANALYSIS REPORT                                                                         Page   1

         Problem:    PLAN
         Objective:  VALUE = 296.2166065 (MINimum)

            No. Row name     St      Activity         Slack   Lower bound       Activity      Obj coef  Obj value at Limiting
                                                   Marginal   Upper bound          range         range   break point variable
         ------ ------------ -- ------------- ------------- -------------  ------------- ------------- ------------- ------------
              1 VALUE        BS     296.21661    -296.21661          -Inf      299.25255      -1.00000        .      MN
                                                     .               +Inf      296.21661          +Inf          +Inf

              2 YIELD        NS    2000.00000        .         2000.00000     1995.06864          -Inf     296.28365 BIN3
                                                    -.01360    2000.00000     2014.03479          +Inf     296.02579 CU

              3 FE           NU      60.00000        .               -Inf       55.89016          -Inf     306.77162 BIN4
                                                   -2.56823      60.00000       62.69978       2.56823     289.28294 BIN3

              4 CU           BS      83.96751      16.03249          -Inf       93.88467       -.30613     270.51157 MN
                                                     .          100.00000       79.98213        .21474     314.24798 BIN5

              5 MN           NU      40.00000        .               -Inf       34.42336          -Inf     299.25255 BIN4
                                                    -.54440      40.00000       41.68691        .54440     295.29825 BIN3

              6 MG           BS      19.96029      10.03971          -Inf       24.74427      -1.79618     260.36433 BIN1
                                                     .           30.00000        9.40292        .28757     301.95652 MN

              7 AL           NL    1500.00000        .         1500.00000     1485.78425       -.25199     292.63444 CU
                                                     .25199          +Inf     1504.92126          +Inf     297.45669 BIN3

              8 SI           NL     250.00000      50.00000     250.00000      235.32871       -.48520     289.09812 CU
                                                     .48520     300.00000      255.06073          +Inf     298.67206 BIN3
\end{verbatim}
\end{footnotesize}
\end{landscape}

\newpage

\begin{landscape}
\begin{footnotesize}
\begin{verbatim}
         GLPK 4.42 - SENSITIVITY ANALYSIS REPORT                                                                         Page   2

         Problem:    PLAN
         Objective:  VALUE = 296.2166065 (MINimum)

            No. Column name  St      Activity      Obj coef   Lower bound       Activity      Obj coef  Obj value at Limiting
                                                   Marginal   Upper bound          range         range   break point variable
         ------ ------------ -- ------------- ------------- -------------  ------------- ------------- ------------- ------------
              1 BIN1         NL        .             .03000        .           -28.82475       -.22362     288.90594 BIN4
                                                     .25362     200.00000       33.88040          +Inf     304.80951 BIN4

              2 BIN2         BS     665.34296        .08000        .           802.22222        .01722     254.44822 BIN1
                                                     .         2500.00000      313.43066        .08863     301.95652 MN

              3 BIN3         BS     490.25271        .17000     400.00000      788.61314        .15982     291.22807 MN
                                                     .          800.00000     -347.42857        .17948     300.86548 BIN5

              4 BIN4         BS     424.18773        .12000     100.00000      710.52632        .10899     291.54745 MN
                                                     .          700.00000     -256.15524        .14651     307.46010 BIN1

              5 BIN5         NL        .             .15000        .          -201.78739        .13544     293.27940 BIN3
                                                     .01456    1500.00000       58.79586          +Inf     297.07244 BIN3

              6 ALUM         BS     299.63899        .21000        .           358.26772        .18885     289.87879 AL
                                                     .               +Inf      112.40876        .22622     301.07527 MN

              7 SILICON      BS     120.57762        .38000        .           124.27093        .14828     268.27586 BIN5
                                                     .               +Inf       85.54745        .46667     306.66667 MN

         End of report
\end{verbatim}
\end{footnotesize}
\end{landscape}

\newpage

\noindent
{\it Generic information}

{\tt No.} is the row or column ordinal number in the problem object.
Rows are numbered from 1 to $m$, and columns are numbered from 1 to $n$,
where $m$ and $n$ are, resp., the total number of rows and columns in
the problem object.

{\tt Row name} is the symbolic name assigned to the row. If the row has
no name assigned, this field contains blanks.

{\tt Column name} is the symbolic name assigned to the column. If the
column has no name assigned, this field contains blanks.

{\tt St} is the status of the row or column in the optimal solution:

{\tt BS} --- non-active constraint (row), basic column;

{\tt NL} --- inequality constraint having its lower right-hand side
active (row), non-basic column having its lower bound active;

{\tt NU} --- inequality constraint having its upper right-hand side
active (row), non-basic column having its upper bound active;

{\tt NS} --- active equality constraint (row), non-basic fixed column.

{\tt NF} --- active free row, non-basic free (unbounded) column. (This
case means that the optimal solution is dual degenerate.)

{\tt Activity} is the (primal) value of the auxiliary variable (row) or
structural variable (column) in the optimal solution.

{\tt Slack} is the (primal) value of the row slack variable.

{\tt Obj coef} is the objective coefficient of the column (structural
variable).

{\tt Marginal} is the reduced cost (dual activity) of the auxiliary
variable (row) or structural variable (column).

{\tt Lower bound} is the lower right-hand side (row) or lower bound
(column). If the row or column has no lower bound, this field contains
{\tt -Inf}.

{\tt Upper bound} is the upper right-hand side (row) or upper bound
(column). If the row or column has no upper bound, this field contains
{\tt +Inf}.

\noindent
{\it Sensitivity analysis of active bounds}

The sensitivity analysis of active bounds is performed only for rows,
which are active constraints, and only for non-basic columns, because
inactive constraints and basic columns have no active bounds.

For every auxiliary (row) or structural (column) non-basic variable the
routine starts changing its active bound in both direction. The first
of the two lines in the report corresponds to decreasing, and the
second line corresponds to increasing of the active bound. Since the
variable being analyzed is non-basic, its activity, which is equal to
its active bound, also starts changing. This changing leads to changing
of basic (auxiliary and structural) variables, which depend on the
non-basic variable. The current basis remains primal feasible and
therefore optimal while values of all basic variables are primal
feasible, i.e. are within their bounds. Therefore, if some basic
variable called the {\it limiting variable} reaches its (lower or
upper) bound first, before any other basic variables, it thereby limits
further changing of the non-basic variable, because otherwise the
current basis would become primal infeasible. The point, at which this
happens, is called the {\it break point}. Note that there are two break
points: the lower break point, which corresponds to decreasing of the
non-basic variable, and the upper break point, which corresponds to
increasing of the non-basic variable.

In the analysis report values of the non-basic variable (i.e. of its
active bound) being analyzed at both lower and upper break points are
printed in the field `{\tt Activity range}'. Corresponding values of
the objective function are printed in the field `{\tt Obj value at
break point}', and symbolic names of corresponding limiting basic
variables are printed in the field `{\tt Limiting variable}'.
If the active bound can decrease or/and increase unlimitedly, the field
`{\tt Activity range}' contains {\tt -Inf} or/and {\tt +Inf}, resp.

For example (see the example report above), row SI is a double-sided
constraint, which is active on its lower bound (right-hand side), and
its activity in the optimal solution being equal to the lower bound is
250. The activity range for this row is $[235.32871,255.06073]$. This
means that the basis remains optimal while the lower bound is
increasing up to 255.06073, and further increasing is limited by
(structural) variable BIN3. If the lower bound reaches this upper break
point, the objective value becomes equal to 298.67206.

Note that if the basis does not change, the objective function depends
on the non-basic variable linearly, and the per-unit change of the
objective function is the reduced cost (marginal value) of the
non-basic variable.

\noindent
{\it Sensitivity analysis of objective coefficients at non-basic
variables}

The sensitivity analysis of the objective coefficient at a non-basic
variable is quite simple, because in this case change in the objective
coefficient leads to equivalent change in the reduced cost (marginal
value).

For every auxiliary (row) or structural (column) non-basic variable the
routine starts changing its objective coefficient in both direction.
(Note that auxiliary variables are not included in the objective
function and therefore always have zero objective coefficients.) The
first of the two lines in the report corresponds to decreasing, and the
second line corresponds to increasing of the objective coefficient.
This changing leads to changing of the reduced cost of the non-basic
variable to be analyzed and does affect reduced costs of all other
non-basic variables. The current basis remains dual feasible and
therefore optimal while the reduced cost keeps its sign. Therefore, if
the reduced cost reaches zero, it limits further changing of the
objective coefficient (if only the non-basic variable is non-fixed).

In the analysis report minimal and maximal values of the objective
coefficient, on which the basis remains optimal, are printed in the
field `\verb|Obj coef range|'. If the objective coefficient can
decrease or/and increase unlimitedly, this field contains {\tt -Inf}
or/and {\tt +Inf}, resp.

For example (see the example report above), column BIN5 is non-basic
having its lower bound active. Its objective coefficient is 0.15, and
reduced cost in the optimal solution 0.01456. The column lower bound
remains active while the column reduced cost remains non-negative,
thus, minimal value of the objective coefficient, on which the current
basis still remains optimal, is $0.15-0.01456=0.13644$, that is
indicated in the field `\verb|Obj coef range|'.

%\newpage

%{\parskip=0pt
\noindent
{\it Sensitivity analysis of objective coefficients at basic variables}

%\medskip

To perform sensitivity analysis for every auxiliary (row) or structural
(column) variable the routine starts changing its objective coefficient
in both direction. (Note that auxiliary variables are not included in
the objective function and therefore always have zero objective
coefficients.) The first of the two lines in the report corresponds to
decreasing, and the second line corresponds to increasing of the
objective coefficient. This changing leads to changing of reduced costs
of non-basic variables. The current basis remains dual feasible and
therefore optimal while reduced costs of all non-basic variables
(except fixed variables) keep their signs. Therefore, if the reduced
cost of some non-basic non-fixed variable called the {\it limiting
variable} reaches zero first, before reduced cost of any other
non-basic non-fixed variable, it thereby limits further changing of the
objective coefficient, because otherwise the current basis would become
dual infeasible (non-optimal). The point, at which this happens, is
called the {\it break point}. Note that there are two break points: the
lower break point, which corresponds to decreasing of the objective
coefficient, and the upper break point, which corresponds to increasing
of the objective coefficient. Let the objective coefficient reach its
limit value and continue changing a bit further in the same direction
that makes the current basis dual infeasible (non-optimal). Then the
reduced cost of the non-basic limiting variable becomes ``a bit'' dual
infeasible that forces the limiting variable to enter the basis
replacing there some basic variable, which leaves the basis to keep its
primal feasibility. It should be understood that if we change the
current basis in this way exactly at the break point, both the current
and adjacent bases will be optimal with the same objective value,
because at the break point the limiting variable has zero reduced cost.
On the other hand, in the adjacent basis the value of the limiting
variable changes, because there it becomes basic, that leads to
changing of the value of the basic variable being analyzed. Note that
on determining the adjacent basis the bounds of the analyzed basic
variable are ignored as if it were a free (unbounded) variable, so it
cannot leave the current basis.

In the analysis report lower and upper limits of the objective
coefficient at the basic variable being analyzed, when the basis
remains optimal, are printed in the field `{\tt Obj coef range}'.
Corresponding values of the objective function at both lower and upper
break points are printed in the field `{\tt Obj value at break point}',
symbolic names of corresponding non-basic limiting variables are
printed in the field `{\tt Limiting variable}', and values of the basic
variable, which it would take on in the adjacent bases (as was
explained above) are printed in the field `{\tt Activity range}'.
If the objective coefficient can increase or/and decrease unlimitedly,
the field `{\tt Obj coef range}' contains {\tt -Inf} and/or {\tt +Inf},
resp. It also may happen that no dual feasible adjacent basis exists
(i.e. on entering the basis the limiting variable can increase or
decrease unlimitedly), in which case the field `{\tt Activity range}'
contains {\tt -Inf} and/or {\tt +Inf}.

For example (see the example report above), structural variable
(column) BIN3 is basic, its optimal value is 490.25271, and its
objective coefficient is 0.17. The objective coefficient range for this
column is $[0.15982,0.17948]$. This means that the basis remains
optimal while the objective coefficient is decreasing down to 0.15982,
and further decreasing is limited by (auxiliary) variable MN. If we
make the objective coefficient a bit less than 0.15982, the limiting
variable MN will enter the basis, and in that adjacent basis the
structural variable BIN3 will take on new optimal value 788.61314. At
the lower break point, where the objective coefficient is exactly
0.15982, the objective function takes on the value 291.22807 in both
the current and adjacent bases.

Note that if the basis does not change, the objective function depends
on the objective coefficient at the basic variable linearly, and the
per-unit change of the objective function is the value of the basic
variable.
%}

%* eof *%