C <-> Box Logic

[tyronerees]

• [ ] Set up interface
• [ ] Add simple test
• [ ] Update documentation

[tyronerees]

This doesn't seem to be straight forward (unless I'm missing something).

Current setup

The way the C-interface currently works (in master) is described below. Note xx could be r, j, hf, etc.:

• the user supplies pointers to the following:
  1. ral_nlls_eval_xx_type eval_xx
  2. void * params params can hold anything, and is provided as a helper to get data into the functionseval_xx. The fortran need not know about anything about what's in here, as long as the functions access it correctly it just gets passed along as a blind pointer.
• the file ral_nlls_ciface.f90 wraps params into a Fortran derived type fparams, with members
  1. params (a pointer to the void * C object)
  2. xx (pointers to the C functions)
• the file ral_nlls_ciface.f90 also defines subroutines c_eval_xx that call the C function (fparams%xx), passing in the parameters (fparams%params)
• ral_nlls_solve (or _iterate) is called with fparams and the various c_eval_xx

How params is used in the box-logic branch

In the box-logic branch, we extend the params_base_type to params_box_type, which holds data needed for the box logic:

  Type, Public, Extends(params_base_type) :: params_box_type
    ! See if problem has box bounds
    Integer :: iusrbox = 0
    Real(Kind=wp), Allocatable :: blx(:), bux(:), pdir(:), normFref(:), sk(:), g(:)
    ! projection changed the direction? d /= P(d)?
    Logical :: prjchd = .false.
    ! Convergence metrics
    Real(Kind=wp) :: normPD, gtd
    ! Memory for HZLS (LS)
    Real(Kind=wp) :: sksk, skyk, quad_c, quad_q, normFold
    ! Consecutive times quadratic model is accurate
    Integer       :: quad_i = 0
    ! Memory for nonmonotone LS
    Integer       :: nFref = 0
  End Type params_box_type

C interface to the box-logic

params is no longer a black box, and has values the must be allocated by both the C and the Fortran. I don't think it's currently possible to send such an object between the two languages.

Solutions?

1. We could have an optional derived type bound_params, which would hold all the data.
2. We could add optional arrays bux and blx, and store the rest in the workspace and/or inform types as appropriate.
3. Handle params similarly to the workspace in the C interface to nlls_setup_bounds (as bound_params, say), and pass this as an optional argument to the Fortran wrapper nlls_solve. The file ral_nlls_ciface could then be changed so that these are wrapped together appropriately in the params that is sent to the Fortran.
4. ???

Either 1. or 2. would still need some working around from the C side, as I don't believe optional variables are handled the same way as in Fortran, but this should be straightforward.

From a design standpoint, params is now doing multiple jobs, and it would be cleaner to keep objects have a single purpose.