Romain, I added the KLU interface to PETSc last year hearing the hype about KLU¹s performance from several power system folks. I must say that I¹m terribly disappointed! I did some performance testing of KLU on power grid problems (power flow application) last year and I got a similar performance that you report (PETSc is 2-4 times faster than KLU). I also clocked the time spent in PETSc¹s SuiteSparse interface for KLU for operations other than factorization and it was very minimal. The fastest linear solver combination that I found was PETSc¹s LU solver + AMD ordering from the SuiteSparse package (-pc_factor_mat_ordering_type amd). Don¹t try MUMPS and SuperLU ‹ they are terribly slow.
Shri From: hong zhang <[email protected]> Date: Monday, August 17, 2015 at 10:08 AM To: Romain Thomas <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [petsc-users] petsc KLU >Romain: >Do you mean small sparse sequential 200 by 200 matrices? >Petsc LU might be better than external LU packages because it implements >simple LU algorithm and we took good care on data accesing (I've heard >same observations). You may try 'qmd' matrix ordering for power grid >simulation. >I do not have experience on SuiteSparse. Testing MUMPS is worth it as >well. > >Hong > > >Hi >Thank you for your answer. I was asking help because I find LU >factorization 2-3 times faster than KLU. According to my problem size >(200*200) and type (power system simulation), I should get almost the >same computation time. Is it true to think that? Is the > difference of time due to the interface between PETSc and SuiteSparse? >Thank you, >Romain > >-----Original Message----- >From: Barry Smith [mailto:[email protected]] >Sent: vrijdag 14 augustus 2015 17:31 >To: Romain Thomas >Cc: Matthew Knepley; [email protected] >Subject: Re: [petsc-users] petsc KLU > > > You should call > > MatGetFactor(mat,MATSOLVERKLU,MAT_FACTOR_LU,&fact); > > then call > >> MatLUFactorNumeric(Mat fact,Mat mat,const MatFactorInfo *info) >> MatLUFactorSymbolic(Mat fact,Mat mat,IS row,IS col,const MatFactorInfo >> *info) MatLUFactor(Mat mat,IS row,IS col,const MatFactorInfo *info) > > This routines correctly internally call the appropriate >MatLUFactorNumeric_KLU() etc for you because you passed MATSOLVERKLU >above. > There is no reason to (and it won't work) to call > >> MatLUFactorNumeric_KLU(Mat F,Mat A,const MatFactorInfo *info) >> MatLUFactorSymbolic_KLU(Mat F,Mat A,IS r,IS c,const MatFactorInfo >> *info) MatGetFactor_seqaij_klu(Mat A,MatFactorType ftype,Mat *F) > >directly. > > Barry > >> On Aug 14, 2015, at 10:07 AM, Romain Thomas <[email protected]> wrote: >> >> Hi, >> Thank you for your answer. >> My problem is a bit more complex. During the simulation (³real time²), >>I need to upgrade at each time step the matrix A and the >>MatassemblyBegin and MatassemblyEnd take time and so, in order to avoid >>these functions, I don¹t use ksp or pc. I prefer to use > the functions MatLUFactorNumeric, MatLUFactorSymbolic and MatLUFactor. >And so, I want to know if there is similar functions for KLU. (I tried >for Cholesky and, iLU and it works well). >> Best regards, >> Romain >> >> >> From: Matthew Knepley [mailto:[email protected]] >> Sent: vrijdag 14 augustus 2015 16:41 >> To: Romain Thomas >> Cc: [email protected] >> Subject: Re: [petsc-users] petsc KLU >> >> On Fri, Aug 14, 2015 at 9:23 AM, Romain Thomas <[email protected]> >>wrote: >> Dear PETSc users, >> >> I would like to know if I can replace the following functions >> >> MatLUFactorNumeric(Mat fact,Mat mat,const MatFactorInfo *info) >> MatLUFactorSymbolic(Mat fact,Mat mat,IS row,IS col,const MatFactorInfo >> *info) MatLUFactor(Mat mat,IS row,IS col,const MatFactorInfo *info) >> >> by >> >> MatLUFactorNumeric_KLU(Mat F,Mat A,const MatFactorInfo *info) >> MatLUFactorSymbolic_KLU(Mat F,Mat A,IS r,IS c,const MatFactorInfo >> *info) MatGetFactor_seqaij_klu(Mat A,MatFactorType ftype,Mat *F) >> >> in my code for the simulation of electrical power systems? (I >> installed the package SuiteSparse) >> >> Why would you do that? It already works with the former code. In fact, >> you should really just use >> >> KSPCreate(comm, &ksp) >> KSPSetOperator(ksp, A, A); >> KSPSetFromOptions(ksp); >> KSPSolve(ksp, b, x); >> >> and then give the options >> >> -ksp_type preonly -pc_type lu -pc_mat_factor_package suitesparse >> >> This is no advantage to using the Factor language since subsequent >> calls to >> KSPSolve() will not refactor. >> >> Matt >> >> Thank you, >> Best regards, >> Romain >> >> >> >> -- >> What most experimenters take for granted before they begin their >>experiments is infinitely more interesting than any results to which >>their experiments lead. >> -- Norbert Wiener > > > > >
