Have a look at POEMs 48 and 49

Introducing two new proposals for OpenMDAO enhancement (POEMs), for your consideration. Both are fairly low impact, though POEM 049 does propose removal of some unused APIs.

POEM 048: MetaModelSemiStructured Component

OpenMDAO Already has both structured and unstructured metamodel components. You might think that those two are the all you would ever need, but there is a semi-structured data format that is fairly common (at least in the aircraft design world). This kind of data is useful for things like performance tables where you can’t necessarily get valid data on a full structured grid. The data looks like this:

x = 1
    y = 1, 2, 3, 4, 5, 10, 11
    z = 10, 20, 30, 40, 50, 100, 110
x = 2 
    y = 1, 2, 3, 4, 5, 10, 11
    Z = 60, 80, 100, 200, 220
x = 3
    y = 1, 2, 3, 4, 5, 10, 11
    z = 300, 330, 120, 150, 300, 330

The independent values are always monotonic, but the dependent data does not necessarily have to be. Despite being non-structured, the monotonic inputs allow for the same kind of recursive interpolation that OpenMDAO’s MetaModelStructuredComp uses.

POEM 049: Removal of the matrix-matrix derivative APIs.

While this POEM does propose a backwards incompatible change, to the best of our knowledge no one is actually using these APIs. If you are using them and want to object to their removal, now is your chance! Please comment on the POEM PR and provide us an example use case where you really need to have it.

These APIs date back to early OpenMDAO V1 days when performance for serial components that provided a dense partial derivative Jacobian were very poor due to some slower internal data formats and the lack of a DirectSolver. At that time, our solution involved augmenting the matrix-vector product APIs with a matrix-matrix product API that would skip a particularly slow OpenMDAO for-loop. It worked to an extend, but was not a very general solution.

Today we have both sparse and dense assembled Jacobians that provide better overall performance in a wider range of use cases. We believe these older matrix-matrix features are not needed, and removing them will simplify several places in the code and make our linear solvers more easily understandable.

If you think otherwise, please speak up. We’d appreciate you providing a use case that shows how the matrix-matrix APIs are significantly faster than using the an Assembled Jacobian and LinearRunOnce or DirectSolver.