cgradient.F looks like steepest descent rather than CG on first sight

[stef]

I just noticed that in cgradient.F, the function

Code: Select all

!
!  Compute new direction, d(k+1).
!
      CALL new_direction (ng, tile, model,                              &
      ...

is called right after the the (normalized) gradient vector has been computed with

Code: Select all

      CALL lanczos (ng, tile, model,                                    &

But in new_direction, the code is like

Code: Select all

          d_zeta(i,j)=ad_zeta(i,j,Lnew)
          d_zeta(i,j)=d_zeta(i,j)*rmask(i,j)

where ad_zeta(i,j,Lnew) is the normalized gradient from lanczos().

Is this really correct?

Shouldn't the new search direction contain a contribution from the H-projection of the current gradient onto the previous search direction?
Or something like that, i.e. the contribution containing what is usually referred to as the 'beta' factor in CG algorithms.

I have not fully understood the code, but this looks strange, because it looks like steepest descent rather than conjugate gradient.

[stef]

Hmm, now I saw the tl_new_state() function. Is this an implementation of getting x^k from z^k according to Eqs. 21-22 of [1]?

So new_direction() is just to store the gradients in the d_* arrays? With the lanczos method, the actual cg search directions are never explicitly computed? However, the following comment in new_direction():

Code: Select all

!
!-----------------------------------------------------------------------
!  Compute new conjugate descent direction, d(k+1). Notice that the old
!  descent direction is overwritten.
!-----------------------------------------------------------------------
!

is not ideal, is it? Or am I still not understanding it?


[1] Fisher, M., 1998: Minimization algorithms for variational data !
data assimilation. In Recent Developments in Numerical !
Methods for Atmospheric Modelling, pp 364-385, ECMWF. !