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
Rythmos: Transient DAE solver
Stokhos: Embedded UQ solver for Stochastic-Galerkin over random variables
MOOCHO: Emebedded Optimization algorithms with rSQP algorithms
LIME: Algorithms for multi-physics coupling (under development)

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:

OptiPack: Distributed memory optimization algorithms with line searches
MOOCHO: Distributed memory SQP methods with constraints
Dakota via TriKota: The entire Dakota framework (developed at Sandia independently from Trilinos) is available through the adapters and build system of the TriKota package.

Piro 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 EpetraExt::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 RythmosSolver 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, Roger Pawlowski, and Eric Phipps. Much of the code is adapted from tests and examples for NOX, LOCA, Rythmos, Stokhos, MOOCHO, OptiPack, and TriKota, and was developed and matured in the Albany application code before being library-ized into Piro.