If you do have the data structures of the CSR matrix, you should of course make use of it. But there are cases in which your sparse matrix comes from another Julia function, in which case it’s most likely going to be CSC. Examples are `sprand`

and `spzeros`

from SparseArrays.jl, `mmread`

from MatrixMarket.jl and so forth.

My workflow is not so important as I only do prototyping work in Julia and do my real work in C. However, as I explained to @bertschi, most Julia functions which return sparse matrices do it in CSC. So there are numbers of cases in which you have no choice but to handle some CSC matrices in Julia.

The advantage of CSR over CSC and COO is that its corresponding SpMV can be parallelized, which is not the case of the SpMV of CSC and COO. Given that Julia’s BLAS enables multithreading, I was suprised that the choice of the default sparse matrix format was not done so as to eventually allow seamless parallelization of SpMV. Sure, as it’s been widely discussed in the thread, you can workaround the CSC functionalities of Julia and parallelize the CSC SpMV_T which you can use with a transposed CSC so as to emulate a multithreaded CSR SpMV, but just like @ChrisRackauckas said, I think would make more sense for SparseArrays.jl to support CSR.

Well to be fair, `sprand`

and `spzeros`

produce matrices that can be interpreted as CSR instead.

Yes, `sprand`

and `spzeros`

are not the most relevant examples, but `mmread`

is.