Interoperability between static and dynamic rank views

[etphipp]

With the DynRankView and View now being used in a bunch of code together, interoperability between the two is becoming an issue. In particular some code only works with DynRankViews, other code only works with View's, and the user has a mixture of the two. Thus it would be nice if you could:

• Assign a DynRankView to a dimension compatible View and vice versa
• deep_copy() between the two
• Compute the rank in an agnostic fashion: DynRankView has a rank() function but View has a rank enum. Often the only thing preventing code from working with both is this difference in how the rank is computed. Since View already has an enum called rank, you probably can't add rank() as a member function. So maybe a non-member function Kokkos::rank(v) with overloads for View's and DynRankView's?

[etphipp]

@kyungjoo-kim

[hcedwar]

The DynRankView is supposed to be a temporary workaround (hack) until Intrepid2 can be refactored to remove the requirement for dynamic rank view.

[etphipp]

That's part of the reason why you need interoperability. Only parts of the code are refactored, so you need a way to convert between the two.

Even so, the DynRankView will have general utility, so it would be a shame to get rid of it after Intrepid2 (and the codes that use it) have been refactored.

[kyungjoo-kim]

Oh... I thought that the dynamic rank view is a permanent solution that everybody uses the same container among different packages, i.e., panzer, intrepid, drekar and albany. I don't think that we remove dynrankview after refactoring; introducing dynrankview is part of refactoring.

assignment between dynrankview and view may not be possible. but deep_copy should be okay if kokkos supports it.

[rppawlo]

I too was under the impression that DynRankView is a permanent thing. I certainly believe that the bracket operator should be removed once the intrepid conversion is done, but as Eric said, DynRankView is very useful.

[ndellingwood]

When assigning a view to a dynamic rank view, make sure padding carries through.

[ndellingwood]

Brief update: @hcedwar @crtrott @rppawlo @etphipp @kyungjoo-kim
Working on the some of the interoperability feature requests (subdynrankview to subview, copy and assignment of View to DynRankView) started to require multiple design workarounds, including some unacceptable within the Kokkos View (e.g. exposing the shared allocation tracker). After talking with Carter, the best route forward will be to redesign the DynRankView so that it no longer privately inherits the rank 7 View but will essentially be a new form of View (rank 7) that shares most all of its internal implementation with the original View.

[ndellingwood]

@etphipp @rppawlo
The following features were added with #359

DynRankView redesigned to be its own View implementation
Added features:

• Copy, Copy-assign View to DynRankView
• deep_copy between Views and DynRankViews
• subview function name now enabled (subdynrankview has same functionality)
• Common method to request rank of a View and DynRankView: rank(user_view); This will eventually be replaced by a constexpr rank() in the View, but this will require coordination with packages and apps to avoid breaking their builds.

Important!
Before merging into Trilinos corresponding changes in Sacado must also be made as those in the attached patch file. Otherwise compatibility will break.

sacado-mod-drvredesign-7.patch

[ndellingwood]

The patch didn't seem to go through, one more try...

sacado-mod-drvredesign-7.patch.txt