Outline

Disclaimer for Beta-Release in Trilinos 11.4

Piro is an immature package that was released for the first time as part of Trilinos 10.2 in March-April 2010. At this point, any expectations of documentation, full algorithmic coverage, and backward-compatibility should be limited.

Piro Keywords: Nonlinear Solvers, Time Integration, Optimization, UQ, Continuation, Multi-Physics Coupling, Network Solvers

Introduction

Piro is the top-level, unifying package of the Embedded Nonlinear Analysis Capability area. The main purpose of the package is to provide driver classes for the common uses of Trilinos nonlinear analysis tools. These so-called Solvers all can be constructed similarly, with a Model Evaluator and a parameter list, to make it simple to switch between different types of analysis. As Reponse-Only Model Evaluators, they also all derive from the same base classes so that the resulting analysis can in turn be driven by non-intrusive analysis routines.

The name Piro is an acronym for "Parameters In -- Responses Out," which is a Tarzan-grammar description of the abstraction for a solved forward problem. It also is the name of a Native American Pueblo originally located near present day Socorro, New Mexico.

Piro Description

Piro attempts to unify the usage of the nonlinear analysis capabilities in Trilinos. It requires that the application code present itself using the ModelEvaluator interface abstraction (either the Thyra or EpetraExt version). The different Piro solvers can be constructed using just an instance of Thyra::ModelEvaluator (or EpetraExt::ModelEvaluator) and a Teuchos::ParameterList, either directly or via a factory for Thyra-based models (and the Epetra counterpart) for added flexibility. Once created, the resulting solved models can be evaluated with a single evalModel call, or alternatively via the forward solve routines included in Piro.

The nonlinear analysis tools that are (or will be) wrapped by Piro include:

NOX: Nonlinear Solver
LOCA: Continuation and Bifurcation Analysis Solver
ROL: Tools for Numerical Optimization

Each of these solvers not only takes a ModelEvaluator as the interface to the application code, but also itself inherits from the ModelEvaluator interface. These are of the ResponseOnlyModelEvaluator variety (which is currently a class in Thyra, but just a useful description for EpetraExt). A ResponseOnlyModelEvaluator takes parameters as inputs and produces responses as output (hence the PIRO acronym). In general, it may also produce gradients of the response with respect to the parameters, and, in the future, Hessians.

As a ResponseOnlyModelEvaluator, any Piro solver will satisfy the interface for non-intrusive optimization and UQ algorithms. In Trilinos, these include:

provides convenient driver routines that perform the analysis of a ResponseOnlyModelEvaluator (including Piro solved models) using any of those package.

Piro Use Case

To get concrete, here is a typical use case (which can be seen in the test directory).

Wrap your application code in an ModelEvaluator, taking a solution vector and parameters as input, and producing a residual vector, Jacobian, and response (interpreted as an objective function).
Construct this model, and use it and a parameter list (specified in an XML file) to construct a NOXSolver.
Call the analysis routine with this solver and a parameter list to perform optimization of this model.
Add support for time dependence to your model, construct the TempusSolver instead, and repeat optimization for transient application.

Model Evaluator Confusion

The design of Piro leads to confusion, because the ModelEvaluator is the interface abstraction at two levels. The full ModelEvaluator (that takes a statevector as input and returns a residual) is the abstraction around the users application. The Piro Solvers (typically nonlinear or transient) eliminate the statevector so that the residual is satisfied, and present themselves as a ModelEvaluator as well (in this case, the ResponseOnly variety) for non-intrusive algorithms.

This design allows for flexibility, particularly in expanding this coupling beyond two levels. For instance, multi-physics coupling algorithms can combine separate models into a single coupled model. A UQ study of a coupled model with transient heat transfer and quasi-steady fluid flow, could involve ModelEvaluators at 4 levels, and not just two.

Piro Contacts

Piro is developed by Andy Salinger, Roscoe Bartlett, Todd Coffey, Kim Liegeois, Roger Pawlowski, Mauro Perego, Eric Phipps and Irina Tezaur. Much of the code is adapted from tests and examples for NOX, LOCA, and was developed and matured in the Albany application code before being library-ized into Piro.