[petsc-users] A question on finite difference Jacobian

[Zou (Non-US), Ling]

Thank you Jed.
This seems to be hard :)

Ling

On Wed, Oct 7, 2015 at 9:30 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> > On Oct 7, 2015, at 9:54 AM, Zou (Non-US), Ling <ling.zou at inl.gov> wrote:
> >
> > Thank you Barry.
> >
> > The background I am asking this question is that I want to reduce (or
> you can say optimize) the cost of my finite difference Jacobian evaluation,
> which is used for preconditioning purpose. The concept is based on my
> understanding of the problem I am solving, but I am not sure if it will
> work, thus I want to do some test.
> >
> > Here is the concept, assume that my residual reads,
> >
> > F(\vec{U}) = F[\vec{U}, g(\vec{U})]
> >
> > in which, g(\vec{U}) is a quite complicated and thus expensive function
> evaluation. This function, however, is not very sensitive to \vec{U}, i.e.,
> \partial{g(\vec{U})}/\partial{g(\vec{U})} is not that important.
> >
> >
> > Normally, a finite difference Jacobian is evaluated as (as discussed in
> PETSc manual),
> >
> > J(\vec{u}) \approx \frac{F(\vec{U}+\epsilon \vec{v}) - F(\vec{U})}
> {\epsilon}
> >
> > In my case, it reads,
> >
> > J(\vec{u}) \approx \frac{F[(\vec{U}+\epsilon \vec{v}),
> g(\vec{U}+\epsilon \vec{v})] - F[(\vec{U}), g(\vec{U})]} {\epsilon}
> >
> > Because \partial{g(\vec{U})}/\partial{g(\vec{U})} is not important, the
> simplification I want to make is, when finite difference Jacobian (as
> preconditioner) is evaluated, it can be further simplified as,
> >
> > J(\vec{u}) \approx \frac{F[(\vec{U}+\epsilon \vec{v}), g(\vec{U})] -
> F[(\vec{U}), g(\vec{U})]} {\epsilon}
> >
> > Thus, the re-evaluation on g(\vec{U}+\epsilon \vec{v}) is removed. It
> seems to me that I need some kind of signal from PETSc so I can tell the
> code not to update g(\vec{U}). However, I never tested it and I don't know
> if anybody did similar things before.
>
>    This is tricky because you are not simply providing a different
> function to difference; you are skipping part of the differencing
> procedure. MatFDColoringSetFunction() is only designed to allow you to
> change the function, not monkey with removing the differencing value
> sometimes.
>
>    Of course it is possible for you to do what you want but I think it
> would require you copying our differencing code and modifying exactly for
> your needs. For AIJ matrices the function is MatFDColoringApply_AIJ() it is
> a bit obscure and you would have to figure out what rows correspond to the
> g(\vec{U}) part so you handle them differently.
>
>   Barry
>
> >
> > Thanks,
> >
> > Ling
> >
> >
> > On Tue, Oct 6, 2015 at 7:09 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> > > On Oct 6, 2015, at 4:22 PM, Zou (Non-US), Ling <ling.zou at inl.gov>
> wrote:
> > >
> > >
> > >
> > > On Tue, Oct 6, 2015 at 2:38 PM, Barry Smith <bsmith at mcs.anl.gov>
> wrote:
> > >
> > > > On Oct 6, 2015, at 3:29 PM, Zou (Non-US), Ling <ling.zou at inl.gov>
> wrote:
> > > >
> > > > Hi All,
> > > >
> > > > If the non-zero pattern of a finite difference Jacobian needs 20
> colors to color it (20 comes from MatFDColoringView, the non-zero pattern
> is pre-determined from mesh connectivity), is it true that PETSc needs 40
> functions evaluation to get the full Jacobian matrix filled? This is
> because that a perturbation per color needs two function evaluation
> according to PETSc manual (ver 3.6, page 123, equations shown in the middle
> of the page).
> > > > But I only see 20 function evaluations. I probably have some
> misunderstanding somewhere. Any suggestions?
> > >
> > >    PETSc uses forward differencing to compute the derivatives, hence
> it needs a single function evaluation at the given point (which has almost
> always been previously computed in Newton's method)
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Is it a potential problem if the user chooses to use a different (e.g.
> simplified) residual function as the function for MatFDColoringSetFunction?
> >
> >    Yes, you can do that. But this may result in a "Newton" direction
> that is not a descent direction hence Newton stalls. If you have 20 colors
> I doubt that it would be a good idea to use a cheaper function there. If
> you have several hundred colors then you can use a simpler function PLUS
> -snes_mf_operator to insure that the Newton direction is correct.
> >
> >
> >   Barry
> >
> > >
> > >
> > > and then one function evaluation for each color. This is why it
> reports 20 function evaluations.
> > >
> > >   Barry
> > >
> > >
> > > >
> > > > Ling
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20151007/b56609d4/attachment.html>