Re: [EXTERNAL] Re: Pyomo 4.1

[Yingjie Fan]

Yes, I mean the lowest convergence metric value when I say "the best". If I understand correctly, the final x-hat solution is generated based on  x-bar at the last PH iteration. For not convergent instances, it may exist a better x-hat based on x-bar appeared before the last PH iteration.

I didn't use time limit on the sub-problem solver. Do you mean results are always the same with the same PH max-iteration on your computer?

On Wednesday, July 15, 2015 at 5:04:55 PM UTC+2, JPW wrote:

Regarding your last comment: Yes, the metric value can become worse as PH progresses - there is no guarantee of monotonicity, even in the continuous case. But also recall that you do not have a solution until the end – and then only if a feasible x-hat is identified. When you say that the best solution may appear at iteration 20, you really mean that either the convergence metric is lowest, or the reported first-stage cost average is lowest. But if the metric is != 0.0, and the max-min difference in first stage solution cost is != 0.0, then you don’t have a non-anticipative solution. 

I’m interested/worried about the non-deterministic you are seeing, but it could have several explanations. Are you using a time limit on the sub-problem solves? That can cause non-detrministic, although it would obviously have been an issue previously with Pyomo4.0.

Gabe/anyone: Do you know if we have changed the “deterministic output” defaults in the LP/NL writers? I don’t recall any change, and am not seeing issues in the nightly tests, but I can’t think of another cause.

jpw

From: <pyomo...@googlegroups.com> on behalf of Yingjie Fan <fan...@gmail.com>
Reply-To: "pyomo...@googlegroups.com" <pyomo...@googlegroups.com>
Date: Wednesday, July 15, 2015 at 8:30 AM
To: "pyomo...@googlegroups.com" <pyomo...@googlegroups.com>
Subject: Re: [EXTERNAL] Re: Pyomo 4.1

Thanks to all of you! I understand now and feel more confident to use the results.

An interesting thing is, after I ran "runph" for several times for the same instance, results and convergernce histories are different for Pyomo4.1. But when I used Pyomo4.0, results for the same instance are exactly the same. What changes in Pyomo 4.1 make this phenomenon happen?

Another question or a small suggestion to Pyomo4.2:
According to the "Convergency history", sometimes the "Metric Value" become worse after PH iterations. When I define the max iterations at 50, the best solution may appear when iteration==20. Is that possible to recall the best historical solution? It will cost lots of computer memory to save all historical solutions, but I think it would be helpful if only save the "best till now" solution.

Yingjie

On Wednesday, July 15, 2015 at 3:47:44 PM UTC+2, Gabe Hackebeil wrote:

Yingjie,

Please note that I probably used these terms interchangeably in my original description (unconsciously), and it likely sounds very wrong to someone paying close attention. Most of the time I probably meant xbar, but hopefully you get the idea.

Gabe

On Jul 15, 2015, at 1:26 PM, David Woodruff <david.l....@gmail.com> wrote:

I should add some helpful notation  to this very good description:
   At each iteration, PH computes x-bar, which is the average over the scenarios. We use the notation x-hat (or, sometimes X-hat) to refer to a candidate solution,( or "upper bound" solution if you are minimizing.)

  So x-bar is computed at every iteration, but x-hat is computed only on termination. The new option controls how x-hat is determined.

  Dave

On Wed, Jul 15, 2015 at 3:48 AM, Gabriel Hackebeil <gabe.ha...@gmail.com> wrote:

Yingjie,

In the latest release we’ve integrated code that attempts to generate a feasible PH solution at exit. That is, we take the xhat (the current non-anticipative candidate variable solution) and fix all scenarios to that before performing a final solve. If PH is already converged, this should generate the same subproblem solutions anyway.

However, if PH is not converged this will be helpful in that it provides you with a feasible solution to the stochastic program (that might be a good solution if it is feasible). Because xhat, as updated by PH at each iteration, might not satisfy integrality constraints, we have implemented a few methods for generating the candidate variable solution, which can be controlled via the “--xhat-method” command-line option. I believe the default (“closest-scenario”) will find the scenario that is nearest to the current xbar, and then take that scenario’s variable values as the candidate solution for the entire SP. Other methods implemented are “voting” and “rounding”. The rounding method rounds xhat when the variable is integral or boolean, and the voting method performs a probability weighted vote over the scenarios to determine which integral value to take on. Unless I’m mistaken, voting and rounding would only differ if you had general integer variables in your model. It looks like your problem does, so it might be interesting to play around with this option.

Note that one might interpret this command-line option as describing how xhat is updated at each PH iteration. This is currently not the case (it only applies to the final PH solve), but it might be an interesting variation to explore for mixed-integer models (maybe it’s actually the correct thing to do).

Another thing to note is that you can obtain duality-based lower bounds on your objective (to go with this final upper bound) by adding the string “--user-defined-extension=pyomo.pysp.plugins.phboundextension” to the command-line invocation. This will perform an extra round of solves per PH iteration, but it’s nice to have for mixed integer models.

