Closed talassio closed 3 years ago
Further comments to resolve the issue:
mult_j
and mult_Jt
should not have options
to be optional, forcing to discern between using the Jacobian or Jacobian transpose (Gradient).
This will require to update model=4
evaltensor_*
callbacks which currently do not handle the case of Jacobian transpose.
evaltensor_f
make call to mult_j
regardless of options%fortran_jacobian
. It should be updated so to check the case of the options%fortran_jacobian
and either call mult_j
with options or mult_j
/mult_jt
depending on the option value.
evaltensor_j
in all three loops assumes J
is the Jacobian, this needs to be updated to take into account the value of options%fortran_jacobian
.
solve_LLS
is also assuming J
is provided in column major format
The signature to mult_j
and mult_jt
could be changed to accept logical fortran_jacobian
instead of nlls_options options
, this would simplify the passing of the value into the evaltensor_*
callbacks. Furthermore, tensor_params_type
could be extended to include a new member logical fortran_jacobian
to be passed onto mult_j
.
Providing the Jacobian with option
options%fortran_jacobian = .True.
OR providing Jacobian transpose with optionoptions%fortran_jacobian = .False.
should be (numerically) equivalent.Minimal example provided wtih
lanczos3.f90
, currently only for some combinations ofoptions%...
the behaviour is as expected, for the others combinations diffs are present in solution paths.