Re: [Help-glpk] FW: FW: Leap/OSeMOSYS

[Daniel Gustafson]

> > Not sure if it is ok to address you with this issue, but I believe it
> > does not really fit into the help distribution list. My question is
> > just out of curiosity.
> > We are currently working on an open source energy model
> > www.OSeMOSYS.org, which is interlinked with an existing energy model
> > called LEAP (www.energycommunity.org). LEAP in its new version can
> > basically do optimization using OSeMOSYS and ultimately glpk. Some
> > users set up an energy model with hourly time slices throughout the
> > year, basically describing demand and generation for each and every
> > hour of the year for a period of several years. This creates huge
> > matices and glpk runs out of memory. Our colleagues tried then to use
> > plexus, which was able to solve the problem in 30 seconds, which seems
> > surprisingly short.
> > We were wondering what the main differences in the code are that
> > explain this discrepancy.
> The glp_prob problem object used on api level requires additional memory
> to store various auxiliary information used by glpk routines. For
> example, one element of the constraint matrix (of double type) being
> stored in glp_prob requires 32 bytes (on a 32-bit platform) rather than
> 8 bytes. Thus, an lp instance being stored in glp_prob takes about four
> times more memory than if it were represented as a set of plain arrays,
> and about ten times more memory in case if the lp preprocessor is used.
>
> To estimate the amount of memory required by glpk please see
> http://lists.gnu.org/archive/html/help-glpk/2008-07/msg00044.html .
The type of problem you describe--an hourly simulation of power system 
operations--cannot normally be solved by a black-box LP engine except 
for the smallest prototype cases.  There are two reasons:  the size of 
the problem gets very large very quickly, and the nature of the 
problem--repeated blocks of virtually-identical equations--often 
exhibits degeneracy.

Fortunately, the techniques of decomposition, Dantzig-Wolfe and Benders' 
Decomposition, work very well for this type of problem.  There are other 
idiosyncratic tricks and techniques that can be applied if the structure 
of the problem can be further limited.  Note that decomposition is not 
an alternative to a simplex solver but rather capitalizes on the 
structure of the problem to use the solver more effectively.

Evidently the Plexos application implements some of these techniques 
because Plexos requires the user to supply a simplex solver.  The 
techniques used by commercial vendors of power system analysis 
applications are of course not well documented.
> > Also, in case there is a generic option to make glpk solve this
> > problem, apart from heavily adjusting the OSeMOSYS code, e.g., by
> > splitting up the problem somehow, please do let us know.
>
>
> _______________________________________________
> Help-glpk mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-glpk