Finally, I’ve noticed some inconsistencies in output that you attached for the newer version of PH. It seem to be showing nonzero values for “min-max” even though the scenarios are all fixed to the same candidate solution in the first stage. This is a bug, and something I’ll look into getting fixed today.

Gabe

P.S. When I say xbar, I mean the probability weighted average variable solution in the first stage (for a two-stage problem) as computed after the most recent PH iteration. Also, when I say candidate solution I mean only in the first stage as well.

On Jul 15, 2015, at 8:34 AM, Yingjie Fan <fan...@gmail.com> wrote:

Two pairs of examples are attached. "...old" are results from Pyomo4.0. Without "...old" are from 4.1.

Yingjie

On Wednesday, July 15, 2015 at 2:34:26 AM UTC+2, JPW wrote:

The first stage costs should not be the same for all scenarios when it is non-convergent. Can you provide an example of the output you are seeing?

jpw

From: <pyomo...@googlegroups.com> on behalf of Yingjie Fan <fan...@gmail.com>
Reply-To: "pyomo...@googlegroups.com" <pyomo...@googlegroups.com>
Date: Tuesday, July 14, 2015 at 5:05 PM
To: "pyomo...@googlegroups.com" <pyomo...@googlegroups.com>
Subject: Re: [EXTERNAL] Re: Pyomo 4.1

One further question:
in runph results, first stage costs in this new version are the same for all scenarios even when it is not totally convergent. Is the first stage cost the average cost of all scenarios or the cost of the average solution? If it is the value of the average solution of all scenarios, does the average solution satisfy integrate constraints?

Thanks!

Yingjie

On Tuesday, July 14, 2015 at 10:41:31 PM UTC+2, John wrote:

Talking to Bill, we realized that the problem is likely an out of date PyUtilib dependency. Can you upgrade/update the installed version of PyUtilib and see if the problem goes away?

John

On Jul 14, 2015, at 3:23 PM, Gabe Hackebeil <gabe.ha...@gmail.com> wrote:

John,

This should be inherited from the the Plugin interface. Not sure how __enter__ could be, but not __exit__.

Gabe

On Jul 14, 2015, at 6:37 PM, Siirola, John D <jds...@sandia.gov> wrote:

Gabe,

I think you are onto something with the root cause being a solver error. 

That said, I also think there is a bug in our code: My guess is that the SolverFactory is returning an UnknownSolver object - which doesn't implement the __exit__() method, so isn't compatible with the "with" statement that was added to pyomo/scripting/plugins/util.py (but then, I don't see where any of the solvers define __exit__ or __enter__ ... So this may be a bigger fix - and it might just be easier to remove the with statement in the short term). 

John

John

On Jul 14, 2015, at 1:05 PM, Yingjie Fan <fan...@gmail.com> wrote:

I tried Pyomo-4.1.10505, still didn't work :-(

Yingjie

On Tuesday, July 14, 2015 at 6:56:14 PM UTC+2, Yingjie Fan wrote:

Thanks Gabe!
There is no problem with my PATH, I can run cplex.exe.
Python version 3.4.3
I will try Pyomo-4.1.10505 soon.

Yingjie
On Tuesday, July 14, 2015 at 6:29:22 PM UTC+2, Gabriel Hackebeil wrote:

I can’t seem to reproduce that error (even when I give a bad solver name). This might be a side-effect of cplex.exe not being in your PATH on Windows. Can you launch cplex.exe from any directory on the command line? If not, you need to fix that.

Also, there was a maintenance release today (Pyomo-4.1.10505). You might try giving that a shot.

I’ll try and reproduce this on a Windows machine when I get a chance. What version of Python are you using?

Gabe

On Jul 14, 2015, at 5:19 PM, Yingjie Fan <fan...@gmail.com> wrote:

Hello, does the new version Pyomo-4.1.10486 function well now? It does not work on my computer (Windows 7).

Commend line:
pyomo solve --solver=cplex ***.py ***.dat

Traceback (most recent call last):
  File "C:\Python\lib\runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Python\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Python\Scripts\pyomo.exe\__main__.py", line 9, in <module>
  File "C:\Python\lib\site-packages\pyomo\scripting\pyomo_main.py", line 71, in
main
    retval = ret[0].func(*ret)
  File "C:\Python\lib\site-packages\pyomo\scripting\plugins\solve.py", line 161,
 in solve_exec
    with SolverFactory(solver) as opt:
AttributeError: __exit__

Best regards,

Yingjie

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<instancesLT30+.dat><instancesLT30+old.dat><instancesLT40+.dat><instancesLT40+old.dat>

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Watson, Jean-Paul]

Correct – we are seems deterministic results on our tests and systems. If you are willing to share your model/data and associated command line (privately is fine, sending directly to me), I’d be happy to check it out.

[kbl...@berkeley.edu]

Hi everyone,

