[Meson] Add unit tests in Fortran

[amontoison]

Nick, it seems that a file u_elfun_quadruple.f is missing in src/test.
I have some comments on the Fortran tests:

• We have an error with threaded tests:

# /home/alexis/Applications/CUTEst/builddir4/ctest_threaded_double
# /home/alexis/Applications/CUTEst/builddir4/ctest_threaded_single
 CALL CUTEST_cdhj
 ** CUTEST error: thread -1717986918 out of range [1,4]
 error status = 4

Meson doesn't return en error because it just prints things and it's not a segmentation fault.

• If I compile CUTEst with 64-bit integer, I have this error:

alexis@HP-Spectre:~/Applications/CUTEst/src/test$ /home/alexis/Applications/CUTEst/builddir4/ctest_threaded_single
 CALL CUTEST_cdimen 
 * n = 5, m = 1
 CALL CUTEST_cnoobj 
 there is an objective function
 CALL CUTEST_csetup 
 *       i      X_l          X          X_u
 *       1 -1.0000E+20  0.0000E+00  1.0000E+20
 *       2  1.0000E+00  0.0000E+00  1.0000E+20
 *       3 -1.0000E+10  0.0000E+00  1.0000E+00
 *       4  2.0000E+00  0.0000E+00  2.0000E+00
 *       5  0.0000E+00  0.0000E+00  1.0000E+20
 *       i      C_l         C_u          Y         EQUATION   LINEAR
 *       1  0.0000E+00  0.0000E+00  0.0000E+00         T         F
 CALL CUTEST_cstats
 * nonlinear_variables_objective = 5
 * nonlinear_variables_constraints = 2
 * equality_constraints = 1
 * linear_constraints = 0
 CALL CUTEST_cnames
 * p_name = ALLINITC4 
 *       i  X_name
 *       1  X1        
 *       2  X2        
 *       3  X3        
 *       4  X4        
 *       5  X5        
 *       i  C_name
 *       1  C1        
 Call CUTEST_connames
 *       i  C_name
 *       1  C1        
 CALL CUTEST_cvartype
 *       i  X_type
 *       1  0
 *       2  0
 *       3  0
 *       4  0
 *       5  0
 CALL CUTEST_cfn
 ** SUBROUTINE CFN: error flag raised during SIF evaluation
 error status = 3

• Which test(s) should use q_group_*.f, q_elfun_*.f, q_range_*.f?
• Should I use ctest.F90 and / or ctest2.F90?

[nimgould]

Sorry, I forget to push all of the u_*_threaded.f files. Now done.

The cdhj issue was a bug on my part, I forgot to add the ", thread" argument. Fixed.

We have talked about 64-bit cutest before, and as I said this is highly non trivial as we would have to make a breaking change to sifdecode #53 . We agreed not to implement this at the time. As I said, there is no need for 64 bits in CUTEst at the moment as no SIF example gets close to that limit. And I did suggest that if we do need this, someone else from the team should do it.

The q_*.f functions are just to test QPs

ctest2.F90 is just to debug an individual tool (for my convenience). Just use ctest.F90, and ignore ctest2.F90

[nimgould]

Actually, I suppose there is no reason not to test 64 bit cutest with invented c_elfun_s_64 (etc) that we construct. The sifdecoder can't do this (at the moment)
but if we ever anticipate this happening, it might be good to see that it works.

All that would be needed would be to duplicate all of the c_.f q_.f and u_.f to have names c_64.f q64.f and u_64.f, and for each of these new duplicates insert a line
USE ISO_FORTRAN_ENV
after the first subroutine statement, and change all occurrences of INTEGER to INTEGER(INT64) (and make sure that any of these lines stays <=72 characters.

We would also have to modify ./include/cutest_modules_single.h (etc) to add a _64 if 64 bit integers are used as we did for GALAHAD, when buidling the 64 bit cutest libraries

[amontoison]

Sorry, I forget to push all of the u_*_threaded.f files. Now done.

The cdhj issue was a bug on my part, I forgot to add the ", thread" argument. Fixed.

The q_*.f functions are just to test QPs

ctest2.F90 is just to debug an individual tool (for my convenience). Just use ctest.F90, and ignore ctest2.F90

Thanks you Nick for the fixes and explanation.

We have talked about 64-bit cutest before, and as I said this is highly non trivial as we would have to make a breaking change to sifdecode #53 . We agreed not to implement this at the time. As I said, there is no need for 64 bits in CUTEst at the moment as no SIF example gets close to that limit. And I did suggest that if we do need this, someone else from the team should do it.

When I added the tests, I assumed that files like u_elfun_double.f, u_group_single.f, or c_range_quadruple.f could accept the macro -DINTEGER_64 like the test files. I didn't check the content, my fault.

I propose that we wait until there is a demand or work on a 64-bit decoder before focusing on tests in GALAHAD. I prefer to add tests for what is currently supposed to work (like the C interface in issue #64 and potential issues in the _name functions) or develop new features, such as a routine that returns the jth Hessian product (the product between the Hessian of constraint j and a vector).

All tests passed, so I'll merge the pull request.