Hi Manuel ------------------------------------------------------------ To: Manuel Welsch <[email protected]>, [email protected] Subject: Re: [Help-glpk] FW: FW: Leap/OSeMOSYS Message-ID: <1320800606.2997.45.camel@corvax> From: Andrew Makhorin <[email protected]> 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) : [email protected] Webmail (preferred) : [email protected] [from Webmail client] _______________________________________________ Help-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-glpk
