I have a three array variation of the CSR format as a sparse matrix. The rowIndex vector is of type INTEGER (KIND=8), while all the rest of the integers are KIND=4. Because of memory and code limitations, I cannot use the option -i8 when compiling.
Is there any way to use MKL_SPARSE_D_CREATE_CSR and the rest of the functions with rows_start and rows_end defined as INTEGER (KIND=8)?
I don't think so. Consider the implications. If mixing different size integer arguments to MKL routines was allowed, they would need to implement 2^6 = 64 different versions of MKL_SPARSE_D_CREATE_CSR, and similarly for other MKL routines that take one or more integer arguments.
They decided long ago to provide two versions of the libraries: LP64 and ILP64.
However, note that this restriction applies only to integer variables that are actual arguments to MKL routine calls. You are free to use whatever integer sizes suit you for other variables.
So mecej4 is absolutely correct, but the discussion could be a little more nuanced. The world of sparse formats is trying to solve the general problem of balancing representing the sparse matrix with as small of a memory footprint while still making the format useful for a wide range of operations. There is probably a good reason to consider use of all scalar integer inputs as large integers (like std::int64_t) but make the arrays of integers use as small of a size as is possibly necessary to represent their internal sizes.
For CSR4 format:
row_start/rows_end are of length nrows and contains integers that represent an offset in the range 0 to nnz
colind is of length nnz and contains integers that represent a column index in the range 0 to ncols
Qualitatively these are distinct ranges and usages so it does make sense to consider having three types of data in the CSR4 format: something like OFFSET_INT_TYPE, INDEX_INT_TYPE, and then the DATA_TYPE, as follows:
Your desire to use 8 byte integers for rows_start and rows_end but 4 byte integers for colind seems consistent with this desire to reduce the memory footprint. Did I understand your intent correctly?
However, this complicates things somewhat in the interfaces (the growth of the number of interfaces and size of the library to contain all the distinct implementations is not insignificant) and we as oneMKL decided a long time ago to not distinguish between the two types of integers in our IE Sparse BLAS C and Fortran interfaces.
Additionally, this can further complicate matters when you start considering sparse matrix - sparse matrix multiplication where the INDEX_INT_TYPE and OFFSET_INT_TYPE integer sizes might be incompatible between the two matrices, it would require some finesse and very clear rules on how the output sparse matrix should be created, filled and used.
Thus you must unfortunately pick a single integer size (based on linking to LP64 or ILP64 and using MKL_INT) for using our oneMKL APIs.
We assume that your issue is resolved. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.