Hello,
I’m Adam, a physics PhD student. I know quite a few languages and have programmed for about a decade, though with Fortran only for about a year. Despite that, I quite enjoy (modern) Fortran! I attended the recent monthly call, it was nice to meet everyone. I’ve been on the fence about GSoC, but figured I’d post here about what I’d be interested in and get feedback while I work on a patch/PR.
If you want my previous contribution credentials, I contributed to the nonlinear conjugate gradient solvers in the PETscTAO package a few years back [during an internship right before I started my PhD]. In particular, I implemented a few modern CG variants, and added diagonalpreconditioning to all CG methods based on limitedmemory BFGS methods. You can find my name as an author in the User’s Manual publication.
I have two interests for the GSoC:

Multidimensional Quadrature with Integrable Singularities (basically implementing these two papers: Paper1 Paper 2 )
 This is my higher interest, as it is somewhat relevant to my research and so I can justify the time spent to my PhD advisor.
 This is when you have a form of the integrand f(x)/(zg(x)) [user knows f(x), g(x) or has them numerically evaluated] and want to compute the (parameterized) integral over a domain I(z); there are also analytic forms to compute integrals of I(z) at the same time.
 There is a hugely limited version of this implemented as the socalled “Tetrahedron method” in the condensed matter community, but these papers outline a huge generalization to the method.
 It is a desirable method when the denominator leads to an integrable singularity, but it is difficult to compute f(x) or g(x) for a lot of points [so adaptive refinement isn’t a great option].
 This would be a good tool at least to the computational physics community, but I imagine would also be useful for certain FEM codes among other applications.
 It may be too niche for stdlib, and in fact it’s fairly complex. But I would like it to be implemented and opensource. So I don’t know if this qualifies as a valid GSoC 2023 project; feedback would be welcome.

Sparse matrix support in stdlib_linalg
 This is less relevant to my personal research [and therefore will be able to spend less time on it], but I do have a special place in my heart for sparse matrices. Saving memory is a blast.
 Amongst having support for CSR and COO, I think special attention for banded matrices (dia_array in scipy.sparse) and Kroneckerproduct matrices (common for [N>1]dimensional derivative stencils) could make sense. They would each get their own matvecs. Also, Kroneckerproduct matrices could have either sparse or dense matrices comprising them.
 I will probably add in the Kronecker product (for dense → dense) to stdlib_linalg for my patch/PR requirement. I have a working snippet, just gotta figure out fypp
 Should I add two implementations that are stylistically different (and with somewhat different performance) and let whoever manages the PR decide which one to keep, or just add the one that’s faster for big (dense) matrices?
 I will probably add in the Kronecker product (for dense → dense) to stdlib_linalg for my patch/PR requirement. I have a working snippet, just gotta figure out fypp