Evaluate the use of NumericConstants

[whart222]

There is a fundamental conflict between the use of NumericConstants in Pyomo and the design of the matrix constraint.

A Constraint component represents lower and upper constraint bounds with NumericConstant objects that wrap numeric values. Thus, the lb/ub methods return objects that can be interrogated in a standard manner (e.g. is_potentially_variable()).

A MatrixConstraint component represents lower and upper constraint bounds as arrays of numeric values. Thus, the lb/ub methods return numeric values.

I don't see an obvious way to reconcile this design differences. I'm leaning towards allowing bounds to be numeric values.

But I don't see how we can represent matrix constraints where bounds are non-variable expressions (i.e. that include mutable parameters). Is that possible?

[ghackebeil]

In Kernel, the constraint component does not wrap the lb and ub properties on assignment. It does call as_numeric on what is being assigned, but this is only done so that it can assert the argument is "not potentially variable".

As with assignment to the expr attribute on named expressions, I think the more intuitive behavior for users is to not change the object they assigned to properties like this, so that they will not be surprised when using that property. E.g.,

c = constraint()
c.lb = 5
if c.lb <= 5:
    ...

I don't think something like this should result in an exception (it would if we converted 5 to a NumericConstant).

[whart222]

@ghackebeil I like your example.

It occurs to me that the core issue here is that sometimes we want to think about our modeling environment w.r.t. expressions, and sometimes w.r.t. matrices/vectors/numbers. It could be that that is the core difference between a kernel layer and an AML layer.

BUT, that start's looking like two modeling environments; already kernel has that feel to me.

As an example, what would it mean for a user to define a set of constraints:

A x == b

where (1) A and b are matrices and vectors (i.e. with only numeric values), or (2) where A and b are modeling components for matrix and vector-like things where elements can be expressions? In (1), it's clear how a user would create numerical algorithms directly with the model. In (2), the user should expect to translate their model in some manner before passing it to a numerical algorithm.

But do we treat these separately in Pyomo? Or allow the user to specify both types and require the transformation only when necessary?

[jwatsonnm]

I will argue here for co-existence. As a motivating exemplar, I would like the ability to translate between the AML and kernel layers. We have a lot of problems in which a large chunk of the model is invariant or at least very stable. And despite this, we re-build these chunks over and over and over - with the associated build time and memory expense. An alternative would be to "compile" said things into the kernel layer once we are happy with them. And then we could perform very fast (well, at least faster than standard Python) I/O, e.g., by going through numpy. Memory reductions would also be a plus.

[whart222]

@jwatsonnm But would we need/want mixed models? For example, models where some components are type (1) and some are type (2)? Or for simplicity would it make more sense to convert from (2) to (1). We're not really doing that today, which is why I ask.

[jwatsonnm]

Yes - I am arguing for models with mixed types of components. I think we would want to convert from AML to Kernel, and then embed the resulting Kernels in AML models. I do not think converting from kernel to AML is useful, in that the symbolics are gone once you convert to kernel.

[whart222]

If we're going to support mixed types of components, then it seems natural for us to have symbolic components - like our AML models - and numeric components - like Kernel. I'm OK tentatively closing this ticket if others agree that that plan seems desirable. But I think we need to have a separate design discussion regarding this type of distinction and the pros and cons.

[whart222]

FWIW, I like thinking about this as a means towards performance optimization. I could even imagine having decorators for stable parts of a model with which kernel-level representations are automatically generated. Hmm...

For example, supporting mutable parameters is expensive. So there are real wins to be had by generating a mathematically structured problem representation (e.g. linear constraints).

[carldlaird]

Not sure that the separation between AML and kernel is "symbolic" vs "numeric". I don't understand this distinction.

[whart222]

@carldlaird For example, is a lower or upper bound value always a number or could it be a pyomo expression.

[jwatsonnm]

I like the idea of decorators being used to automatically compile stable parts of the model. "Hmm" indeed!

[michaelbynum]

I thought the goal was to merge AML and kernel so that kernel is used under the hood, making kernel and AML models compatible. Is it valuable to maintain both AML and kernel separately long term? Maybe I don't fully understand the discussion...

[whart222]

@michaelbynum Yes, that's the plan. But we need to resolve discrepancies like this if we're going to do that merge. OR, we could decide to not merge. (Though, if we go down that route, there are important design ideas we need to use from kernel to rework the AML.)

[mrmundt]

In an effort to clean up old issues, we are moving some design discussions to our Archived Design Discussions wiki.