Is it worth making better use of compressed Jacobian format?
- Dominant language
- Fortran
- Stars
- 11
- Forks
- 38
- Avg merge
- 17h 57m
- Merged PRs (30d)
- 1
Description
Transferred from [ukca:#326](https://code.metoffice.gov.uk/trac/ukca/ticket/326) on MOSRS.
The Jacobian in ASAD is a sparse matrix, which is stored in compressed format as `spfj`. Previous profiling work has indicated that the majority of the computational cost is in the nested loops in `splinslv2` (within `asad_sparse_vars.F90`). However, these loops do not make use of compressed formats when looping over entries of the Jacobian and instead loop over *all* entries of the sparsity pattern and check whether each is zero.
On branch [r7184_lu_refactor](https://github.com/joewallwork/ukca/tree/r7184_lu_refactor), I implemented compressed-sparse-row (CSR) and compressed-sparse-column (CSC) storage formats for the Jacobian and made use of them in the nested loop structure. There doesn't appear to be a noticeable runtime difference in my testing so far (at N48 resolution).
We should investigate whether there's a performance enhancement in higher resolution cases.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the nested loops in splinslv2 within asad_sparse_vars.F90 and review the compressed Jacobian work on branch r7184_lu_refactor. Benchmark the existing and compressed formats at higher-resolution cases, since N48 showed no noticeable runtime difference. Done means establishing whether compressed storage provides a measurable performance enhancement and documenting the result.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- fortran
- Domain
- performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100