[petsc-users] Provide Matrix Factorization to EPS for Generalized Eigenvalue Problem

[Peetz, Darin T]

I don't fully understand what the empty KSP is doing either, because it seems to me that if a KSP object was properly destroyed, KSPCreate() should have to be called again before it is used again, right?  So it must not be fully destroyed or else the second linear system solve would fail, but something is happening to it such that the symbolic factorization is redone.

Like I said, the fix I implemented seems to work (even if it doesn't seem necessary), so I don't know that it really needs any more attention.  However, I was able to reproduce the behavior in the example you sent me.  If you're curious, running the program as normal should behave the same way as the original example.  Running with the option "-destroy_eps" destroys and recreates the EPS object, and running with the additional option "-empty_ksp" gives the EPS object an empty KSP before it is destroyed.  At least when I ran it on my machine, I got 1 symbolic factorization for the original program, 2 with the "-destroy_eps" option, and 1 with both "-destroy_eps" and "-empty_ksp".

Thanks,
Darin
________________________________________
From: Jose E. Roman [jroman at dsic.upv.es]
Sent: Wednesday, November 02, 2016 3:29 AM
To: Peetz, Darin T
Cc: petsc-users at mcs.anl.gov
Subject: Re: [petsc-users] Provide Matrix Factorization to EPS for Generalized Eigenvalue Problem

> El 1 nov 2016, a las 20:42, Peetz, Darin T <peetz2 at illinois.edu> escribió:
>
> Thank you for providing the example.  I have managed to get it working properly; however, after looking at the example, I have one more question.
>
> First, let me provide a little background on how the code is set up.  I have one function that takes care of solving the linear system of equations, and a separate one that takes care of the eigenvalue problem.  The KSP object for the linear system is passed between both functions, and kept for the duration of the program to save some of the cost of factorizing the matrix each time.  I have been keeping the EPS object local to the function that takes care of the eigenvalue problem since it is only relevant within that function, and I haven't seen a need to reuse the same EPS object in every iteration (I'm assuming the cost of creating the EPS object itself is relatively small).  The reason for the extra symbolic factorizations seems to have been that when I destroyed the EPS object before it goes out of scope, it also destroys the underlying KSP object that I provided.
>
> Basically, I'm wondering if my assumption about the cost of creating the EPS object is correct.  Is it okay to recreate the EPS object every time the eigenvalue function is called, or does this create a significant overhead?  It seems that if I try to reuse the same EPS object I have to make sure I'm reusing the same A-matrix as well, or else the ST object redoes both the symbolic and numeric factorizations (so the same K matrix is numerically factorized twice in each iteration) each time.  Thus I would be able to save a significant amount of memory if I could let the EPS object and A-matrix exist in a local scope.
>
> As a side note, I worked around the KSP destruction issue by providing an empty (uninitialized) KSP object to the EPS object after calling EPSSolve and extracting the eigenvalues/eigenvectors.  This is functional but seems like a bad/crude approach.  Is there a more elegant way to "free" the KSP object from the EPS object once it is no longer needed, or should I stick with this approach?
>
> Thanks a lot for your help,
> Darin

STSetKSP() increases the reference count of the KSP object, so when EPS is destroyed, the KSP object remains. I don't understand why you need to provide an empty KSP. Regarding your question about recreating EPS, yes the cost can be considered small.

Jose


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ex14.c
Type: text/x-csrc
Size: 9008 bytes
Desc: ex14.c
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20161102/14c7c05b/attachment.c>