Ticket #4046 (closed defect: fixed)

Opened 8 years ago

Last modified 4 years ago

Erroneous processing in GLPK soln output

Reported by: wehart Owned by: jwatson
Priority: major Milestone: Coopr 3.4
Component: pyomo.solvers Version:
Keywords: Cc: kmhunte2@…

Description

The current glpk parser divides the solution dataline into chunks:

                index_string = line[0:6].strip()
                name_string = line[7:19].strip()
                activity_string = line[23:36].strip()
                lower_bound_string = line[37:50].strip()
                upper_bound_string = line[51:64].strip()

However, glpsol v 4.32 allows data lines to be split when long names are used:

     1 PTotal(2001,Water1)
                    B              5             0
     2 PTotal(2001,Coal1)
                    B             97             0

We need to recognize when this split occurs and adapt the parser accordingly. Currently, this is blocking the use of GLPK for the energy-water application; I'm marking the priority as 'major', as we can work-around this using a different solver.

Change History

comment:1 Changed 7 years ago by khunter

  • Cc khunter added

Is there any objection to converting to regular expressions? The big one I might note is that regex's can be an order of magnitude or more slower than direct string manipulation like this. On the other hand, I think they're a heck of a lot cleaner to implement. I also hazard a guess that this would *not* be the bottleneck.

comment:2 Changed 7 years ago by wehart

I have no objections to using them to parse these lines. Using them more generally sounds like overkill.

comment:3 Changed 7 years ago by khunter

  • Cc kmhunte2@… added; khunter removed

Turns out there's a sexier solution involving use of a more-easily machine parseable output from GLPK. As of r3574, glpk_experimental should offer a more robust parsing experience. I'm also curious (via JP and PySP) if it offers any speed improvement or detriment. I doubt it will be anything more than noise, but the associated code is much simpler (and is backed up by a defined 'API' from GLPK).

comment:4 Changed 7 years ago by wehart

  • Milestone changed from Coopr 2.x to Long Term

comment:5 Changed 6 years ago by khunter

  • Status changed from new to closed
  • Resolution set to fixed

This should no longer be an issue with the switch to the new GLPK solver plugin.

comment:6 Changed 4 years ago by wehart

  • Milestone changed from Long Term to Coopr 3.4
Note: See TracTickets for help on using tickets.