Framework must enable automatic array transformations

[climbfuji]

For expediency when porting physics into CCPP and testing them with various host models, the framework must enable automatic array transformations.

For example, MPAS arrays that are in (k,i) need to be converted to (i,k) automatically.

This is a post-capgen-unification task.

[gold2718]

Can you be more specific as to the desired semantics?
Where can which arrays be found? Host model? Schemes?
Can a scheme have a mix of array types?

[climbfuji]

Can you be more specific as to the desired semantics?
Where can which arrays be found? Host model? Schemes?
Can a scheme have a mix of array types?

In my thinking, these automated array transformations are basically the same as unit conversions or blocking/deblocking operations in terms of how to encode this in the framework. Upon inspection of the dimensions attribute and comparing it between host model and scheme, the framework decides on a case-by-case basis if a transformation is required.]

This way, one could have schemes that expect arrays with different index ordering (between themselves and compared to the host model) and it will just work fine. We have one example in the current ccpp-physics, namely the GFDL-MP saturation adjustment (fast physics). All but one incoming arrays have some sort of

(x,y,z)

index ordering (with different extents, because some have halo cells, some have not, but this is another story), and one has

(x,z,y)

(The FV3 dycore defines these arrays as such, hence no transformations needed at the moment.) Of course the index ordering can be changed if necessary, in particular for performance reasons to avoid data copies. But for expediting the porting and testing being able to handle these cases would be beneficial.

[mkavulich]

It's possible that this already works? @dustinswales will check.