Initial support for array connectors

[pmai]

Dimension elements on connectors. More has to be added to specify connection semantics, etc.

Also needs corresponding changes in the SSV/SSM/... side of things.

[pmai]

Connection semantics and SSV/SSM/... changes to be handled in a separate PR.

[klausschuch]

The number of dimension elements in a connector defines the dimensionality of the array.

[klausschuch]

defines

[DagBruck]

@klausschuch can you explain why you prefer defines?

[DagBruck]

I agree in general, but I had two comments on the feedback from @klausschuch.

[pmai]

I have moved the dimension elements into common, and added array support for SSV and SSB (SSM should not currently be affected, unless we want to enhance transformations to also provide array shape transformations, but even in this case this would likely go into common). This also adds the capability to provide array values for parameters.

I have also implemented the non-controversial subset (0-2) of the connection options of #9, by providing optional startIndices and endIndices attributes on a connection. This currently allows for:

0. Only same-shaped arrays can be connected:+
   No startIndices and endIndices specified
1. from a scalar to a single element of an array: a -> A(1,1).+
   No startIndices, endIndices="1 1"
2. from a single element of an array to a single element of an array: A(1,1) -> B(1,1).+
   startIndices="1 1" endIndices="1 1"

Case 3) (scalar mapped to all elements of an array) could still be allowed, by having no startIndices and no endIndices, and defining this to mean mapping to all elements, but I have not added verbiage to this effect. Case 4) (single element of an array to all elements of an array) could also be handled in this way.

Cases 5) and 6) could be handled by extending the allowed content of the Indices attributes to not only contain indices, but also range expressions, like startIndices="1-5 2-3" or even stardIndices="3-n 4-m" or similar. However again this is not currently part of the proposal and could be added in a later SSP release.

Another approach would be to handle this in Transformations, i.e. adding ArrayTransformations that do reshaping; this would also apply naturally to parameters, which we currently do not handle (except via mapping to parameter connectors, and then using connections). However it seems a bit overkill to always have to provide an ArrayTransformation for the simple cases 1/2, hence the current approach.

[JochenKoehler]

Web meeting 2023-11-24
Decision made to approve the pull requrest. Pierre will do the merge.