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

[Robbie Morrison]

Hi Manuel

------------------------------------------------------------
To:           Manuel Welsch <address@hidden>,
              address@hidden
Subject:      Re: [Help-glpk] FW: FW: Leap/OSeMOSYS
Message-ID:  <address@hidden>
From:         Andrew Makhorin <address@hidden>
Date:         Wed, 09 Nov 2011 04:03:26 +0300
------------------------------------------------------------

>> 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.

You should be able to obtain metrics on the quality of
the solution from the solver.

>> We were wondering what the main differences in the
>> code are that explain this discrepancy.

Just a comment.  I find aphysical models give no end of
trouble (scaling complaints, stability, round-off
errors, many near-zeros), whereas physically correct
models sail thru.  Do you know that your model is
correct?  Pipelines connected to wellheads and that
sort of thing.

> 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
>
>> 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.

This might be of some use:

  Yokoyama, Ryohei, Yasushi Hasegawa, and Koichi
    Ito. 2002.  A MILP decomposition approach to large
    scale optimization in structural design of energy
    supply systems.  Energy Conversion and Management,
    v43 no6 771-790.

Groscurth etal (circa 1995) also discuss Dantzig-Wolfe
decomposition in energy system models (but not in great
depth).  I could dig out the reference if you like.  See also:

  http://en.wikibooks.org/wiki/GLPK/Add-Ons#Dantzig-Wolfe_decomposition

Finally, did you know you have an entry in the GLPK
wikibook:

  http://en.wikibooks.org/wiki/GLPK/Application_projects_utilizing_GLPK#OSEMOSYS

Please edit that as you like!

Feel free to email me offline, as this is probably
drifting a little off-topic.

good luck, Robbie
---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Institute for Energy Engineering (IET)
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from Webmail client]