Redesign the Pyomo Connector component

[jsiirola]

We have started accumulating a number of documented issues with the current implementation of Connector components. This issue is an umbrella issue to track them, as well as centralize discussion around a redesign of the Connector component.

Known Connector issues:

• Deactivating one side of connector causes representation error #91
• ConnectorExpander cannot be applied tier-wise in a model #96
• Expanded connector constraints do not identify as equalities #107
• DAE transformations on connectors #128
• Connectors do not support sliced variables #227
• Connector features #290
• Design documentation for connectors #297
  Support initialize=True/False for Disjuncts #376

[eslickj]

It would be very useful for the IDAES project if there was some way to store the direction of a connector. Maybe if the connection constraints could have some deterministic ordering of connectors in the expression. The direction doesn't really mean anything for Pyomo, but in displaying process flowsheets and sequential modular initialization it is important.

[qtothec]

We could have an IDAES subclass of Connector that stores the directionality information?

[eslickj]

If we had directional connectors that would also solve the problem. Just define them as in or out. I kind of prefer the direction to be attached to the constraint, but I don't have a solid reason for that. If labeling connectors in/out is best way to handle it, I can create a IDAES issue and we can cross my comment off the list.

[gseastream]

I believe most of these issues will be solved by the new pyomo network Port/Arc package in #583. I would like to update this collection of issues and close what we can when the merge happens, but I also want to make sure these issues are actually solved, so please reply if you think some of these will not be resolved by the new system.

#91, #96 will definitely be solved because the Arc expander only expands active Arcs and then deactivates them afterwards

#107 will definitely be solved because the new transformation does not encounter this bug, for which I opened #618

#128 I'm pretty sure will be solved if I understood @blnicho correctly, since the new constraints are indexed by the same sets as the variables in the ports

#227 I'm not sure. I think this will be fixed by @jsiirola's slice thing he's working on?

#297 I'm not sure. The classes and methods are pretty well documented in the code, but I assume someone wants to me to put an rst file on sphinx so I guess I can throw one together

#523 will probably be fixed, or it'll at least be addressed since the new transformation has performance improvements and advantages over the old Connector expander

#376 does not appear to be relevant to connectors so I'll assume that was a typo

#290 has several issues in it:

1. Arcs replace the old way of defining constraints with connectors, and Arcs have their own ctype so they can be found instantly
2. All expanded constraints (except for some of the extensive ones) are placed on a block and the arc maintains a reference to that block, so you can access the collection of all constraints with stream1.expanded_block and deactivate the whole thing or whatever you want
3. You can access each constraint individually from this expanded block, and they are all named exactly by the name of the port member followed by "_equality", so if your port has something named "flow" there will be a constraint called flow_equality on the expanded block. You can access this via stream1.expanded_block.flow_equality, or you can even do stream1.flow_equality since I modified the __getattr__ method to look on the expanded block for things.
4. See slice comment above
5. As stated in the discussion, you can access variables from the port object via the vars dictionary attribute, but now with ports you can also do port1.flow and like the __getattr__ method above it will look in the vars dictionary for you. You can also call port1.fix() and it will fix every variable in the port at its current value.

[eslickj]

Just pinging @andrewlee94. He would be interested, and doesn't appear to be a participant in this issue yet.

[gseastream]

Per my comment above, with the recent merge of Pyomo network, #91, #96, #107, #523, and maybe others can be closed now. I would also still appreciate insight on some of the other issues listed above as to whether or not they are now solved.

[qtothec]

Well if you want to test them and see if they're still issues, then we can close as appropriate.

[blnicho]

Completed with #655