Incidence Analysis/GreyBox integration

[Robbybp]

@andrewlee94 has requested this. I believe @avdudchenko brought this up at some point on the IDAES side.

Summary

We basically want to do something like this:

class MyGreyBox(ExternalGreyBoxModel):
    ...

m = pyo.ConcreteModel()
# Define explicit variables and constraints
# inputs/outputs are lists of variables we defined somewhere.
m.gb = ExternalGreyBoxBlock(MyGreyBox(), inputs=inputs, outputs=outputs)

igraph = IncidenceGraphInterface(m)
# Alternatively:
# nlp = PyomoNLPwithGreyBoxBlocks(m)
# igraph = IncidenceGraphInterface(nlp)
vdm, cdm = igraph.dulmage_mendelsohn()
# The implicit EGB constraints should be accounted for

Rationale

Some people use Incidence Analysis (and/or IDAES diagnostics), some people use ExternalGreyBox. Often these are the same people. It would be nice if these tools worked together.

Things to think about

• IA relies on explicit constraints to get the graph. We'll have to get a separate graph for the "implicit part" of the model then stack the two together. This shouldn't be bad.
• How do we store things in IncidenceGraphInterface.constraints? I.e., "the first row (or first output constraint) of m.gb." We can put anything we want in the list an dict that we cache, so do we just put the tuple (m.gb, 1)? Or do we define some special constraint type that corresponds to an EGB?
• Need to very clearly document what the user can and can't expect to receive as a "constraint" from these algorithms
• Once we put something that isn't a constraint in these data structures, sending them back to IA algorithms (e.g., block_triangularize(vdm.square, cdm.square)) will hit an input validation error. Hopefully this isn't too hard to relax.
• I originally thought that nlp = PyomoNLPwithGreyBoxBlocks(m); igraph = IncidenceGraphInterface(nlp) would be easier since I already have matrix interfaces for most (all?) of the algorithm functions. But IncidenceGraphInterface assumes it can get variables and constraints somehow, and (I think) this is the primary way people interact with IA.

Additional information

While I'm thinking about this, I'd like to remove (or at least deprecate) pynumero.interfaces.pyomo_nlp.PyomoGreyBoxNLP. PyomoNLPwithGreyBoxBlocks, despite the horrible name, is the right class to use. It's really confusing to have two parallel implementations.

[Robbybp]

While I'm thinking about this, I'd like to remove (or at least deprecate) pynumero.interfaces.pyomo_nlp.PyomoGreyBoxNLP. PyomoNLPwithGreyBoxBlocks, despite the horrible name, is the right class to use. It's really confusing to have two parallel implementations.

If we have a reasonable way to represent EGB rows as "constraints", we could even deprecate both of these and just roll the functionality into PyomoNLP. But this is a bit orthogonal to this issue.

[Robbybp]

Some wrapper around ExternalGreyBoxBlock that ducktypes Constraint or ConstraintData seems like the right way to go.