[petsc-dev] coding style
Oxberry, Geoffrey Malcolm
oxberry1 at llnl.gov
Thu Aug 18 19:28:04 CDT 2016
> 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.
>
More information about the petsc-dev
mailing list