Allow to define user-specified status tests for multiphysics problems in Belos

[tawiesn]

Add a status test which allows to check the norm of a subvector of the residual vector for multiphysics problems (i.e., if the operator is a n x n block matrix from Thyra or Xpetra) in the status test framework of Belos. This shall not replace the existing status tests. It is meant to be used by the user in the user-specified status tests to gain a better insight of the convergence properties of the single fields in a multiphysics problem

[tawiesn]

Implemented a new status test "StatusTestGenResSubNorm" which allows to check the norms of sub-vectors of the residual vector. So far it is only working with Thyra::BlockedLinearOp and Thyra::ProductMultiVector based objects. Support for Xpetra will follow. This issue cannot be closed as long as we have no generic way to set up application-specific status tests as this status test is not supposed to be part of the currently existing set of status tests for GMRES and other solvers in Belos. See #162

[amklinv]

I just made a commit that allows you to replace the status test in FixedPoint; I'll add it to the other solvers later. Just to make sure, you want to: A) replace the Belos convergence test with yours? or B) use both the traditional Belos status test AND yours?

[tawiesn]

Thanks for the info. I think i tend to A), i.e., replace the Belos convergence tests with my own. This is related to issue #162, since i'd like to define the status tests using an xml framework. I think it would be very confusing (especially for external users) if you define your status tests in your xml file and then there are still the hard-coded status tests which might kick in and change the behavior of the solver. The idea would be to let the user choose whether he either wants to use the hard-coded already existing status tests which are probably good for 80% of all people or define his own status tests.

[mhoemmen]

Hi @tawiesn -- when you take "subvectors" (presumably in the manner of offsetView), you must need to use the Epetra / Tpetra / Thyra interface directly, rather than Belos'. If so, what happens if the multivector type (the MV type in Belos::MultiVecTraits) is something else other than Epetra, Tpetra, or Thyra? You can't actually fix the general case, but the general case should still compile (you can throw std::logic_error).

[tawiesn]

@mhoemmen: Yes, that is correct. I already have it for Thyra (it's not committed, yet), since that is what i actually need to use it with drekar on some multi physics problems. All the packages somewhere have the Belos adapter which provides a specialization of the MultiVecTraits<Scalar, MV> class. It's working fine so far and i also have a unit test for it. I will also implement it for Xpetra, since Xpetra also has support for blocked operators (similar as Thyra). So far, i throw errors for the pure Epetra and Tpetra adapters. I don't think it would make sense to implement this feature there, as Epetra and Tpetra do not support blocked operators in the multi physics sense. The interesting question now is how to properly include these types of status tests in Belos. I'm dreaming of a general parameter-list based way to define a tree of status tests (similar to what NOX can do). The existing status tests in Belos are solver-specific hard-coded and not so easy to replace by user-specified. I've set up a meeting with Heidi and Alicia on Monday to discuss this issue (see also #162). Btw: Belos has a StatusTestFactory that you've implemented in 2011. As far as i can see it is not used at all. Do you know whether this piece of code is used (maybe outside of Trilinos?)

[mhoemmen]

So far, i throw errors for the pure Epetra and Tpetra adapters. I don't think it would make sense to implement this feature there, as Epetra and Tpetra do not support blocked operators in the multi physics sense.

I agree. Neither Epetra nor Tpetra provide cross-product compositions of operators, like Thyra does, so there's no idea of "the k-th block" of a vector in Epetra or Tpetra.

Belos' use of a traits class (rather than inheritance) for MV and OP operations hinders the implementation of MV / OP - specific status tests. Turning compile-time errors into run-time errors, as discussed above, is the best work-around.

[mhoemmen]

Btw: Belos has a StatusTestFactory that you've implemented in 2011. As far as i can see it is not used at all. Do you know whether this piece of code is used (maybe outside of Trilinos?)

Sounds like one of those things I wrote as part of an effort to standardize status test creation in the various Belos solvers. Alas, I never had a chance to finish that effort. Belos was (still is) a big mess of copy-and-paste, and when I tried untangling it, all the subtle semantics got messed up. 2011 was before I realized putting things into a public namespace before they are ready is a bad idea. If you can redeem the class, go for it.

[rppawlo]

We did use the abstract StatusTest class in Belos for some research with nox. This was back in the MPSalsa and Charon1 time frame. So at some point it did work. Haven't used it recently.

[tawiesn]

PseudoBlockGMRES has now support for user-specified status tests. Support has to be added to (all) other sovler managers.

[warsa]

@hkthorn Do you know if this has this been done yet or will be done? In browsing the documentation, I still only see it for PseudoBlockGMRES, even in the dev version. If you remember, I would also need to get access to the underlying Iter object of all the SolverManagers, as you suggested for getting the current residual norm at ever iteration.

[github-actions[bot]]

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[bot]]

This issue was closed due to inactivity for 395 days.