Ticket #4232 (closed defect: fixed)

Opened 8 years ago

Last modified 5 years ago

Error message refers to incorrect copy of Set

Reported by: khunter Owned by: unassigned
Priority: major Milestone: Coopr 3.5
Component: pyomo.core Version:
Keywords: Cc: kmhunte2@…

Description

Consider the following set construction:

from coopr.pyomo import *

M = model = AbstractModel()

M.time_period = Set()
M.window      = Set( within=M.time_period )
M.vintage     = M.time_period  # copy of time_period; used for technology
                               # vintaging and to maintain code readability
# input.dat

set  time_period  := 2000  2010  2020  2030 ;
set  window       := 2000  2015 ;

Gives the error message

$ pyomo mtest.{py,dat}
ERROR: constructing declaration 'window' from data={None: [2000, 2015]} failed
ERROR: Unexpected exception while running model mtest.py
	The value=2015 is not valid for set=window, because it is not within the domain=vintage

Note that it refers to vintage, yet the window Set was supposed to be within time_period.

Change History

comment:1 Changed 8 years ago by khunter

  • Cc kmhunte2@… added

comment:2 Changed 8 years ago by khunter

  • Priority changed from normal to minor

comment:3 Changed 8 years ago by khunter

  • Priority changed from minor to major

This has now bitten me in a less than minor fashion as I need to work with a particular alias of set that is used via multiple aliases within a single parameter. Unfortunately, I don't know that section of Pyomo well enough to offer a patch in a time frame that I can manage, so I need to work around this bug in my code for the time being.

However, I believe this to be no longer minor priority bug, as it affects more than just an error message.

comment:4 Changed 8 years ago by khunter

  • Component changed from Configuration to coopr.pyomo

comment:5 Changed 5 years ago by wehart

  • Milestone set to Coopr 3.5

comment:6 Changed 5 years ago by jdsiiro

Referenced in changeset [8181]:

Fixing tickets #4323 [ne, #4232] and #4482. We used to support renaming or moving a component simply by assigning it to a new block or by assigning it to a new attribute on the same block (although we tossed a warning).

Attempting this now raises an exception.

Justification for the change in behavior: we implemented the move / rename by internally performing "block.del_component() + block.add_component()". This has the net effect of moving the component to the END of the construction order — a very bad thing if it is something like a Set where other components were counting on the set to already be constructed (which gave rise to the error reported in #4482)!

comment:7 Changed 5 years ago by jdsiiro

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

I am marking this as "fixed in r8181", although the fix is to disallow the behavior reported in the ticket.

Note: See TracTickets for help on using tickets.