[Trilinos-Users] [EXTERNAL] Mikado: Easy access to solvers

Bartlett, Roscoe A rabartl at sandia.gov
Thu Aug 4 11:10:21 EDT 2016


From: Nico Schlömer [mailto:nico.schloemer at gmail.com]
Sent: Thursday, August 04, 2016 8:15 AM
To: Bartlett, Roscoe A; trilinos-users at trilinos.org; Trilinos Developers List
Subject: Re: [EXTERNAL] [Trilinos-Users] Mikado: Easy access to solvers

Thanks Ross for your comments!

You're right, of couse: Mikado actually uses Stratimikos for its Belos interface. I think at the time I wasn't able to figure out how to use Amesos2 or MueLu with it, which was one of the motivations for me to write that wrapper. (And it's thin indeed, just a few hundred lines of code – exluding tests.)

[Ross] You inject them at runtime.  For MueLu, this requires just a two lines:

# include “Stratimikos_MueLuHelpers.hpp”

[Ross] It does not look like anyone has written they Thyra adapters for Amesos2 yet.  That should not be very hard to do.

[Ross] The one problem with the current way that this runtime registration works is that you don’t see the parameter list documentation for these shown here (look at the drop-down for “Valid Parameters”):


[Ross] We need to move to an approach of static initialization and set up processes to generate complete PR documentation and make sure it gets regenerated every day automatically.

I've added a YAML reader yesterday, so perhaps that'll satisfy the use case you're talking about. I never found that terribly interesting because the run times are so much longer than the compile times for my typical applications. Whatever, it wasn't too hard to add.

[Ross] MueLu has a YAML reader and converter to Teuchos::ParameterList as well also based on the yaml-cpp TPL:


[Ross] We just need to pull this YAML to PL converter into Teuchos proper and add some unit tests.  (It does not look like the converter that you wrote has any unit  tests which are needed for sustainability.)

The parameter specification is something I thought would be less verbose than the TeuchosParameterList. I'm quite happy with it in that it feels quite natural to type, and also is small in code. The heavy lifting is done by boost::any (soon to be std::any).

[Ross] I have to admit it looks nice, but not a nice as a real JSON file or Python dict.  But for raw C++, is not too bad.  This syntax was not really possible before C++11.

You're also rightfully pointing out that Mikado isn't as powerful as Stratimikos in some respects. That's alright, too, I guess. Mikado is meant for "simple" solves with as little interface syntax as possible. No DefaultLinearSolverBuilder, createLinearSolveStrategy, lowsFactory, Thyra::MueLuPreconditionerFactory, etc.

[Ross]  What if we could layer these things (like an onion) so that something like Mikado was the simplest interface for the most basic use case but then when people needed more, they could peel back the layers and get more functionality as needed?  The problem with Mikado right now is that it goes straight from the simplest of PL-driven interfaces right down to the rawest package-specific code.  The Thyra interfaces mentioned above are needed to satisfy all the use cases described here:


[Ross] What is a Mikado user supposed to do when they need to reuse the constructed preconditioner factorization structure between solves or needs to share the same preconditioner between two different (but very close) forward operators?  With the current Mikado, they would have to scrap Mikado and hard code to a specific iterative solver and preconditioner.   If Mikado called Stratimikos, then they could just go to Stratimikos/Thyra interfaces with the exact same parameter lists!  And that is the key, it needs to be the exact same PL so that the user who is running the code and is providing the YAML or XML PL file never needs to worry about what is happening under the covers with all the C++ code.

That said, if any of these things was to go into Teuchos/Stratimikos, I certainly wouldn't oppose it.

[Ross] I can see Mikado staying its own package it its own git repo but allow it to build either with Trilinos (as an inserted TriBITS package) or as its own independent downstream CMake project (like it does now).  That seems like a win win for everyone involved.

[Ross] I will also note that Mikado could be updated to use Piro as well to access nonlinear solves in the same onion approach.  But I am not as familiar with Piro so I will defer that to others.

[Ross] If we can find some time next week, can we talk about an interface like Mikado might integrate with the rest of Trilinos?


On Tue, Aug 2, 2016 at 8:30 PM Bartlett, Roscoe A <rabartl at sandia.gov<mailto:rabartl at sandia.gov>> wrote:

It looks like Mikado is a duplicate of Stratimikos with the following differences:

1) Mikado uses C++11 features with boost::any to allow simpler specification of a Teuchos::ParameterList directly in C++.   It would be be fairly easy to take that conversion code and move it into Teuchos (the only hard part are the unit tests). But in reality, people should not have to recompile their application all the time to change solvers and preconditioners.  With Teuchos::ParameterList, you can supply an XML file and in the near future, there will be a YAML format supported (which is used by MueLu currently I think).

2) Mikado is hard-coded to several solvers and preconditioners but does not allow for extension.  It does not abide by the Open-Closed Principle (OCP).  (Stratimikos allows you to register new linear solvers and preconditioners at runtime.)

3) Mikado can’t build and install as part of a Trilinos build.  People have to build and install Trilinos first and then separately configure, build, and install.  After the refactoring TriBITS #63<https://github.com/TriBITSPub/TriBITS/issues/63> is complete, then it will be fairly easy to build and install a package like Mikado either with Trilinos (as an added package) or downstream from Trilinos as its own CMake project.  (Actually, you already do that as was demonstrated with the XSDKTrilinos package.  It is not that hard to do even now.)

4) Mikado his hard-coded to Tpetra.  It can’t accept  Epetra objects as well.

5) Mikado only supports solving a single linear system.  It does not take into account solving a sequence of similar linear systems, solving more than one linear systems at the same time that shares the basic structure (and perhaps preconditioners), etc.

I would argue that the identical Mikado interface could just be a thin wrapper around Stratimikos::DefaultLinearSolverBuilder and would be a much smaller amount of code and would allow for extension of new solvers and preconditioners at  runtime.  Would you be willing to discuss that option?  Actually, now is a good time to discuss this if you are interested.

Given the listed BSD -3Clause license, I think this type of thing would be possible.



Dr. Roscoe A. Bartlett, PhD
Sandia National Laboratories
Trilinos Software Engineering and Integration Technologies Lead
Consortium for the Advanced Simulation of Light Water Reactors (CASL) Physics Integration Infrastructure Lead

From: Trilinos-Users [mailto:trilinos-users-bounces at trilinos.org<mailto:trilinos-users-bounces at trilinos.org>] On Behalf Of Nico Schlömer
Sent: Tuesday, August 02, 2016 12:27 PM
To: trilinos-users at trilinos.org<mailto:trilinos-users at trilinos.org>; Trilinos Developers List
Subject: [EXTERNAL] [Trilinos-Users] Mikado: Easy access to solvers

Hi everyone,

I've recently invested some time to make access to (Tpetra) solvers in Trilinos easier. Fruit of the labor: Mikado [1]. It has helped me a great deal, maybe the same is true for you.

As usual: Hints and suggestions welcome!


[1] https://github.com/nschloe/mikado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://trilinos.org/pipermail/trilinos-users/attachments/20160804/96080c0e/attachment-0001.html>

More information about the Trilinos-Users mailing list