Remove LAPACK as a requirement

[Connor-Bowley]

Is it worthwhile to remove LAPACK (and by extension Fortran) for an easier build process and lower barrier to development.

GROUPS doesn't appear to need LAPACK (NIRALUser/GROUPS#40).

SPHARM-PDM uses it in one place that I have found. Could we replace the LAPACK call with something equivalent from Eigen (which is already in the superbuild and is used by other things like VTK) and then remove LAPACK (and Fortran) altogether?

[bpaniagua]

yes, that would be fine, but we will have to benchmark SPHARM and make sure it continues working the same with the same dataset

[jcfr]

GROUPS doesn't appear to need LAPACK

It turns out that it is currently required in the implementation of GroupwiseRegistration::eigenvalues.

See details at NIRALUser/GROUPS#40 (comment)

[jcfr]

SPHARM-PDM uses it

For reference, the lapack function LAPACK_sgels is used in ParametricMeshToSPHARMSpatialObjectFilter::ComputeCoeffs. See Libraries/Shape/Algorithms/ParametricMeshToSPHARMSpatialObjectFilter.cxx#L1050-L1062

Related links:

• https://netlib.org/lapack/explore-html/d0/db8/group__real_g_esolve_ga166c189c7bcd808a9468c05e53da816f.html
• https://github.com/Reference-LAPACK/lapack/blob/77a0ceb6c9a3c757e7039027f1f324e2811e6ee0/SRC/sgels.f

[jcfr]

Closing. Both SPHARM-PDM and GROUPS were respectively updated by @allemangD in the following pull-requests:

• Remove Fortran and LAPACK NIRALUser/SPHARM-PDM#81
• Remove Fortran and LAPACK NIRALUser/GROUPS#44

And corresponding updates integrated into SlicerSALT through #294