I read the thread and have a question with respect to a slightly different situation: PH converges however the implementation fails to compute xhat in the last step.  

My problem is multi-staged but each subproblem is linear in objective and constraints (variables are continuous). I took a look at the CPLEX solver log and there was an infeasibility row (CPLEX> Infeasibility row 'c_e_x41_':  0  = 0.928939.) that is likely a result of the projection steps. 

My question is what does the current implementation do when such scenarios occur.

Looking forward to hearing your thoughts.

Best,

Kevin

[David Woodruff]

Hi Kevin,

  The current version does not do a very good job with tightly constrained continuous variables (speaking loosely). Most of the xhat code was written with MIPs in mind and MIPs for which if one has the integers, the other variables behave nicely.

   I have some half-written code that I think will do a better job on xhat for your sort of problem.

   A related issue is tests for "convergence," particularly when all variables are

continuous.

  I will make it a priority to get back to this by early next week; perhaps I can ask you to try

out the branch when it is ready to test.

  If you want to work on these issues in PySP, we should probably talk off the forum.

Dave

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum+unsubscribe@googlegroups.com.

[Watson, Jean-Paul]

Hi Kevin,

 

Following up on what Dave says…

 

You can (and should) try to use the option “--enable-primal-dual-residual-convergence” option on runph. The default converger in PH only addresses primal convergence, and you are likely to end up with a better solution if you ensure both primal and dual (weight) convergence.

 

Regarding work to get a primal feasible x-hat, you can and should use the “--termdiff-threshold” option on runph – I think it defaults to 1e-4. If you crank that down to something like 1e-6, you perhaps can avoid the tolerance issues you are seeing. This will of course increase the number of iteration required for convergence.

 

Another option to improve primal convergence / quality is to bundle scenarios, using the --create-random-bundles option on runph. This will increase sub-problem difficulty, but if your individual scenarios are not that hard, should help.

 

jpw

[David Woodruff]

... following up on what JP said: So far, we have not encountered an non-MIP that did not benefit from bundling, so you might start there. When you use random bundles, you will want to also use the --scenario-tree-seed option to allow for repeatability.

--

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum+unsubscribe@googlegroups.com.

[Siirola, John D]

…following up on both Dave and JP:  I feel that I should point out that Pyomo 4.1 is over 2.5 years old (current release is 5.3, and 5.4 is due out in days).  There is a distinct possibility that some of what both JP and Dave said may not apply to the 4.1.x releases.

 

john

[Abodh Poudyal]

I got the following error while using the tags below for 49 scenarios on runef:

--scenario-tree-random-seed=0 

--create-random-bundles=5

***************************************************************************************************

RuntimeError: Re-assigning the component 'Scenario1' from block 'Bundle2' to

block 'MASTER' as 'Scenario1'.

This behavior is not supported by Pyomo; components must have a

single owning block (or model), and a component may not appear

multiple times in a block.  If you want to re-name or move this

component, use the block del_component() and add_component() methods.

[David Woodruff]

Are you running Pyomo 6 and the latest version of PySP?

To view this discussion on the web visit https://groups.google.com/d/msgid/pyomo-forum/e42ffa18-9d12-43e8-a725-9658398b1dcbn%40googlegroups.com.

[Abodh Poudyal]

I updated the pyomo to 6.0.1 (from 5.7) and now the runef or runph command does not work.  

'runef' is not recognized as an internal or external command, operable program or batch file.

My pysp version is 0.0.10 (which I believe is the latest version right?)

[Abodh Poudyal]

as an update I did update the pysp to version 6.0 from the github. However, I get this error when I type runef --help

Traceback (most recent call last):

  File "C:\Users\poudyal\anaconda3\envs\py3\Scripts\runef-script.py", line 33, in <module>

    sys.exit(load_entry_point('PySP==6.0.0', 'console_scripts', 'runef')())

  File "C:\Users\poudyal\anaconda3\envs\py3\Scripts\runef-script.py", line 25, in importlib_load_entry_point

    return next(matches).load()

StopIteration

[David Woodruff]

Starting with version 6.0 of Pyomo you need to get PySP from

https://github.com/Pyomo/pysp

then

cd pysp

then

python setup.py develop

To view this discussion on the web visit https://groups.google.com/d/msgid/pyomo-forum/c13843be-7397-48fd-ae6e-21488939cea4n%40googlegroups.com.

[Abodh Poudyal]

This exactly solved my problem. 

I installed pysp using pip install pysp and did not realize it would create this issue. Now I have successfully installed pyomo 6.0 and the latest version of pysp and scenario bundle works for me (although it is a bit slower than just running runph). However, it is great to have the feature working. Thank you Dr. Woodruff for your constant support.

Regards,

Abodh

[David Woodruff]

Hmm. Very interesting. We should disable pip install PySP.

To view this discussion on the web visit https://groups.google.com/d/msgid/pyomo-forum/ec3f3632-f0c5-44cd-9e72-1a811da1fdd6n%40googlegroups.com.