[petsc-dev] coding style

Oxberry, Geoffrey Malcolm oxberry1 at llnl.gov
Thu Aug 18 17:27:24 CDT 2016


Thank you; now I follow.

> On Aug 18, 2016, at 2:59 PM, Munson, Todd <tmunson at mcs.anl.gov> wrote:
> 
> 
> Exactly, its only for a quadratic programming solver, so the user
> is claiming their model is quadratic and the solver
> extracts the matrices.
> 
> Todd.
> 
>> On Aug 18, 2016, at 4:54 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>> "Oxberry, Geoffrey Malcolm" <oxberry1 at llnl.gov> writes:
>> 
>>> I realize this point was brought up earlier, but doesn’t this
>>> discussion still assume that evaluating g at zero is defined and makes
>>> sense? Though I see the appeal in this design, I’m not sure it will
>>> necessarily work in practice. For instance, we definitely have
>>> formulations that involve terms like sqrt(x), which isn’t
>>> differentiable at zero, and would break this interface. (We would
>>> bound the feasible set away from zero, so the optimization algorithm
>>> should still work.)
>> 
>> Isn't the context of this particular comment that the user claims their
>> model is quadratic?  Of course evaluating at 0 has no special meaning
>> for a general nonlinear model.
>> 
>>>> On Aug 18, 2016, at 11:02 AM, Munson, Todd <tmunson at mcs.anl.gov> wrote:
>>>> 
>>>>> 
>>>>> People are free to use MatShell to create a "matrix" that is
>>>>> actually a nonlinear operator.  Solvers won't work properly if it's
>>>>> not, but that's their problem.
>>>> 
>>>> The quadratic programming solvers in our case will happily go and
>>>> tell you it solved the problem...however, the problem it solved uses
>>>> 
>>>> c = grad[g(0)] H = hess[g(0)]
>>>> 
>>>> I'd be happier if the solver barfed and told the user to select a
>>>> method appropriate for their real problem -- it it truly is nonlinear
>>>> -- rather than going off and solving the wrong problem, which is what
>>>> is done today.
>>>> 
>>>> Todd.
>>>> 
> 



More information about the petsc-dev mailing list