Dear Shri, I am by no means putting your arguments in doubt. I apologize if I gave that impression. I am however looking for a reference that we can cite when making claims on the performance of KLU. Did you publish your results somewhere?
Thank you. Domenico. ________________________________________ From: Abhyankar, Shrirang G. [[email protected]] Sent: Tuesday, August 18, 2015 6:45 PM To: Domenico Lahaye - EWI; [email protected] Subject: Re: [petsc-users] petsc KLU Domenico, Here are the results for a power flow application.I don’t remember the size of the system. Package + Ordering MatSolve Sym. Fact Num. Fact Ordering KSPSolve Numeric ratio Linear solve ratio PETSc + QMD 1.60E-02 2.40E-02 9.99E-02 0.13 2.76E-01 1.14 1.90 PETSc + ND 3.20E-02 5.60E-02 9.40E-01 0.02 1.06E+00 10.68 7.31 PETSc + AMD 2.40E-02 2.00E-02 8.80E-02 0.01 1.45E-01 1.00 1.00 KLU + AMD 2.80E-02 2.80E-02 2.40E-01 0.01 3.08E-01 2.73 2.12 KLU + COLAMD 5.60E-02 4.00E-02 3.90E-01 0.01 5.00E-01 4.43 3.45 KLU + QMD 2.80E-02 1.20E-02 2.67E-01 0.13 4.40E-01 3.03 3.03 The numeric and linear solve ratios are the ratios w.r.t. to using PETSc + AMD. You can test the performance of KLU on the power flow example application $PETSC_DIR/src/snes/examples/tutorial/network/pflow/pf.c Shri -----Original Message----- From: Domenico Lahaye - EWI <[email protected]> Date: Tuesday, August 18, 2015 at 6:34 AM To: "[email protected]" <[email protected]> Subject: Re: [petsc-users] petsc KLU >Dear all, > > Have the disappointing results of KLU been reported somewhere? >Earlier claims made might reinforce claims that we want to make. > > Sincere thanks, Domenico. > >________________________________________ >From: Romain Thomas >Sent: Tuesday, August 18, 2015 1:10 PM >To: Domenico Lahaye - EWI >Subject: FW: [petsc-users] petsc KLU > >Hi, >You can find below the message from Shri. >Best regards, >Romain > >-----Original Message----- >From: Abhyankar, Shrirang G. [mailto:[email protected]] >Sent: maandag 17 augustus 2015 18:21 >To: Romain Thomas; Zhang, Hong >Cc: [email protected] >Subject: Re: [petsc-users] petsc KLU > >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 >> >> >> >> >> >
