[petsc-users] Pre-check before each line search function evaluation

[Matthew Knepley]

On Thu, Nov 30, 2023 at 4:23 PM Alexander Lindsay <alexlindsay239 at gmail.com>
wrote:

> If someone passes me just L, where L represents the "global" degrees of
> freedom, in this case they represent unknowns on the trace of the mesh,
> this is insufficient information for me to evaluate my function. Because in
> truth my degrees of freedom are the sum of the trace unknowns (the unknowns
> in the global solution vector) and the eliminated unknowns which are
> entirely local to each element. So I will say my dofs are L + U.
>

I want to try and reduce this to the simplest possible thing so that I can
understand. We have some system which has two parts to the solution, L and
U. If this problem is linear, we have

  / A  B \ / U \ = / f \
  \ C D / \ L /   \ g /

and we assume that A is easily invertible, so that

  U + A^{-1} B L = f
  U = f - A^{-1} B L

  C U + D L = g
  C (f - A^{-1} B L) + D L = g
  (D - C A^{-1} B) L = g - C f

where I have reproduced the Schur complement derivation. Here, given any L,
I can construct the corresponding U by inverting A. I know your system may
be different, but if you are only solving for L,
it should have this property I think.

Thus, if the line search generates a new L, say L_1, I should be able to
get U_1 by just plugging in. If this is not so, can you write out the
equations so we can see why this is not true?

  Thanks,

     Matt


> I start with some initial guess L0 and U0. I perform a finite element
> assembly procedure on each element which gives me things like K_LL, K_UL,
> K_LU, K_UU, F_U, and F_L. I can do some math:
>
> K_LL = -K_LU * K_UU^-1 * K_UL + K_LL
> F_L = -K_LU * K_UU^-1 * F_U + F_L
>
> And then I feed K_LL and F_L into the global system matrix and vector
> respectively. I do something (like a linear solve) which gives me an
> increment to L, I'll call it dL. I loop back through and do a finite
> element assembly again using **L0 and U0** (or one could in theory save off
> the previous assemblies) to once again obtain the same K_LL, K_UL, K_LU,
> K_UU, F_U, F_L. And now I can compute the increment for U, dU, according to
>
> dU = K_UU^-1 * (-F_U - K_UL * dL)
>
> Armed now with both dL and dU, I am ready to perform a new residual
> evaluation with (L0 + dL, U0 + dU) = (L1, U1).
>
> The key part is that I cannot get U1 (or more generally an arbitrary U)
> just given L1 (or more generally an arbitrary L). In order to get U1, I
> must know both L0 and dL (and U0 of course). This is because at its core U
> is not some auxiliary vector; it represents true degrees of freedom.
>
> On Thu, Nov 30, 2023 at 12:32 PM Barry Smith <bsmith at petsc.dev> wrote:
>
>>
>>   Why is this all not part of the function evaluation?
>>
>>
>> > On Nov 30, 2023, at 3:25 PM, Alexander Lindsay <
>> alexlindsay239 at gmail.com> wrote:
>> >
>> > Hi I'm looking at the sources, and I believe the answer is no, but is
>> there a dedicated callback that is akin to SNESLineSearchPrecheck but is
>> called before *each* function evaluation in a line search method? I am
>> using a Hybridized Discontinuous Galerkin method in which most of the
>> degrees of freedom are eliminated from the global system. However, an
>> accurate function evaluation requires that an update to the "global" dofs
>> also trigger an update to the eliminated dofs.
>> >
>> > I can almost certainly do this manually but I believe it would be more
>> prone to error than a dedicated callback.
>>
>>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20231130/d2b30b57/attachment.html>