\section{\dylp Debugging Features}
\label{sec:DylpDebugging}

\dylp incorporates two types of debugging features: a controllable printing
facility and paranoid checks.
The printing facility is enabled when the symbol \pgmid{NDEBUG}
is not defined at compile time, and is intended to allow the generation of
log information at whatever level of detail is desired by the user.
The paranoid checks are enabled when the symbol \pgmid{PARANOIA} is defined
at compile time and are intended to provide significant (and expensive)
cross-checks during code development.

\subsection{Printing}

The amount of output generated by \dylp can be varied from next to nothing
to a level of detail intended only for detailed debugging.
The paragraphs which follow briefly outline the capabilities; for specific
output at a given print level, please refer to the file \coderef{dylp.h}{}.

\begin{codedoc}
  \item\varhdr{basis}
  Prints information related to management of the basis, including adjustments
  to suppress numerical instability and recover from singularity.

  \item\varhdr{conmgmt}
  Prints information on the management of constraints, including activation and
  deactivation, changes to primal and dual variables, and (at the highest level)
  a running commentary on all constraint and variable additions, deletions, and
  motions attributable to activation and deactivation of constraints.

  \item\varhdr{crash}
  Prints information regarding the generation of the initial basis,
  including factoring, the initial set of basic variables, and their values.
  For a cold start, information on the selection of the basic variables can be
  printed.

  \item\varhdr{degen}
  Prints information about degenerate pivots and restricted
  subproblem formation to deal with degeneracy.

  \item\varhdr{dual}
  Prints information about the execution of the dual simplex, with capabilities
  similar to \pgmid{phase1}.

  \item\varhdr{major}
  Tracks the major state transitions of the dynamic simplex algorithm
  as \dylp solves an LP.

  \item\varhdr{phase1}
  Prints information about the execution of phase I of the primal simplex.
  At the low end, messages are printed for extraordinary events ---
  unboundedness, serious pivoting problems, \etc
  At a medium level, a one line message is printed summarising each pivot, as
  well as messages about routine but infrequent events --- refactoring, accuracy
  checks, and various minor problems.
  At the highest level, all primal and dual variables are printed as they are
  recalculated for each pivot, along with detailed information about reduction
  of infeasibility and changes to the phase I objective function.
  This is \textit{an enormous amount} of output for large problems. 

  \item\varhdr{phase2}
  Prints information about the execution of phase II of the primal simplex,
  with capabilities similar to \pgmid{phase1}.

  \item\varhdr{pivoting}
  Prints information on the evaluation of candidates for the leaving primal
  or entering dual variable and details of the pivot column or row.
  At least one line per pivot; at the highest level, produces
  \textit{a lot} of output.

  \item\varhdr{pivreject}
  Prints information on the operation of \dylp's pivot rejection mechanism.

  \item\varhdr{pricing}
  Prints information regarding the pricing of candidates for the entering
  primal or leaving dual variable.
  At any level above 1 you'll get \textit{many} lines of output per pivot;
  that's \textit{an enormous amount} of output for large problems.

  \item\varhdr{scaling}
  Prints information regarding numerical scaling of the constraint system.

  \item\varhdr{setup}
  Prints information regarding the loading and initialisation of an LP problem,
  including the constraints and variables which are activated and the angle of
  inequalities to the objective function.

  \item\varhdr{varmgmt}
  Prints information on the activation and deactivation of variables, much as
  \pgmid{conmgmt}.
\end{codedoc}

\subsection{Paranoia}

Because it is intended as a development code, \dylp incorporates a large number
of sanity checks, enabled by defining the conditional compilation symbol
\pgmid{PARANOIA}.
Many of these tests are cheap and simple --- checks for null parameters,
sensible constraint and variable counts, proper major phase, and range checks
on indices.
Others are more elaborate and expensive.

There are two dedicated subroutines which are used at several points to check
the integrity of the current simplex point (basis, status, and primal
variable values) and the constraint system:
\begin{itemize}
\item
\pgmid{dy_chkstatus} implements extensive checks to make
sure that the status and value of a primal variable agree across multiple
data structures and are appropriate for the current major phase.

\item
\pgmid{dy_chkdysys} implements extensive checks to ensure that the
active constraint system and associated data structures are correct and
consistent.
\end{itemize}

There is another set of checks which track the numerical accuracy of
calculations by performing an independent calculation of a quantity.
These are of little use unless there is some reason to doubt the correctness
of the calculation, hence the separate conditional compilation symbols.
\begin{itemize}
  \item
  Checks on the accuracy of the calculations to produce unscaled rows of the
  basis inverse are controlled by the symbol \pgmid{CHECK_UNSCALED_BETAI}.

  \item
  Checks on the accuracy of iterative updating for PSE column norms and
  DSE row norms are controlled by the conditional compilation symbols
  \pgmid{CHECK_PSE_UPDATES} and \pgmid{CHECK_DSE_UPDATES}.
  These checks calculate the norms directly for comparison with
  the updated values, and the computational expense is
  unacceptable unless there is specific reason to suspect an error.
\end{itemize}

