Strata icon indicating copy to clipboard operation
Strata copied to clipboard

InterpolatedNodalSurface supports only sparse matrix representations

Open traggatt opened this issue 9 years ago • 1 comments

Sparse matrices may be significantly more memory efficient when handling sparsely populated matrices, however they can be tricky to work with, especially when converting back to their dense form. This involves reducing the x and y axis to their unique values, (probably) sorting, and then population of a 2d array using the indices for the unique x and y values.

One example use case is rendering surface sensitivities to a grid form. A user would typically expect to see these in a tabular layout. e.g.

screen shot 2016-03-17 at 11 40 41

Currently rendering into this form requires the user to go through the sequence of steps described above. Furthermore, due to the way in which the surface metadata is stored, down-casting is required in order to infer the column and row types.

A potential solution may be to add types for dense and sparse matrices, and unify these types via a common interface. The user could then run computations using their preferred data structure. (Probably in most cases, this would be a dense matrix. A sparse matrix would be more desirable for working with very large, sparsely populated matrices).

A dense matrix representation DoubleMatrix already exists in Strata, but it is not possible to use it in surface computations. One possible solution may be to convert DoubleMatrix to an interface and add sparse and dense implementations. Sensitivities would then be reported in the relevant form.

In addition, it would be useful if our dense matrix type could support sparsely populated data. This would allow the user to access the benefits of dense matrices when working with sparse data.

traggatt avatar Mar 17 '16 11:03 traggatt

Just to note that Strata now insists that the x and y values are sorted.

jodastephen avatar Jul 04 '16 19:07 jodastephen