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

[Xypron]

The following papers presumedly describe the algorithm used in plexos.

The plexos homepage
http://energyexemplar.com/

refers to

Robert PASICKO, Slavica ROBIC, Zeljko TOMSIC
MODELLING CO2 EMISSIONS IMPACTS ON CROATIAN POWER SYSTEM
http://energyexemplar.com/wp-content/uploads/publications/Pasicko,%20Robic,%20Tomsic%20-%20Modelling%20CO2%20emissions%20impacts%20on%20Croatian%20power%20system.pdf

refers to

Glenn Drayton, Michael McCoy, Mario Pereira, Edward Cazalet, Mary 
Johannis, Dennis Phillips
Transmission Expansion Planning In The Western Interconnection – The 
Planning Process and the Analytical Tools That Will Be Needed to do the Job
http://www.psr-inc.com/psr/download/papers/IEEE_final_draft_dwp_11-4-23-04.pdf

refers to

M. V. F. PEREIRAAN D L. M. V. G. PINTO
Stochastic Optimization of a Multireservoir Hydroelectric System : A 
Decomposition Approach
http://www.cose.fee.unicamp.br/~dino/IT511/artigos/longo%20prazo/Stochastic_Optimization_of_a_Multireservoir_Hydroeletric_System_-_A_Decomposition_Approach.pdf

Best regards

Xypron

On 18.11.2011 20:16, Daniel Gustafson wrote:
> > > 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
>
>
> _______________________________________________
> Help-glpk mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-glpk