[petsc-dev] coding style

[Oxberry, Geoffrey Malcolm]

> On Aug 18, 2016, at 7:58 PM, Munson, Todd <tmunson at mcs.anl.gov> wrote:
> 
> 
>>> 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.
> 
> The part of the API inside of TAO related to multipliers is the computedual
> operation.  Right now, its only defined for bound constrained problems and
> needs to be fixed for general constraints.

Thanks for the heads up! This information is good to know.

> 
> But if we are going through the effort of refactoring the code, we might as 
> well attempt to have a proper redesign of the code before I start "fixing"
> everything.  Think about requirements and usability, simplicity for 90% 
> of the users, playing well with the PETSc philosophy, ...
> 
> I don't think Matt did the TAOIPM method, but rather Jason.

Good to know.

> 
>> 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.
> 
>> 
>> 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.
> 
> Now that I am back on TAO development "full time," I should eventually
> get notified to do code reviews for TAO related requests and respond
> to them quickly.  I will figure out how to look at your pull request 
> tomorrow though.

Awesome, thank you!

> 
> Right now, I am concentrating on addressing known problems in some 
> methods, but longer term, really just want to refactor the whole 
> thing.

Cool, this is also good to know.

SQPTR needs some work. I wrote it over 14 days; mostly whatever time I could spare at ICSP, plus three weekends. Right now, it’s written so that various steps of the algorithm could be factored out and tested individually using a handwritten test harness. The performance could be improved by caching objects instead of destroying them and recreating them repeatedly, and eliminating redundant function evaluations. The definition of the Hessian needs to be fixed for use in the general case — right now, I have a test example with linear equality constraints that does not contribute at all to the Hessian. I also suspect the current implementation does not use TAO idiomatically, and that might need to be fixed. Nevertheless, it runs and computes the right answer. Longer term, it would be good to interface the solvers to CUTEst to get a benchmark, and it would be good to include PDE-constrained optimization problems as separate benchmark problems; I think there are some practical research issues on this point that might be good to discuss off-list with anyone on the PETSc/TAO team that would be interested.

Geoff

> 
> Todd.
>