Skip to content

Thyra epetra adapters refactor

James Willenbring requested to merge bartgol:thyra_epetra_adapters_refactor into develop

Created by: bartgol

@trilinos/thyra @trilinos/epetra

Description

This PR introduces new interfaces for the Thyra-Epetra adapters, so that they are the analogue of the Thyra-Tpetra ones. In particular, the new interfaces act as 'wrappers', and the conversion Epetra->Thyra->Epetra is indeed an identity map. This addresses issue #3 . The new interfaces are not enabled by default. To enable them, one needs to set ThyraEpetraAdapters_ENABLE_Refactor to ON in the cmake configure script. If not enabled, the old interfaces are still available.

Note: I fixed as much code as I could, to work with the new interfaces. However, I didn't enable the whole Trilinos. I will fix issues as the autotester brings them up. It is worth notice that places that use Thyra-Epetra interfaces are likely filled with #ifdef HAVE_THYRA_EPETRA_REFACTOR guards, to switch between old and new interface. This is not really good looking. I tried to keep some interfaces the same as the old ones, even though I do not fully understand (or agree with) them. For instance in the LinearOp, whose initialization method takes supportsAdjoint as input (while I would let the LinearOp verify whether or not it is supported, by testing transpose support in the wrapped Epetra op). Also other interfaces have the same signature, even though the naming convention differs from the rest of the subpackage. E.g., Thyra::get_Epetra_Opertor in Thyra_get_Epetra_Operator.hpp can be easily replaced by Thyra::EpetraOperatorVectorExtraction::get(Const)EpetraOperator, but keeping it has allowed to lower the amount of places where I needed an ifdef for the new implementation. Ideally, I would remove them later on though.

Motivation and Context

The root of this PR is in issue #3 . See discussion therein for more details.

Related Issues

  • Closes #3

How Has This Been Tested?

I added a testsuite for the new interfaces, by adapting the testsuite found for the tpetra adapters.

Checklist

  • My commit messages mention the appropriate GitHub issue numbers.
  • My code follows the code style of the affected package(s).
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the code contribution guidelines for this project.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • No new compiler warnings were introduced.
  • These changes break backwards compatibility.

Additional Information

The new interfaces require a new cmake option to be enabled. I am not sure how the autotester can handle this.

There is one test currently failing in Stratimikos. I'm chasing it, but I wanted to put the PR up so I could start getting feedback.

Merge request reports