adding SNESSetLinearSolve()

[Barry Smith]

On Nov 8, 2007, at 3:00 PM, Lisandro Dalcin wrote:

> On 11/7/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>       Go ahead add and add the features you'd like.
>
> Well, I was thinking about all this. As I take very seriously all your
> concerns, I've decided to implement anyway a full features 'python
> shell' SNES. I was far more easier than I thought.
>
> Once this is ready, I'll ask you to review a bit all the features, in
> order to take a decision of what could be usefull and what is just
> noise. Deciding this will be far easier with a sample working code.
>
> In the proccess, I wanted to reuse the different default
> implementations of line search for SNES, and I realized that they are
> tied to SNES being of type SNESLS. I believe this coupling of
> linesearch routines to SNESLS type can be avoided by taking advance of
> the context argument passed in calls. Would this change be OK?

    If it can be done.

    I've always viewed the line search as going hand in hand with  
SNESLS,
that is I never though about trying to reuse the line search routines  
for some
other SNES. Of course if they can be made to be reused for others that  
would
be best.

     Barry

>
>
>
>> On Nov 7, 2007, at 10:01 AM, Lisandro Dalcin wrote:
>>
>>> On 11/1/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>>>> On Nov 1, 2007 9:24 AM, Lisandro Dalcin <dalcinl at gmail.com> > >>
>>>>> For example, I would love to have SNESSetPresolve/SNESSetPostSolve
>>>>>> and
>>>>>> SNESSetPreStep/SNESSetPostStep, and perhaps a
>>>>>> SNESSetPreLinearSolve/SNESSetPostLinearSolve. Of course, this  
>>>>>> make
>>>>>> the
>>>>>> API grow with features that are not frecuently needed.
>>>>
>>>>  I'd like to understand why they are ever needed and if they can be
>>>> done
>>>> with current constructs?
>>>>
>>>
>>> Barry, sorry for the delay, but I was really busy. I'll try to
>>> clarify my needs.
>>>
>>> * I'm using PETSc exclusively from Python. In such a dynamic  
>>> language,
>>> implementing complicated application setups is far easier than in
>>> C/C++.
>>>
>>> * Of course, Python is no efficient for low-level stuff. Do I  
>>> actually
>>> make use of a PETSc-based C++ application (PETSc-FEM) to assemble
>>> vectors and matrices, manage fixations/boundary conditions and  
>>> linear
>>> constraints between dofs.
>>>
>>> * Some application setups will need PETSc solvers (SNES/TS) to  
>>> provide
>>> a way to set user callback routines (or hooks). That's the reason I
>>> talked about adding SNESSetPresolve/SNESSetPostSolve and
>>> SNESSetPreStep/SNESSetPostStep. This way, PETSc can be adapted to  
>>> the
>>> application needs if required, and not the other way.
>>>
>>> * Taking again SNES as an example: Why it provides  
>>> SNESSetUpdate()???
>>> It is not used in any other place in PETSc sources. I guess at some
>>> point someone needed a user callback routine to be called just  
>>> before
>>> computing the Jacobian, so it was added. I'm currently using it to
>>> compute/update auxiliar linear operators to be used in defining a
>>> problem-based preconditioner for NS equations. Of course, I could do
>>> this in computeJacobian() rutine, but then I would have to special
>>> case the use of this preconditioner in order to compute the auxiliar
>>> operator; in short my application has to adapt to PETSc.
>>>
>>> * Taking TS as an exaple. Why it provides SetPreStep/SetPostStep???
>>> They are also not even used in a TS example. I guess again that at
>>> some point someone needed it. And then, I'm asking to have more of
>>> that, and no less.
>>>
>>> In the end, perhaps the better way for me to go is to implement SNES
>>> and TS directly in Python and do what I want, it is not much hard  
>>> and
>>> there should not be performace issues at this level. But I would
>>> really prefer to make SNES/TS more configurable (via setting general
>>> pourpose user callback routines) in order to not duplicate code and
>>> efforts.
>>>
>>> So the real quention you have to answer is the following: Should I
>>> continue fighting for making PETSc solver more 'user- 
>>> configurable', or
>>> should I direct my efforts in implemening all those features  
>>> directly
>>> in Python, where implementing truly polimorfic code is far, far  
>>> easier
>>> than in C?
>>>
>>> In the near future, application written in C/C++/Fortran could take
>>> advantage of petsc4py to implement custom 'shell' matrices, linear
>>> solvers, preconditioners, nonlinear solvers and time steppers.
>>> Something like
>>> SNESCreate(comm,&snes)
>>> SNESSetType(snes, "python")
>>> SNESPythonCreate(snes, "package.module.MyNewtonSolver")
>>>
>>> Woud'nt that be a really nice feature?
>>>
>>> I'm not sure if all you consider Python (plus wrapped compiled code)
>>> as a feasible way to drive large-scale simulations, but I really
>>> believe it is. Furthermore, from the last three years I worked  
>>> hard to
>>> make it possible: now Python users can use mpi4py, petsc4py,  
>>> slepc4py
>>> and tao4py and manage applications with negligible overhead for  
>>> medium
>>> to large data transfers/ problems.
>>>
>>>
>>> --
>>> Lisandro Dalcín
>>> ---------------
>>> Centro Internacional de Métodos Computacionales en Ingeniería  
>>> (CIMEC)
>>> Instituto de Desarrollo Tecnológico para la Industria Química  
>>> (INTEC)
>>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
>>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
>>> Tel/Fax: +54-(0)342-451.1594
>>>
>>
>>
>
>
> -- 
> Lisandro Dalcín
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>