Support 64-bit local indices in Tpetra & downstream packages

[mhoemmen]

Original e-mail to trilinos-users:

We would like to use Tpetra, Belos, Amesos2 and MueLu with both local
index type = long and global index type = long. Unfortunately, this does
not appear to be supported out of the box, at least I couldn't find the
right CMake settings.
I suppose I have to manually instantiate all the required classes with
the appropriate types or is there another way?
At the moment I am getting undefined symbol errors at runtime in our
project such as (demangled):

MueLu::TpetraOperator<double, long, long, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::OpenMP, Kokkos::HostSpace> >::getDomainMap() const

[mhoemmen]

I suppose I have to manually instantiate all the required classes with
the appropriate types or is there another way?

As a possible temporary work-around, you could try disabling ETI (-D Trilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=OFF), then just try using LocalOrdinal = long. At some point, we will need to add CMake options to enable other LocalOrdinal types, so that they work with ETI ON.

[mhoemmen]

btw I would recommend using long long instead of long. C++11 and C99 guarantee that long long has >= 64 bits. long may have 32 bits on some platforms.

[wfspotz]

For PyTrilinos, I thought it might be nice for the ordinals to match the Python integers, which are long (I should double check the exact type used by Python: long, or long long, or something else?). This would reduce the chance for overflow, and reduce the required error checking for the wrappers. What I am not going to support is multiple ordinal types in Python. I might abstract the local ordinal type out so that it is only specified in one place. Then we can start with local ordinal = int and graduate to long long (or whatever is appropriate) when it is better supported.

[mhoemmen]

What I am not going to support is multiple ordinal types in Python.

@wfspotz That's perfectly OK :-) Once we can support one LocalOrdinal type other than int, we can support others with little extra effort. I prefer long long because it is always (at least) 64 bits, but long isn't hard to add either.

[cihanuq]

@mhoemmen Your recommendation to use long long instead of long is sensible, however in our software we had issues with third party libs (namely, umfpack and netcdf) which both don't appear to support long long by default, unless on Windows.

[github-actions]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity.
If you would like to keep this issue open please add a comment and remove the MARKED_FOR_CLOSURE label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE.

[github-actions]

This issue was closed due to inactivity for 395 days.