Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate new Set rewrite into Pyomo #1319

Merged
merged 85 commits into from
Mar 31, 2020
Merged

Integrate new Set rewrite into Pyomo #1319

merged 85 commits into from
Mar 31, 2020

Conversation

jsiirola
Copy link
Member

@jsiirola jsiirola commented Mar 2, 2020

Fixes #N/A

Summary/Motivation:

This integrates the set rewrite (#1111 / #326) into all of Pyomo.

Changes proposed in this PR:

  • updating process_setarg to better handle function/generator arguments
  • improve simple_set_rule decorator to preserve wrapped rule API
  • adding indices, contains_indices methods to initializer objects
  • Adding TUplizeValuseInitializer to standardize tuplization of lists for multidimensional Sets
  • Improved deprecation support for old Set methods and attributes
  • adding a Set.get() method for fetchng the value stored in the set
  • SetOperators not connected to Blocks are always copied when cloning models/blocks
  • Improved implementation of DeclareGlobalSet
  • RealSet, IntegerSet, BinarySet moed from core.kernal.set_tyes to core.base.set. Stubs (sufficient for kernel's needs) were reimplemented in Kernel.
  • improved testing and handling of various edge cases encountered when converting Pyomo

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

  1. I agree my contributions are submitted under the BSD license.
  2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

Move to a more aggressive approach for immediately constructing Sets
when the data is already present / defined.
We map 1-tuple indexes to scalars.  Set.get() allows consumers like
IndexedComponent to both test membership and retrieve the mapped value,
so that the _data dictionary can match the underlying Set.
...including concrete, virtual, value and check_values()
This restores legacy functionality whereby dimensioned Set objects can
be initialized from flat lists (necessary for DAT file input).
This updates Set methods so that they better match the behavior in
the Python set methods they are copying.
Adding additional cases for backwards compatibility with the previous
RangeSet implementation.
Constructing an abstract component that us using the class name as the
component name should update the component name to the concrete version
of the class.
Copy link
Contributor

@michaelbynum michaelbynum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, this looks great. I do have a few minor comments/questions.

pyomo/core/base/global_set.py Show resolved Hide resolved
pyomo/core/base/set.py Show resolved Hide resolved
pyomo/core/base/set.py Show resolved Hide resolved
pyomo/core/base/set.py Show resolved Hide resolved
pyomo/core/base/set.py Show resolved Hide resolved
pyomo/core/base/set.py Show resolved Hide resolved
@Robbybp
Copy link
Contributor

Robbybp commented Mar 10, 2020

Just merged this with my dae-tools branch and discovered a bug. When creating a SetOperator from a ContinuousSet, the _fe attribute will change from containing only the finite element points to containing the entire set. The following code illustrates:

from pyomo.environ import *
from pyomo.dae import *

m = ConcreteModel()

m.time = ContinuousSet(bounds=(0,1))
m.set1 = Set(initialize=['a','b','c'])

disc = TransformationFactory('dae.collocation')
disc.apply_to(m, wrt=m.time, nfe=2, ncp=2, scheme='LAGRANGE-RADAU')

op = m.time * m.set1

print(m.time._fe)

displaying [0, 0.166667, 0.5, 0.666667, 1], instead of [0, 0.5, 1] as in previous versions of pyomo. This is significant as it renders get_finite_elements useless. This could be caused by an erroneous call to construct, which sets self._fe = sorted(self), but I didn't see an obvious culprit in a quick scan through the code of the set operators.

@Robbybp
Copy link
Contributor

Robbybp commented Mar 10, 2020

This also seems to happen when expanding arcs.

@jsiirola
Copy link
Member Author

@Robbybp ContinuousSet should be fixed now (including a test to catch this case in the future). Thanks!

@Robbybp
Copy link
Contributor

Robbybp commented Mar 10, 2020

@Robbybp ContinuousSet should be fixed now (including a test to catch this case in the future). Thanks!

Yep, the code that led to me finding this works now, thanks for fixing

@ghackebeil
Copy link
Member

ghackebeil commented Mar 10, 2020 via email

pyomo/core/base/var.py Outdated Show resolved Hide resolved
pyomo/core/base/var.py Outdated Show resolved Hide resolved
pyomo/core/kernel/variable.py Outdated Show resolved Hide resolved
pyomo/core/plugins/transform/util.py Outdated Show resolved Hide resolved
pyomo/dae/diffvar.py Outdated Show resolved Hide resolved
pyomo/core/base/set.py Outdated Show resolved Hide resolved
pyomo/core/base/set.py Outdated Show resolved Hide resolved
pyomo/core/base/set.py Outdated Show resolved Hide resolved
pyomo/core/base/set.py Outdated Show resolved Hide resolved
pyomo/core/tests/unit/test_set.py Outdated Show resolved Hide resolved
@jsiirola
Copy link
Member Author

@blnicho, I think I addressed all your comments except for updating the ContinuousSet docstring.

@@ -1,14 +1,15 @@
import pyomo.kernel as pmo
import pyomo.environ as pe
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm hoping to keep pyomo.kernel as self contained as possible until the two modeling layers are compatible. Is this import necessary?

Copy link
Member Author

@jsiirola jsiirola Mar 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, for this example., yes: Reals is a proper Pyomo Set. The alternative was to change all the Reals in the example to RealSet from kernel, and I wasn't exactly clear as to what you were trying to highlight in the example.

examples/pysp/scripting/apps/compile_scenario_tree.py Outdated Show resolved Hide resolved
return False


class BinarySet(object):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The BinarySet, BooleanSet objects don't seem to serve a purpose in kernel.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but I think I ran into examples that used BinarySet and BooleanSet from kernel. Regardless, I left them in for backwards compatibility. If we can later confirm that they are not necessary (and no one is using them), then we can delete.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fairly certain this these are not needed in kernel. Binary, yes. BinarySet, no.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BooleanSet is used in pyomo/core/tests/unit/kernel/test_variable.py (and historically BooleanSet and BinarySet have been the same class), but it was not imported into pyomo.kernel.

Part of my refactoring was so that kernel proper only needs RealSet and IntegerSet, and can infer Binary from a standard get_interval() method. Longer term, I would like to standardize on BinarySet where needed so that we can re-purpose BooleanSet to be a proper Boolean (i.e., True/False, and not 0/1) set.

Copy link
Member Author

@jsiirola jsiirola left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @ghackebeil. Some responses below.

Do you see any concerns with Pyomo now having two implementations of RealSet and IntegerSet (one for core/kernel and one for core/base)? When Reals/Integers/etc got moved to be proper Set objects, this meant that we needed to support the RealSet / IntegerSet objects in both frameworks (at least for backwards compatibility).

@@ -1,14 +1,15 @@
import pyomo.kernel as pmo
import pyomo.environ as pe
Copy link
Member Author

@jsiirola jsiirola Mar 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, for this example., yes: Reals is a proper Pyomo Set. The alternative was to change all the Reals in the example to RealSet from kernel, and I wasn't exactly clear as to what you were trying to highlight in the example.

return False


class BinarySet(object):
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but I think I ran into examples that used BinarySet and BooleanSet from kernel. Regardless, I left them in for backwards compatibility. If we can later confirm that they are not necessary (and no one is using them), then we can delete.

This restores global set (Reals, etc) imports for kernel users through
the pyomo.kernel environment.  Reverting changes to the kernel variables
documentation and example.
@blnicho blnicho merged commit 9def76d into Pyomo:master Mar 31, 2020
@jsiirola jsiirola deleted the set-merge branch March 31, 2020 19:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants