[LinAlg] Clean-up of sparse algebra wrappers

[maxfirmbach]

Description

Now that some of our sparse algebra wrappers are quite stable, we should think about cleaning them up and take a brief look at how things are done in their Tpetra counterpart:

• Does a respective method still exist?
• Which input arguments does a specific method take?
• ...
• Move error messages into the wrapper itself and directly throw there.

Small example, in Tpetra it's not possible to index a global vector by using [] anymore. So if our wrapper and code would use this, we need to replace it.

This issue is mainly for documentation purpose.

Overview of classes to exchange with Tpetra counterpart:

Epetra	4C	Tpetra	Related issues	ready for switch
Epetra_Vector	LinAlg::Vector<double>	Tpetra::Vector<double>	#1121	❌
Epetra_IntVector	LinAlg::Vector<int>	Tpetra::Vector<int>	#1121	❌
Epetra_MultiVector	LinAlg::MultiVector	Tpetra::MultiVector	#1462	❌
Epetra_FEVector	LinAlg::FEVector	Tpetra::FEMultiVector		❌
Epetra_Map	LinAlg::Map	Tpetra::Map	#1391	❌
Epetra_CrsGraph	LinAlg::Graph	Tpetra::CrsGraph	#1389	✅
Epetra_FECrsGraph	LinAlg::Graph	Tpetra::FECrsGraph	#1389	✅
Epetra_Import	LinAlg::Import	Tpetra::Import		✅
Epetra_Export	LinAlg::Export	Tpetra::Export		✅
Epetra_Operator	LinAlg::SparseOperator	Tpetra::Operator		❌
Epetra_CrsMatrix	LinAlg::SparseMatrix	Tpetra::CrsMatrix		❌
Epetra_FECrsMatrix	LinAlg::SparseMatrix	Tpetra::FECrsMatrix		❌

Possible Solution and Definition of Done

• Verify that the list above is complete
• Open for each of the wrapper an issue and document what seems to be missing or what needs to be changed (or work on it directly)

Interested Parties

[maxfirmbach]

One example of a cleanup are the changes made in #874.

[maxfirmbach]

@dharinib98 @knarfnitram We should remove as many wrapper method calls as possible using Epetra as input.
Example:

    int export_to(const Epetra_SrcDistObject& A, const Core::LinAlg::Export& Exporter,
        Epetra_CombineMode CombineMode, const Epetra_OffsetIndex* Indexor = nullptr)
    {
      return graph_->Export(A, Exporter.get_epetra_export(), CombineMode, Indexor);
    }

I think it should be possible to replace Epetra_SrcDistObject with Core::LinAlg::Graph in this case ... as we are in the respective wrapper.

[knarfnitram]

@maxfirmbach thanks for taking the initiative here. I added a table to gather and visualize all necessary information.
I think it would be to good to first complete this table, that we have a complete overview of all objects and do not forget one. I marked some classes with ?, please check if I have added there the proper Tpetra object.
Then I'd really open an issue for every object and add all respective functions which needs to be first checked and then ported.
Can we already include Tpetra in 4c, such that we could have small test cases to slowly transit functionalities or are we one still one step before that?

[knarfnitram]

@maxfirmbach - one question regarding the [ ] operator. Since within Tpetra it should be distinguished if a vector is allocated within the memory of the host or device, we need either to remove the []-Operator or provide an implementation for it within the Tpetra- wrapped object (Vector is using it, matrix as well?) . Our code currently assumes to be executed within the the host space.
Do we replace the []-Operator either by a function something called local(int lid) and desing our interfaces towards the Trilinos interfaces or do provide a more "simplified interface" provide in a first step the implementation for [] based on the get1dView() of the Tpetra object in host space ?
Since replacing the function might be similar for Multivector, Vector and FE_Vector, I think it would be good discuss it once and then try to stick with the strategy as good as possible.

[maxfirmbach]

@knarfnitram Thanks for the nice overview!

Here's my take on it. I think we should avoid calling [ ] on vectors in general, like myVector[i]. There's a reason why it's not implemented in Tpetra, due to the host vs device issue. I would also like to avoid implementing such things by ourselves.
Normally it's done like:
myVector->getLocalHostData()[i] ... or myVector->getLocalDeviceData()[i], so operating on a pointer to the local data, we should do the same now, if possbile with Epetra.

I would also avoid having Epetra and Tpetra code at the same time in 4C. We could think of having some kind of epetra_to_tpetra converter (and vice versa) for the code transition, but that should never make it into the main code. Ideally we have on PR with Epetra -> Tpetra with whatever helper functions we need in between.

I have the feeling that we are not there yet. Thus I propose to make everything pretty and tidy, think about what is missing, what is necessary for a switch, document that and then proceed with intermediate steps.

[knarfnitram]

thanks for the clarification, I opened an issue regarding the Epetra_Vector.
We are missing the Epetra_IntVector, but I assume we will convert it to a Tpetra::Vector<int> ?

[mayrmt]

@knarfnitram we won't need a specialized int vector class anymore, since we will just template the scalar type to int as you suggested.