> Thank you. This reduced the memory usage considerably and the solver > was able to start.
> lpx_read_cpxlp: 2730 rows, 117390 columns, 212813510 non-zeros Wow! The constraint matrix is extremely dense and therefore huge. Please note that glpk is a 32-bit application. Currently the size of any array cannot be larger than 2GB, that in case of the double type limits the number of array elements to 268,435,456. Though GLPK conforms to LP64, there may be addressing problems, because some glpk routines reserve additional locations (up to 50% of the array size), and necessary checks are not implemented yet. > After running for a while I get a numerical instability message. > 800: objval = 0.000000000e+00 infeas = 8.592439282e-03 (0) > 805: objval = 0.000000000e+00 infeas = 8.522774850e-03 (0) > 810: objval = 0.000000000e+00 infeas = 8.467081435e-03 (0) > 815: objval = 0.000000000e+00 infeas = 8.038690407e-03 (0) > spx_simplex: numerical instability (primal simplex, phase I) > 820: objval = 0.000000000e+00 infeas = 1.000000000e+00 (0) > 825: objval = 0.000000000e+00 infeas = 9.698752944e-01 (0) This is a warning message, not an error. To be sure that the solution is accurate enough, you may check the kkt optimality conditions printed at the bottom of the solution sheet (use the '-o' option). > 2. Reduce the size of the objective coefficients--- they are all 1's, > while the constraint matrix has coefficients ranging between 10^-4 and > 10^-10 (with a -1 in each row due to the problem formulation.) > Are these approaches correct? Try to remove tiny constraint coefficients. This may improve numeric properties of the constraint matrix and make it sparser. > Is it also worthwhile to just let the solver run and hope for the > best? Probably, yes. Andrew Makhorin _______________________________________________ Help-glpk mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/help-glpk
