Topic: Petsc nonlinear solver support?

Hello, everyone.
I understand that the petsc support in oofem code merely means the linear solver support.As far as I know, Petsc also provide powerful nonlinear solvers through SNES interface, Libmesh and Dolphin codes both have their own petscSnes interfaces to wrap this  petsc snes interface, so they can also provide petsc nonlinear solvers, I wonder whether it is possible to provide this support in oofem?
Does it need  much coding work?
Any advice on how to do it?

2

Re: Petsc nonlinear solver support?

Hi,
yes, oofem uses only linear solver interface from PETSc and is relying on its own nonlinear solvers. In principle, it is possible to develop such an interface. However, I could not estimate the effort needed, as I am not familiar with SNES.
In principle, all nonlinear solvers should be derived from parent SparseNonLinearSystemNM class, which defines the oofem interface for any nonlinear solver. Implementing the SNES support would mean to create a derived class from SparseNonLinearSystemNM and implement it using SNES interface. It could, of course, take advantage of existing PETSc linear solver support. Once this is achieved, the new solver can be plugged in without any further modifications.

Hope that it helps,
Borek

Re: Petsc nonlinear solver support?

I actually tried writing a SNES-wrapper several years ago, then I found that I really didn't have any need for it at all.
It would only be possible to use with a PETSc matrix (and OOFEM's PETSc linear solver-wrapper wouldn't be used at all, it would be handled internally from the SNES-call).

However, I didn't think it was even worth including. OOFEM already supports a fair selection of options for nonlinear problems, and newton solvers are really quite simple to write. I had a look at SNES, and there seem to be a couple of features that we currently don't offer, but I've never really had the need for more than a trivial modified NR-solver.
Also, things like checking convergence with DOF-grouping etc. wouldn't be supported.


But you basically just have to overload SparseNonLinearSystemNM::solve and make a few wrapper functions for the NR-callbacks, and that's about it.



If we could make use of the smoothing to get proper multigrid support that would be an awesome feature. (But realistically, I think algebraic smoothing of the assembled matrices aren't going to cut it (to expensive as a preconditioner), we need mesh-multigrid, which needs a lot more OOFEM-code).

Re: Petsc nonlinear solver support?

Hi, Mikael
Thank you for letting me know you had tried writing a SNES-wrapper and your valuable advice, but I am not sure whether I totally get your point. 
After studying the tutorial and some examples about SNES in Petsc, I think the major step in writing a SNES-wrapper should be like this:
1.    create a snes solver.
2.    Choosing nonlinear solver type.
3.    Set From options.
4.    Set SNES residual function and Jacobian.
5.    Solve and destroy.
I understand that the above steps are as straightforward as calling a few SNES functions. The major steps to consider are the designing of the FormFunction() and FormJacobian() functions to calculate the residual vector and jacobian matrix. The two functions should use the Petsc Vector and matrix objects as input and output variables. But in oofem, the engnm model uses FloatArray and SparseMtrx in residual and jacobian calculation functions. So there should be conversions  between oofem and Petsc in vector and matrix types(whether by passing values or by passing address, maybe address passing is not possible due to different types). I wonder how to resolve this?
Can you please give some advice on this?
And What do you mean by “It would only be possible to use with a PETSc matrix”? Couldn’t I just use the oofem Sparse matrix, and conversion it to PETSc matrix whenever need?
Do you still have the SNES-wrapper code?

Re: Petsc nonlinear solver support?

I don't know where the code went, sorry.

The 5 steps you list is what you should do in the SparseNonLinearSystemNM::solve  method. Compare with the petsc linear solver.


Converting matrices is no good for many reasons;
1. Double the memory usage
2. Having to write converters for all the matrices.
and, well, no need to list any other reasons, these 2 are critical enough so that this can never be considered an option.

FormJacobian should be a wrapper to calling EngngModel::updateComponent().
See the linear petsc solver interface, it's basically the same. It shows you how to extract the Petsc Mtrx type and how to extract the data from the FloatArray to a Petsc Vec.

Re: Petsc nonlinear solver support?

Thank Mikael and bp! It really helps me a lot!