[petsc-dev] coding style

[Oxberry, Geoffrey Malcolm]

> On Aug 18, 2016, at 4:52 PM, Munson, Todd <tmunson at mcs.anl.gov> wrote:
> 
> 
>>> Internally the solvers can do lots of stuff.  Most interior point 
>>> methods, for example, would convert any inequality constraints 
>>> into equality constraints by adding slack variables and 
>>> bounding the slacks.  That way they only need bounds on 
>>> variables.
>> 
>> Yes; for instance, KNITRO essentially does this. I’m more concerned about the developer API having consistent semantics. I don’t want to have to remember that I should be flipping signs or assuming implicit zeroes, depending on the method, unless the gains in performance are significant.
> 
> I do not understand this.  The developer API will be the same for all 
> solvers.  What a solver does internally to reformulate is its own 
> problem.  I am more worried about providing consistent 
> information to the users.

As far as I understand it, there is no API for developing constrained optimization solvers yet. When I last looked at the code, I didn’t see fields for duality multipliers in the Tao object, which is why I rolled my own vector of duality multipliers in TAOSQPTR, and why I assume Matt did the same in TAOIPM. I am asking these questions to understand how such an API might be designed, because I may end up adding a pull request implementing parts of it.

> Note: when we get down to writing code and documentation, there will be 
> one definition of the Lagrangian.  I'm not allowing the AMPL model 
> where the user needs to know how the solver defined the Lagrangian 
> to know how to interpret the multipliers.

I agree; I have been thinking about this issue as well, which is why I asked Matt in pull request #506 about some of these ideas.

> 
>>> I believe crossover is only really needed when the problem is 
>>> degenerate at the solution and you need to make decisions to 
>>> find an invertible basis matrix.  If you don't care about
>>> the invertible basis matrix, then its not needed.  [One
>>> reason for wanting the invertible basis matrix is for
>>> parametric sensitivities or for branch and bound
>>> for combinatorial problems.]
>> 
>> Yes, you are correct; those are the cases I was thinking of specifically. Customers ask for this information in practice to get sensitivity information, or to understand which constraints are really active.
> 
> If you have strict complementarity, you know the activities.

I agree.

> This is only a problem with degenerate solutions.  In this case, you can 
> provide strongly active and weakly active constraints without 
> crossover.

Good to know.

> 
> What you are really asking is not what are the multipliers, but what is
> the basis.  They are two separate things.

I agree.

> 
> If you really want a basis, you can either do crossover or simply use
> an active set method to begin with...  :)

Yes.

> 
> Maybe I am missing something.  There is no function in the TAO API to
> return the basis.

There is not a function to return the basis at the moment, but I am thinking ahead because I work with engineers who I anticipate will ask questions re: sensitivity analysis.

> 
>>>> I already do this in SQPTR, although only for the Hilbert space case. Assuming it eventually gets merged, the interfaces need to be revised for norm-reflexive convex Banach spaces so that all inner products become duality pairings. I am not sure if ROL does this, but the Heinkenschloss and Ridzal paper cited in the SQPTR comments suggests this generalization can be made.
>>> 
>>> I think doing things in function spaces is more of a change than I 
>>> want to consider right now.  You would have to start by convincing
>>> the regular PETSc folks to convey the function spaces for their
>>> PDEs…
>> 
>> As far as I know, the only information needed in the Hilbert space approach is matrices denoting inner products and norms. This information is needed for mesh-independent convergence, and presumably for FEM discretizations, you already have this information in the form of mass matrices. If the information is already there, why not use it? As I understand it, this issue motivated Patrick Farrell’s pull request to add Riesz maps to LMVM.
> 
> I currently do not get notifications for pull requests, so have not seen it.  I
> probably need to look at them from the website more often.

Please do. I’m interested in contributing methods to TAO because I like using PETSc, it seems like the most expedient way to get a solver my project can use with features we need, and I have great respect for the software you guys put out. If there is anything I can do to expedite this process, e.g., things I should read/practice, let me know.

> 
> Todd.
>