[Coin-discuss] Possible Classes to represent a Model

[Luigi Poderico]

JP,

attached to this message there are some classes, that we are using into a
unit commitment solver, very similar to the ones that you described.

I have no English documentation on this, but I hope that structure classes
and the comments will be enough to understand the major features.

Class Variables
Store the main information on optimization problem variables, that are
partitioned in groups. Each group is described by 1) the size, 2) the kind
of
variables (integer, continuous, etc.), 3) a unique name. Each variable is
described by 1) the status (free, fixed, set), 2) lower and upper bounds, 3)
a unique name whit in the group, 4) a name  unique name whit in the
variables.
The operations offered by Variables are: 1) set or fix the values of a
variable; 2) free the value of a variable; 3) register a solver; 4) map a
global name to the couple (group name, var name in group) and vice versa.
It's very important the operation 3, because an object of class Variables
can be shared by several solvers. So if some one change the variables, for
example because it has fixed a variable to 0's, the other solvers that share
the same information must receive a signal on this.

Class Constraints
A Constraints object describe a subset of rows matrix: 1) the number of
rows, 2) the rows elements, 3) the lower and uperbunds. Several Constraints
objects can describe an optimization problem, using a Variables object that
share the name variables.
As class Variables, there is a solver register mechanism.

Class ObjectiveFuntion

Represent an objective function, described by 1) the kind of o.f. that can
be linear, quadratic or black box; 2) the coefficients of linear and
quadratic terms, if any; 3) evaluate the function in a point. The name of
variables are decide to a Variables object.

Class Solver

Get an optimization problem description and solve it. An optimization
problem is described by a Variables object, an ObjectiveFuntion object and
one or more ObjectiveFuntion object.

Note that Solver use a template based layer, that virtualize the "real"
solver.



I hope that our work could be useful in your design. I'd like to point out
the capability of sharing constraints and modification throw several problem
description and solvers, that is revealing very useful when a complex
problem is solved throw a set of smaller and closer sub problems. I have a
question about your proposal: are you thinking to use your classes only to
store informations abstracting "data input" against solvers implementation?




Bests,
Luigi


^^^^^^^^^^^^^^^^^^^^^^^^^^

Poderico Luigi
Ind.: via Pesenti, 19 - 56124 Pisa
Tel.: +39 329 8151210
Fax. +39 329 50 8151210
e-mail: lupoderi at tiscalinet.it
web: http://poderico.supereva.it


----- Original Message -----
From: "J P Fasano" <jpfasano at us.ibm.com>
To: <Coin-discuss at oss.software.ibm.com>
Sent: Thursday, July 25, 2002 10:29 PM
Subject: [Coin-discuss] Possible Classes to represent a Model


> Today there was a meeting with John Forrest, Laci Ladanyi, Robin
> Lougee-Heimer, Ted Ralphs, Matt Saltzman, and myself.
> During the meeting we discussed the idea of separating the Model data from
> the OsiSolverInterfaces.
> I agreed to post my understanding of the discussion.
>
> There could be separate classes to represent a variable and a constraint.
> An objective function can be represented as a constraint (without bounds).
>
> A model is just collection of variables, collection of constraints, and
> collection of objective functions.
> The intention is that this can capture both linear and nonlinear problems.
> A linear model is a special kind of model, where different storage
> techniques would likely be used for run time efficiency.
>
> So the classes might look like:
>   OsiVariable
>     Type enum: might include: Continuous, Integer, ...
>     LowerBound: double
>     UpperBound: double
>     Value: double
>     Reduced cost (multiplier): double
>     Identifier: int
>
>   OsiConstraint
>     Type enum
>     LowerBound: double
>     UpperBound: double
>     Value: Ptr to Function of OsiVariables
>     Price (multiplier): double
>     Identifier: int
>
>   OsiModel
>     Member Data:
>       Variables:   Collection of OsiVariable
>       Constraints: Collection of OsiConstraint
>       Objectives:  Collection of OsiConstraint
>
>   OsiLinearConstraintModel inherits from OsiModel
>     Member Data:
>       Variables: use more efficient storage than
>                  Collection of OsiVariable for runtime
>                  performance
>       Constraints: OsiPackedMatrix
>     Methods:
>       Re-implement OsiModel methods to use local
>       member data.
>
> JP Fasano
> jpfasano at us.ibm.com
> (914)945-1324  (tie line 862-1324)
> COIN www.coin-or.org
>
>
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at www-124.ibm.com
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-discuss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OptimizationProblem.zip
Type: application/x-zip-compressed
Size: 11523 bytes
Desc: not available
URL: <http://list.coin-or.org/pipermail/coin-discuss/attachments/20020729/afbd6be4/attachment.bin>