topic Exactly. If you wish, after in Intel® oneAPI Math Kernel Library

Questions & Puzzled about mkl_sparse_spmm

wen_qiang_z_ — Mon, 05 Nov 2018 03:16:51 GMT

Hi, I`m very very very anxious now because of the using of mkl_sparse_spmm function always feedback me an error beyond my understanding. When I trying to compute the product of two sparse matrix created by mkl_sparse_csr_create function, for the foremost, everything tends to be good, but when I tried to compute it again, an Access Conflict error appeared and I have no idea why this error shows.

Here is part of my codes
do i = 1, 5

!*steps to compute the values needed are ignored,and I `ve tested them to make sure they`re correct*!

!create sparse matrix, this step is right and the stat = 0
       stat=mkl_sparse_z_create_csr(local(i)%Krc%B,sparse_index_base_one,sub(i)%temp, &
           sub(i)%Noc,local(i)%rows_start,local(i)%rows_end,local(i)%col_indx,local(i)%values)
       write(*,*) stat

!create sparse matrix, this step is right and the stat = 0
stat=mkl_sparse_z_create_csr(local(i)%Kcr%A,sparse_index_base_one,&
           local(i)%Kcr%rows,local(i)%Kcr%cols,local(i)%Kcr%rows_start,local(i)%Kcr%rows_end,&
           local(i)%Kcr%col_indx,local(i)%Kcr%values)
       write(*,*) stat

!compute the product
       info = mkl_sparse_spmm(sparse_operation_non_transpose,local(i)%Kcr%A,local(i)%Krc%B,local(i)%Kcr%B)
       write(*,*) info

   end do

At the first loop for i == 1, it seems good, bu when it turns to the loop for i == 2, then the compiler feedback an error of Access Conflict which confuses me most. I can make sure that the sparse matrices are correct. and I did not deallocate the memory or destroy the sparse matrix handle ,so I have no ides why this situation shows.

Can U help me?

In general, when you call a

mecej4 — Mon, 05 Nov 2018 17:03:45 GMT

In general, when you call a matrix routine that takes two input matrices A and B and produces an output matrix C, C should not be the same as A or B. This is because (i) if C is the same as A, for example, some elements of C may be computed and overwritten (into A) and the same elements of A read later, which would cause the results to be wrong; and (ii) in Fortran, there are what are often called "anti-aliasing" rules that say that changes to the contents of an argument may be made only through that argument and not through some other variable that occupies or points to the same memory area. Calls with aliased arguments may work sometimes and fail at other times. To be safe, no actual output argument should be the same as any actual input argument.

Quote:mecej4 wrote:

wen_qiang_z_ — Tue, 06 Nov 2018 00:35:35 GMT

mecej4 wrote:
In general, when you call a matrix routine that takes two input matrices A and B and produces an output matrix C, C should not be the same as A or B. This is because (i) if C is the same as A, for example, some elements of C may be computed and overwritten (into A) and the same elements of A read later, which would cause the results to be wrong; and (ii) in Fortran, there are what are often called "anti-aliasing" rules that say that changes to the contents of an argument may be made only through that argument and not through some other variable that occupies or points to the same memory area. Calls with aliased arguments may work sometimes and fail at other times. To be safe, no actual output argument should be the same as any actual input argument.

You mean that I should open up other spaces to save the output matrix C instead of saving in the same type`s space? Am I right?

Exactly. If you wish, after

mecej4 — Tue, 06 Nov 2018 01:53:26 GMT

Exactly. If you wish, after the matrix multiplication is finished, copy the result from that "space" back into matrix C.

Quote:mecej4 wrote:

wen_qiang_z_ — Tue, 06 Nov 2018 06:26:36 GMT

mecej4 wrote:
Exactly. If you wish, after the matrix multiplication is finished, copy the result from that "space" back into matrix C.

Hi, I`ve tried what you said, it didn`t work. It looks like that the CSR matrix A created before the multiplication has some problem in saving its components but the stat information shows that the creation procedure is correct. So thanks for your advice but I still confused

Please post a small but

mecej4 — Tue, 06 Nov 2018 08:45:00 GMT

Please post a small but complete code example that demonstrates what you said "didn't work", and describe how you compiled, linked and ran the example. State your compiler and MKL versions.

You have not shown the declarations of the variables in your code extracts, but I believe that

 info = mkl_sparse_spmm(sparse_operation_non_transpose,local(i)%Kcr%A,local(i)%Krc%B,local(i)%Kcr%B)

should actually have been

 info = mkl_sparse_spmm(sparse_operation_non_transpose,local(i)%Kcr%A,local(i)%Krc%B,&(local(i)%Kcr%C))

In other words, the last argument should actually be the address to receive a newly created matrix handle, not an existing matrix handle.

If you have not done so already, please look at the example sparse_spmm.c that is provided with MKL in the .../examples/spblasc directory.

Quote:mecej4 wrote:

wen_qiang_z_ — Tue, 06 Nov 2018 11:31:12 GMT

mecej4 wrote:
Please post a small but complete code example that demonstrates what you said "didn't work", and describe how you compiled, linked and ran the example. State your compiler and MKL versions.
You have not shown the declarations of the variables in your code extracts, but I believe that
 info = mkl_sparse_spmm(sparse_operation_non_transpose,local(i)%Kcr%A,local(i)%Krc%B,local(i)%Kcr%B)
should actually have been
 info = mkl_sparse_spmm(sparse_operation_non_transpose,local(i)%Kcr%A,local(i)%Krc%B,&(local(i)%Kcr%C))
In other words, the last argument should actually be the address to receive a newly created matrix handle, not an existing matrix handle.

If you have not done so already, please look at the example sparse_spmm.c that is provided with MKL in the .../examples/spblasc directory.

Thx a lot! And I`ve figured out why this error occurred, thanks for your help!