[petsc-users] petsc KLU
Abhyankar, Shrirang G.
abhyshr at anl.gov
Tue Aug 18 11:45:18 CDT 2015
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 <D.J.P.Lahaye at tudelft.nl>
Date: Tuesday, August 18, 2015 at 6:34 AM
To: "petsc-users at mcs.anl.gov" <petsc-users at mcs.anl.gov>
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:abhyshr at anl.gov]
>Sent: maandag 17 augustus 2015 18:21
>To: Romain Thomas; Zhang, Hong
>Cc: petsc-users at mcs.anl.gov
>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 <hzhang at mcs.anl.gov>
>Date: Monday, August 17, 2015 at 10:08 AM
>To: Romain Thomas <R.Thomas at tudelft.nl>
>Cc: "petsc-users at mcs.anl.gov" <petsc-users at mcs.anl.gov>
>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:bsmith at mcs.anl.gov]
>>Sent: vrijdag 14 augustus 2015 17:31
>>To: Romain Thomas
>>Cc: Matthew Knepley; petsc-users at mcs.anl.gov
>>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 <R.Thomas at tudelft.nl>
>>>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:knepley at gmail.com]
>>> Sent: vrijdag 14 augustus 2015 16:41
>>> To: Romain Thomas
>>> Cc: petsc-users at mcs.anl.gov
>>> Subject: Re: [petsc-users] petsc KLU
>>>
>>> On Fri, Aug 14, 2015 at 9:23 AM, Romain Thomas <R.Thomas at tudelft.nl>
>>>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
>>
>>
>>
>>
>>
>
More information about the petsc-users
mailing list