Ticket #4482 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

Use of (questionable, perhaps) set assignment results in data read error message

Reported by: dlwoodr Owned by: unassigned
Priority: normal Milestone: Coopr 3.5
Component: pyomo.core Version:
Keywords: Cc:

Description

This seems simple, but might be a bit deep.

I added this line to the version of diet2.py that is attached:

model.sameasFOOD = model.FOOD

Then I modified a var declaration that had used FOOD to use my new set:

model.Buy = Var(model.sameasFOOD, bounds=Buy_bounds, within=NonNegativeIntegers?)

This brings up two unrelated issues:

  1. I do have a semi-legit use-case for having two sets with the same name and then trying to use them interchangeably. That seems reasonable semantically, but it might not be reasonable as a practical matter. I can live without it. If that is the ruling, I will add some documentation, because the way I want to do things would seem Pythonic so people should be steered away from it when we document creating sets with the assignment constructor.
  1. If one does this sort of thing, one gets an almost-unrelated error when the data is read. In this particular case, the error is:

RuntimeError?: Failed to set value for param=cost, index=Sausage McMuffin?, value=1.29; source error message="Error setting parameter value: Index 'Sausage McMuffin?' is not valid for array Param 'cost'"

Attachments

dlwdiet2.pyc Download (2.0 KB) - added by dlwoodr 5 years ago.
dlwdiet2.py Download (1.7 KB) - added by dlwoodr 5 years ago.

Change History

Changed 5 years ago by dlwoodr

Changed 5 years ago by dlwoodr

comment:1 Changed 5 years ago by wehart

  • Milestone set to Coopr 3.5

comment:2 Changed 5 years ago by jdsiiro

Referenced in changeset [8181]:

Fixing tickets #4323 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:3 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.

The problem reported in part 2 is due to the change in the component construction order mentioned above in the commit log.

Some more background on part 1 is in order: in particular, in your example, you are not actually creating two equivalent sets in your model: you are attempting to create two references to the *same* set in the model. This is just not a use-case that Pyomo was ever designed to support; in particular, the current design assumes -- and now enforces -- that every component has no more than one parent. We also assume that each parent only holds a single reference to the child object. While we might be able to relax those assumptions in the future, right now the safer thing to do is to verify and (verbosely) document why we do not allow it.

Note: See TracTickets for help on using tickets.