• The core classes define the basic mathematical objects useful for specifying and solving optimization problems. These classes are abstract.
• The algorithm classes are concrete classes that implement algorithms for solving various optimization and linear algebra problems. The emphasis is on large-scale problems.
• The tool classes are concrete classes that build up certain standard constructs out of objects derived from the abstract base classes.
• The concrete classes are ``standard classes'' derived from the core classes. These include, for example, vector and matrix classes.

The heart of HCL is the collection of core classes. These define the properties of vector spaces, vectors, linear operators, real-valued functions, and nonlinear operators.

Algorithms currently available and planned include methods for solving unconstrained minimization problems (limited memory BFGS and the Steihaug-Toint method), equality constrained minimization problems (the augmented Lagrangian method---under development), and general nonlinear programming problems (also under development). The algorithms are written using only the properties of the objects defined by the core classes. This means that no particular data structures are mandated, and therefore the algorithms can be used for arbitrarily complex applications.

The tool classes implement many common abstract constructs arising in the solution of optimization problems. For example, many inverse and design problems have natural (or at least simple) formulations as nonlinear least squares problems. The user of HCL will have implemented the (nonlinear) operator A appearing in the problem as a subclass of HCL_OpDerivAdj, giving access to the operator as well as to its derivative and to the adjoint of its derivative. A data vector d, realized as an instance of a subclass of HCL_Vector, will also be at hand. The tool class HCL_LeastSquaresFcnlGrad provides access to the nonlinear least squares objective function

 HCL_LeastSquaresFcnlGrad_d J(A,d); 

HCL tools include many similar utilities, which implement quadratic forms, linear combinations of functions and operators, compositions and tensor products of operators, product vector spaces, and other common constructs, all requiring minimal additional user code.

The concrete classes implement objects that we expect many users to need, for example, the simplest kind of vector (a Euclidean vector represented by its components stored in-core) and some matrix classes. The in-core vector class HCL_RnVector defines all of the standard vector operations, and defines in addition most of the usual ``Matlab'' array operations. The matrix classes are experimental in the current release. We plan at some stage to replace these with wrappers around components of one of the well-established public domain matrix class libraries.

Another concrete vector class in the present release implements sampled functions on a regular grid in n-space, with out-of-core data storage. This Sampled Grid Function class (SGFVector) realizes a widely used seismic disk data format (due to the Stanford Exploration Project) as a vector class. Its design accomodates any data representing samples of a function on a regular grid. SGFVector can and has been used to formulate and solve optimization problems involving data and solution vectors of size far exceeding core memory capacity. This out-of-core capability is unique to HCL amongst object oriented numerical libraries, so far as we know.

We have abjured ``advanced'' features of C++ in the interest of efficiency and portability. In particular we have not used templates, and therefore must carry both single and double precision versions of all arithmetic classes. Our naming convention is simple: the double precision HCL source resides in the directory tree hcld, single precision in hcls. Source files containing definitions or implementations of double precision classes have names ending in ``_d'', files for single precision source have names ending in ``_s''. Single precision source is generated automatically from double precision source.

In the documentation we will refer to a class sometimes without the ``_d'' or ``_s'', when precision is not at issue. When a specification is necessary, the documentation always refers to the double precision class, as the single precision class of the same root name functions in exactly the same way.

Some of the concrete matrix classes make use of the Fortran utility files residing in the dustydecks tree, containing code borrowed from the BLAS, LAPACK, ARPACK, and other public domain sources.