[petsc-users] create PC, KSP, ST separately and use in EPS

[Denis Davydov]

Dear all,

I am currently looking at ways to extend deal.II PETSc/SLEPc wrappers classes to allow
specification of linear solvers and preconditioners to be used in SLEPc eigensolvers
using deal.II objects and NOT the command line arguments.

All examples and unit tests I came across in SLEPc work with EPSCreate() followed by
EPSGetST(), STGetKSP() and KSPGetPC(). This however does not fit well into object-oriented C++ code.
Thus I plan to create each objects separately and pass them around.

I would like to ask if the way I see it (in terms of PETSc/SLEPc functions called) is conceptually correct:

— PETSc: Preconditioner class:
PCCreate()
PCSetType()
PCSetFromOptions();
—

— PETSc: Solver class (uses Preconditioner class):
KSPCreate()
KSPSetType()
KSPSetPC() // set PC created above
KSPSetConvergenceTest()
KSPSetFromOptions()
—

— SLEPc: SpectralTransformation class (uses Solver class)
STCreate()
STSetType()
STSetShift() // some specific settings to transformation
STSetKSP() // set KSP created above
—

— SLEPc: Eigensolver class (uses SpectralTransformation class)
EPSCreate()
EPSSetTolerances()
EPSSetConvergenceTest()
EPSSetWhichEigenpairs()
EPSSetProblemType()
EPSSetType()
EPSArnoldiSetDelayed() // any specific options to eigensolver
EPSSetST() // set spectral transformation created above
// solve
EPSSetDimensions()
EPSSetFromOptions()
EPSSolve()
—

Do this usage model sounds correct from SLEPc perspective?
What bothers me is that i do not call PCSetOperators()/PCSetUp() and KSPSetOperators()/KSPSetUp(),
which one would call while setting up PETSc objects to solve SLAE.
Nonetheless I assume those functions are executed somewhere inside SLEPc depending on
SHEP/GHEP and ST to be used.

Kind regards,
Denis.

[Jose E. Roman]

Post by Denis Davydov
Dear all,
I am currently looking at ways to extend deal.II PETSc/SLEPc wrappers classes to allow
specification of linear solvers and preconditioners to be used in SLEPc eigensolvers
using deal.II objects and NOT the command line arguments.

Yes, current deal.II wrappers for SLEPc are quite limited.

Post by Denis Davydov
All examples and unit tests I came across in SLEPc work with EPSCreate() followed by
EPSGetST(), STGetKSP() and KSPGetPC(). This however does not fit well into object-oriented C++ code.
Thus I plan to create each objects separately and pass them around.
PCCreate()
PCSetType()
PCSetFromOptions();
—
KSPCreate()
KSPSetType()
KSPSetPC() // set PC created above
KSPSetConvergenceTest()
KSPSetFromOptions()
—
— SLEPc: SpectralTransformation class (uses Solver class)
STCreate()
STSetType()
STSetShift() // some specific settings to transformation
STSetKSP() // set KSP created above
—
— SLEPc: Eigensolver class (uses SpectralTransformation class)
EPSCreate()
EPSSetTolerances()
EPSSetConvergenceTest()
EPSSetWhichEigenpairs()
EPSSetProblemType()
EPSSetType()
EPSArnoldiSetDelayed() // any specific options to eigensolver
EPSSetST() // set spectral transformation created above
// solve
EPSSetDimensions()
EPSSetFromOptions()
EPSSolve()
—
Do this usage model sounds correct from SLEPc perspective?

I see no problem with this approach.

Post by Denis Davydov
What bothers me is that i do not call PCSetOperators()/PCSetUp() and KSPSetOperators()/KSPSetUp(),
which one would call while setting up PETSc objects to solve SLAE.
Nonetheless I assume those functions are executed somewhere inside SLEPc depending on
SHEP/GHEP and ST to be used.

Correct, EPS/ST handle the KSP coefficient matrix so KSPSetUp() must be done at EPSSetUp() and not before.

Jose

Post by Denis Davydov
Kind regards,
Denis.

[Denis Davydov]

Thanks Jose for the prompt (as always) reply.
I will post further questions if I encounter any issues with the outlined approach.

Kind regards,
Denis

Post by Jose E. Roman

Post by Denis Davydov
Dear all,
I am currently looking at ways to extend deal.II PETSc/SLEPc wrappers classes to allow
specification of linear solvers and preconditioners to be used in SLEPc eigensolvers
using deal.II objects and NOT the command line arguments.

Yes, current deal.II wrappers for SLEPc are quite limited.

Post by Denis Davydov
All examples and unit tests I came across in SLEPc work with EPSCreate() followed by
EPSGetST(), STGetKSP() and KSPGetPC(). This however does not fit well into object-oriented C++ code.
Thus I plan to create each objects separately and pass them around.
PCCreate()
PCSetType()
PCSetFromOptions();
—
KSPCreate()
KSPSetType()
KSPSetPC() // set PC created above
KSPSetConvergenceTest()
KSPSetFromOptions()
—
— SLEPc: SpectralTransformation class (uses Solver class)
STCreate()
STSetType()
STSetShift() // some specific settings to transformation
STSetKSP() // set KSP created above
—
— SLEPc: Eigensolver class (uses SpectralTransformation class)
EPSCreate()
EPSSetTolerances()
EPSSetConvergenceTest()
EPSSetWhichEigenpairs()
EPSSetProblemType()
EPSSetType()
EPSArnoldiSetDelayed() // any specific options to eigensolver
EPSSetST() // set spectral transformation created above
// solve
EPSSetDimensions()
EPSSetFromOptions()
EPSSolve()
—
Do this usage model sounds correct from SLEPc perspective?

I see no problem with this approach.

Post by Denis Davydov
What bothers me is that i do not call PCSetOperators()/PCSetUp() and KSPSetOperators()/KSPSetUp(),
which one would call while setting up PETSc objects to solve SLAE.
Nonetheless I assume those functions are executed somewhere inside SLEPc depending on
SHEP/GHEP and ST to be used.

Correct, EPS/ST handle the KSP coefficient matrix so KSPSetUp() must be done at EPSSetUp() and not before.
Jose

Post by Denis Davydov
Kind regards,
Denis.