-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need some help on weird outputs of the benchmark demo. #11
Comments
PS. many diagonal elements are zero valued. |
It looks that this is not a problem of tuning the solver. There is some error and the entire solver process is not performed at all. The reported times are all 0 and values are random. Please check the return value of CKTSO_Analyze. |
The return value of CKTSO_Analyze = -3 |
Our matrix data are in matrix market file format with matrix market format |
-3 means invalid matrix... does your matrix have duplicated entries(for example, you have two ai[i] of same ai[i] value and the double values of two ax[i] need to be accumulated, this case is not allowed in CKTSO)? This is the most possible reason. Other reasons are all related to value out of range or matrix singular (including ap[0]!=0, ap[n]<=0, ap[n]<n, any ap[i]<0, any ap[i]>ap[i+1], any ai[i]<0, or any ai[i]>=n). |
another reason may be in the read code of mtx file. the code provided in the demos may not handle any case. they are simple and just provided for demo purpose. you may check if the read was correct or use you own read code. |
Doctor Chen, thank you for your kindness help. The real problem is the duplicated entries. I fixed the bug and everything just worked fine. Since many of these matrix files are dumped for C or C++ scientific computation libraries to assemble a matrix in some so called "Add_Values" mode, it is very common to come into such a situation, i.e., in these libraries duplicate values will be accumulated automatically. I suggest, in my humble opinion, CKTSO could provide a simple tool to check and transform such "problematic" matrix market files into good ones. |
Yes, this is a practical requirement in some applications. Actually we already have a simple internal tool that can remove duplicated entries. It needs to be called before every factorization. It leads to some additional latency and memory usage, especially when the matrix is very sparse. I am now thinking about how to integrate this funtion into CKTSO to eliminate these overheads. |
Well the answer is quite simple, both KLU and MKL PARDISO were called using PETSc APIs, the matrix was assembled using PETSc's own "Add_values-like" APIs. |
PETSc matrix APIs handle these duplicate entries automatically. |
Hi! Dr Chen, recently we made some benchmark tests on cktso. The test matrices are drawn from real circuit design ranging from 1.0E+04 up to 1.3E+07. We use the benchmark demos from both NICSLU and CKTSO and meet some weird situation. When
run ./benchmark add20.mtx #nthreads the output is just fine something like this follows:
Analysis time = 4900 us.
Factorization average time = 100 us, min time = 82 us.
Refactorization average time = 49 us, min time = 47 us.
Solve average time = 10 us, min time = 9 us.
Residual = 2.47485e-10.
Transposed solve average time = 12 us, min time = 11 us.
Residual = 2.44494e-10.
NNZ(L) = 9867, NNZ(U) = 7472.
Factorization flops = 133187, solve flops = 32283.
Determinent = 5.86668*10^(-3351).
Memory usage = 646989 bytes, max memory usage = 646989 bytes.
However, let's take CKTSO as an example, if we run ./benchmark ourcircuitmatrix #nthreads, something like this follows:
Analysis time = 0 us.
Factorization average time = 0 us, min time = 0 us.
Refactorization average time = 0 us, min time = 0 us.
Solve average time = 0 us, min time = 0 us.
Residual = 7062.9.
Transposed solve average time = 0 us, min time = 0 us.
Residual = 7062.9.
NNZ(L) = 0, NNZ(U) = 0.
Factorization flops = 106382044954745, solve flops = 10.
Determinent = 4.67441e-310*10^(6.91969e-310).
Memory usage = 1480 bytes, max memory usage = 61772 bytes.
I really don't know how to tune the numerous parameters in CKTSO or NICSLU. Canyou please give me some advices on tuning the solver? Since other popular direct solvers like KLU or PARDISO solved all of our test cases without tuning too much, I'm really confused about the weird result.
The text was updated successfully, but these errors were encountered: