Piro is an immature package that is being 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 Sovlers, Time Integration, Optimization, UQ, Continuation, Multi-Physics Coupling, Network Solvers
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 drivers all can be constructed similarly, with a ModelEvaluator and a ParameterList, to make it simple to switch between different types of analysis. They also all inherit from the same base classes (reponse-only model evaluators) so that the resulting analysis can in turn driven by non-intrusive analysis routines.
The name Piro is an acronym for "Paramters 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 Peublo originally located near present day Socorro, New Mexico.
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 Piro solvers can be constructed using just the ModelEvaluator and a Teuchos::ParameterList, and then can be solved with a single "evalModel" call.
The nonlinear analysis tools that are (or will be) wrapped by Piro include:
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:
To get concrete, here is a typical use case (which can be seen in the test directory).
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 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.