[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