Re: [Help-glpk] Processing glpsol output with R (was: Need help on interval planning constraint)

[Noli Sicad]

Hi Robbie and Jeffrey,

R package, R Graphics and R Geo (maptools) are very GLPK / MathProg
output friendly. In the days few days, I was able to use some of the
difficult graphing problems I had. I even implemented joining tables
(LP result) in shapefile and rendering the maps using R Geo (spatial
R) i.e. maptools.

R package has library(foreign).

It reads and writes -, dbf, csv, dat and other format. We can read
directly from GLPK / MathProg in this format.

set A, set B, set C, Param1, Param2

No need to reformat the tables output by MathProg.

Example below
~~~~~~~~~~~~

library(foreign)
library(ggplot2)

forests <- read.csv("C:\\Down2\\R_forestmgt\\forest_cut.csv")

p <- ggplot(forests, aes(Period, Cut_Age)) + geom_point(colour =
"brown", size = 1)
p +  facet_wrap(~ Croptype, ncol = 2)

~~~~~~~~~~~~~~~

The forest_cut.csv table has this format.

set A, set B, Param1, Param2

Period,  Croptype, Age, HarvestArea

~~~~~~~
Another note: GUSEK runs R-package perfectly.

Regards, Noli



On 12/29/09, Robbie Morrison <address@hidden> wrote:
>
> Hello Jeffrey
>
> The quick answer is "not hard at all".
>
> RECOVERING JUST THE VALUES
>
> I suggest starting with the 'glpsol' option:
>
>   --write filename : write solution in plain text format
>
> The first thing to determine is whether the problem is
> pure-LP or MIP.  If not already known, this can be
> undertaken by counting the number of values in line
> two: three values indicates a pure-LP and two indicates
> an MIP (whether this is robust in the event of the
> solver returning failure or similar needs confirming).
>
> The next step is to parse the entire file according to
> the formatting rules for the underlying API call:
>
>   pure-LP problem : 'glp_write_sol'
>   MIP problem     : 'glp_write_mip'
>
> Consult the API manual for the actual details here.
>
> Parsing should be straightforward using double type
> arrays and matrices from R, in conjunction with the
> m x n information previously captured from line one.
>
> If one wants the LP-relaxation solution for an MIP
> problem, then I guess one would need to subsequently
> deploy '--nomip' and repeat the parsing task.
>
> [As a suggestion to Andrew, it might be cleaner for the
> '--write' option to state something like "LP" or "MIP"
> in the opening line to unambiguously indicate the
> problem class -- or perhaps even give a finer
> resolution, for instance "mixed-integer", "mixed-01",
> etc).  Note too that the now depreciated 'lpx_get_class'
> call used to provide at least some of this information.]
>
> The R command that could be used to read in the raw
> data is 'readLines()':
>
>   data  <- readLines(filename)  # default is to read all
>   lines <- length(data)
>   message("lines read     : ", lines)
>   if ( lines == 0 ) warning("no lines read")
>
> Also useful might be 'strsplit()', 'unlist()', and
> 'as.numeric()' for string to number coercion.
>
> OBTAINING MORE INFORMATION
>
> It would also be quite possible to parse the results
> from the existing 'glpsol' option:
>
>   --output filename : write solution in printable format
>
> Parsing this data would take more work but would also
> reveal more information, such as row and col labels
> (names).
>
> The current 'glpsol' practice of wrapping the output at
> text column 65 also makes the parsing task a little
> more awkward (as occurs in the presence of long row and
> col labels) but not impossible.
>
> [Perhaps a new 'glpsol' option might help here:
>
>   --meta filename : write problem metadata in parsable
>                     key/value format
>
> This option would output the problem name, row and col
> labels and so-forth for use in conjunction with option
> '--output'.  It could equally apply to unsolved and
> solved problem instances, but with the current solution
> status in the latter case.]
>
> READING THE PROBLEM
>
> The flip question (although not stated) is that of
> recovering the original problem using R via an exported
> MPS, CPLEX, or (not currently documented and/or fully
> implemented) OPB format.
>
> R itself already supports LP importation as part of
> either its core distribution or via contributed code.
> Here are some packages although I have no idea as to
> their respective statuses, except I think 'Rglpk' has
> yet to catch up with the new APIs:
>
>   package 'Rcplex' - R interface to the CPLEX
>     optimization library
>
>   package 'linprog' - linear programming / optimization
>
>   package 'Rglpk' - high level R interface to the MPS
>     and CPLEX_LP reader of the GNU Linear Programming
>     Kit (GLPK).
>
> CLOSURE
>
> I don't use 'glpsol', but I imagine that some modeling
> tasks are adaptive and that this adaptation might more
> easily take place in an external scripting environment
> than in MathProg.  Hence, script-friendly status and
> results recovery could be of benefit here.
>
> with best wishes to all
> Robbie
>
> ps: Andrew: the "glp_write_sol" on page 99 of the 4.41
>     API manual should read "glp_write_mip".
>
> ------------------------------------------------------------
> To:          Robbie Morrison <address@hidden>
> Subject:     Re: [Help-glpk] Need help on interval planning constraint
> From:        Jeffrey Kantor <address@hidden>
> Date:        Tue, 22 Dec 2009 16:58:32 -0500
> ------------------------------------------------------------
>
> Robbie,
>
> How hard would it be to write a standard import script
> for R?  That is, something to take glpsol's standard
> report and digest it into something that could be
> directly manipulated in R.