On Mon, 29 Oct 2007, Lisandro Dalcin wrote:
> On 10/29/07, Barry Smith <bsmith at mcs.anl.gov> wrote: > > I strongly resist this. Back in the bad old days, 1995?, there was > > some pressure to "allow SNES to use any linear solver package, not just > > PETSc's". WELL, the whole idea then and now is PETSc KSP is suppose to > > be a powerful enough wrapper to wrap ANY linear solver package; BUT > > now you want to impose a wrapper class below SNES that can call any > > solver package. This is obscene! KSP IS SUPPOSE TO BE EXACTLY THAT > > WRAPPER CLASS!!!!! > > In practice, the only way to wrap any solver package is > KSPPREONLY+PCSHELL. And you actually implement the linear solve in PC, > not KSP. This may be an error in our design, we may need a shell KSP. It would be nice not to need it, but ... > > This combination work great in many, many (almot all?) situations. > At the cost of lossing some features (perhaps not commonly used). Have > you ever tried to make Eisenstat&Walker working using a > KSPPREONLY+PCSHELL combination, where your Shell PC is actually using > a inner KSP? Of course, you can do it, but the way is not immediate. This is a valid point, we need to deal with. > > If it is not good enough we should fix it, not hack > > a wrapper below SNES. SNES uses KSP, and ONLY KSP to solve linear > > systems (of course since KSP/PC is a wrapper class it can do whatever > > you want). > > Understood. > > > If we just willy-nilly shove in extra functions randomly > > in PETSc, without regard to the overall design of PETSc we end up > > with Trilinos. > > You completelly convinded me with this argument ;-) > > > Can you please describe your linear solver algorithm in more detail > > using the following notation: > > In short, I need to solve two linear systems with the same matrix > using any PETSc KSP+PC combination and different rhs vectors. This is > for managing the update of a global dof (coupled with all other dofs) > evolving in the nonlinear iteration. > > But forget my use case. Special cases aren't special enough to break the > rules. > > > > - PCSHELL to currently have some deficiencies. > > As was discussed last week in email with Victor Eijkhout, the PCSHELL > > needs to be fixed so that the first argument to the PCApply_yours() etc > > is the PC, NOT the void*. > > Great!! I asked for changing this many, many time ago, and my proposal > was not accepted!! I had to find my way to pass-over this problem in > petsc4py. > > > Don't use a poor implementation of one of PETSc's classes > > to justify a horrible hack to PETSc. > > Well, PETSc already have some public stuff that could be seen as > hacks, symply because practicality beats purity. But I have to agree > that the way to go is extending/remplementing things in the right > place, and not by adding random stuff. > > I'll try to rethink the way a user can implement custom linear solves > on KSP, and let you know my results. > > If PETSc internals were implemented in C++, I would simply do: > > MyKSP: public KSP { > void solve(Vec b, Vec x) { > /* do something */ > KSP::solve(b1,x1) > /* do more*/ > KSP::solve(b2, x2) > /* fill result */ > x = ... > } You seem to be saying you want something much like a KSP shell? > } What are the operators for this KSP (the A and B?) do you set them in the SNESSetJacobian()? Is b1 the same size (n+1) as b? Is the Eisenstat walker test used on BOTH KSP::solve(b1,x1) and KSP::solve(b2,x2)? Barry > > But with the current implementation in C, this is possible but not so > easy to do. > > > >