[petsc-users] clarification of SNES / FormFunction

[Jed Brown]

I don't see why it's unnatural for the member functions to take the
location to evaluate as an argument.

In general, it is fragile and bad style to put any more state in a class
member than necessary.
On May 8, 2012 8:31 AM, "Dominik Szczerba" <dominik at itis.ethz.ch> wrote:

> Because my (class member) functions to construct A(x) and b(x) rely on
> the same (class member) "x" as registered with KSP. I could perhaps
> set up my A and b routines to take "x" as an argument, but this is a
> bit unnatural for a class member function, and I can not quickly
> predict the consequences for the rest of the code either.
>
> Dominik
>
> On Tue, May 8, 2012 at 3:22 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > Why a copy?
> >
> > On May 8, 2012 8:16 AM, "Dominik Szczerba" <dominik at itis.ethz.ch> wrote:
> >>
> >> >> I am currently assuming they are different and am using the "x" from
> >> >> the signature to set up my A(x) and b(x). I was thinking if they are
> >> >> the same (i.e. corresponding to x_n in the Newton method), I could
> >> >> significantly simplify my code. But apparently "x" in the signature
> is
> >> >> not simply x_n because of the involved line search, correct me if I
> am
> >> >> wrong.
> >> >
> >> >
> >> > Correct, they are not the same. How could it possibly simplify your
> code
> >> > "significantly"?
> >>
> >> Significantly was perhaps too strong a word, but a vector copy and a
> >> couple lines of code would certainly go. Never mind, thanks a lot for
> >> the clarification.
> >>
> >> Dominik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120508/5e05625a/attachment-0001.htm>