Constraints

[white238]

A place to focus our thoughts on designing how Constraints will be implemented.

[thartland]

I thought it might be good to provide a little background as far as I see it.

serac's EquationSolver focuses on, well, equations of the form F(x) = 0. This problem/equation can be communicated fairly simply through a single mfem::Operator, one can evaluate F via the Mult method and the Jacobian of F, as needed of a Newton solver, via GetGradient.

There are two broader categories of equations that the continuation solvers (interior-point and homotopy) target.

The Newton-based interior-point solver targets constrained optimization problems of the form minimize_u E(u) such that cI(u) >= 0 and cE(u) = 0, where cI represent Inequality constraints and cE represent the Equality constraints.

An example implementation of a constrained optimization problem -- similar to my continuation solvers, mfem creates a problem class (see their OptimizationProblem). This problem class includes a number of methods/member data to communicate the problem, such as Operators for each type of constraint (equality and inequality), methods to evaluate the objective E(u) and its gradient. Ultimately, such a problem, with all the communicated routines for function, gradient, and potentially Hessian computations are passed to a solver.

PETSc's tao is maybe not the best example since it is C based but here one provides function pointer routines and those are passed to the solver, see e.g., here.

Sandia's ROL does something similar where the function/gradient evaluations are wrapped in an Objective object, see e.g., here.

HiOp has a design similar to mfem and my code wherein a class has member functions to evaluate objective/constraint functions and their derivatives. See e.g., here.

For completeness I will mention that the other solver, the homotopy solver, is for nonlinear mixed complementarity problems of the form q(x, y) = 0 and min{ x_i, f_i(x, y)} = 0 for i = 1, 2,..., dim(x). This solver uses evaluates of f and q and first-order derivatives of said functions. I think generally the idea is similar in that a complementarity problem class can be used to pass along the necessary routines to a solver. But for examples here is an example of a complementarity problem in tao.

As mentioned in our meeting earlier the term constraint is an overloaded term that depends on context and with regard to finite element software often refers to constraints via essential boundary conditions that I believe are simpler. Example usage is the mfem::ConstrainedOperator, see here.

[white238]

What can we do today:

• fixed/essential/dirchelet boundary conditions (limited to non-angled walls), for example: add at a node that your temperature is 5
• contact constraints

What are the users needing to do:

• periodic boundary conditions, for example: at a node your temperature is at another node
• can't push through an angled wall
• MPC: generic linear constraint between degrees of freedom, user defined, possibly stored as a sparse matrix
• non-linear integral constraint through Functional

Types:

• equality vs inequality
• bound
• linear
• non-linear

Breakdown of interface:

• defining the constraint
• storing information
• interface to solver
• error checking of correctness (Solver not working with bound)

How do users interface with it:

• ConstraintManager
• BasePhysics
• Physics in constructor as a container of Constraints
• EquationSolver takes a residual and constraint and solves it

[btalamini]

One other element: users need to be able to define coordinate systems and to pass them into the constraints.