[petsc-dev] coding style

[Munson, Todd]

>> 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.

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 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.  This is 
only a problem with degenerate solutions.  In this case, you can 
provide strongly active and weakly active constraints without 
crossover.

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

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

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

>>> 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.

Todd.