[WIP] broke getGlobalRowView

[tjfulle]

No description provided.

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@71600fd). Click here to learn what that means.
The diff coverage is 82.03%.

@@            Coverage Diff            @@
##             master     #216   +/-   ##
=========================================
  Coverage          ?   34.38%           
=========================================
  Files             ?       33           
  Lines             ?    13444           
  Branches          ?        0           
=========================================
  Hits              ?     4623           
  Misses            ?     8821           
  Partials          ?        0

Impacted Files	Coverage Δ
src/tpetra/test/test_tpetra_crsmatrix.f90	100% <100%> (ø)
src/tpetra/src/fortpetraFORTRAN_wrap.cxx	21.21% <61.22%> (ø)
src/tpetra/src/fortpetra.f90	31.94% <71.42%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 71600fd...b130163. Read the comment docs.

[tjfulle]

@aprokop, to be consistent with Tpetra, we could make a non-member getGlobalRowView procedure that mimics the C++ member version. Something like:

subroutine getGlobalRowView(A, gblrow, cgview, csview)
   type(TpetraCrsMatrix), intent(in) :: A
   integer(global_ordinal_type), intent(in) :: gblrow
   real(scalar_type), dimension(:), pointer :: csview
   integer(global_ordinal_type), dimension(:), pointer :: cgview
  cgview => A%getGlobalRowIndicesView(gblrow)
  csview => A%getGlobalRowValuesView(gblrow)
end subroutine

[aprokop]

Hmm, ok. @sethrj Is it possible to inject code fragment into the Fortran wrapper for a specific class?

[sethrj]

Yes, there are several ways it could be done. If the function signature can be automatically converted correctly from C++ then it's best to use %extend on the class, then you can add code to the proxy function with %fortranappend or %fortranprepend. Or, you can replace the function call in the proxy code entirely using %feature("shadow").

The most manual solution is to extend the fortran class by manually extending the proxy code. I think it would look like this: one fragment adds to the module code, the second injects code into the class type definition.

%extend TpetraCrsMatrix {
%proxycode {
subroutine tpetracrsmat_getGlobalRowView(A, gblrow, cgview, csview)
   type(TpetraCrsMatrix), intent(in) :: A
   integer(global_ordinal_type), intent(in) :: gblrow
   real(scalar_type), dimension(:), pointer :: csview
   integer(global_ordinal_type), dimension(:), pointer :: cgview
  cgview => A%getGlobalRowIndicesView(gblrow)
  csview => A%getGlobalRowValuesView(gblrow)
end subroutine
}
%insert("ftypes") {
getGlobalRowView => tpetracrsmat_getGlobalRowView
}
}

[sethrj]

The workaround I posted is not valid with the latest SWIG versions.

I've updated the contents of @tjfulle's test and pushed to a new branch at https://github.com/sethrj/ForTrilinos/tree/fix-getGlobalRowView . It looks like the test now fails to compile, so that's a plus. I think it'll just be a simple matter of creating a new SWIGTYPE for "arrayview by reference".

[sethrj]

Closing due to inactivity