Reducing number of NOX-based solvers

[vovannikov]

Description

This is the first part of work in relation to #300.

As discussed on the meeting, the number of solver classes is excessive and should be reduced. I would start with this part of the NOX related refactoring, since this seems to be the simplest task, should be good to get familiar with the other classes too. I just would like to discuss the preliminary plan and a few consequences of this decision, such that everyone is aware of them.

If no objections, I will start with these modifications. Most probably, something else appears while working on these items.

Possible Solution and Definition of Done

Tell us what needs to happen and outline a possible solution. If possible, provide a step-by-step task list along the lines of:

• Delete the base class Solid::Nln::SOLVER::Generic since we agreed to rely solely on NOX (src/structure_new/src/nonlinear_solver/4C_structure_new_nln_solver_generic.hpp)
• Delete or refactor class Solid::Nln::SOLVER::NOX (src/structure_new/src/nonlinear_solver/4C_structure_new_nln_solver_nox.hpp)
• Delete classes, which implement a specific solver via setting up certain options in the parameters list, this should be done via the corresponding XML files. These are:
  Solid::Nln::SOLVER::FullNewton (src/structure_new/src/nonlinear_solver/4C_structure_new_nln_solver_fullnewton.hpp)
  Solid::Nln::SOLVER::PseudoTransient (src/structure_new/src/nonlinear_solver/4C_structure_new_nln_solver_ptc.hpp)
  Solid::Nln::SOLVER::SingleStep (src/structure_new/src/nonlinear_solver/4C_structure_new_nln_solver_singlestep.hpp)
  Solid::Nln::SOLVER::Uzawa (src/structure_new/src/nonlinear_solver/4C_structure_new_nln_solver_uzawa.hpp) (already obsolete)
• Delete factory Solid::Nln::SOLVER::Factory (src/structure_new/src/nonlinear_solver/4C_structure_new_nln_solver_factory.hpp), since the default factor NOX::buildSolver() could be used.
• Similar refactoring to be performed within folder solver_nonlin_nox.
• I am also with the presence of flags isinit_ and issetup_. In general, state-dependency always makes it difficult to maintain the code and here we have even two flags. Maybe I could do something to simplify it, maybe it gets postponed for a later step.

Side-effects

1. Outputs are not customized anymore, we stick to the default output provided by NOX. Frankly speaking, the current customizations are not significant and nearly identical to the default.
2. The implementation of the Pseudo-transient solver from solver_nonlin_nox gets removed. Note that the default Pseudo-transient solver from NOX requires Thyra.

Interested Parties

@vryy @vovannikov @maxfirmbach @sebproell @mayrmt @georghammerl

[vryy]

Hi @vovannikov, thanks for capturing this list. I would advise not to delete Solid::Nln::SOLVER::Generic because it's the interface of structure_new to solver_nonlin_nox. A better name, e.g., Solid::Nln::Solver may be chosen, and additionally setting the real NOX nonlinear solver using ParameterList.

[mayrmt]

@vovannikov thanks for looking into this and for posting your first analysis of the problem! Sounds like a plan to me.

If you encounter some missing functionality in NOX, please let us know. We can always reach out to the NOX development team to explore options to actually contribute NOX.

Regarding output to the terminal, I am totally fine with relying on NOX default output for the time being. This for sure is not our biggest problem, so let's beautify the output at a later stage.

Regarding isinit_ and issetup_, this is spread all over the code base. We are actively working to remove it for exactly the reasons that you are mentioning. I don't know, how hard it is to remove it from the solid time integration. @sebproell might have some experience, since he has been pushing to remove this in the past.

[amgebauer]

Thanks for pushing this forward @vovannikov!

Maybe you already planning it, but I'm missing it in the description above. We should start with an abstraction of the NOX interface in 4C and wrap it in a way we want the interface with the nonlinear solver to avoid that we bake design decisions of Trilinos into 4C. Those are currently already causing a lot of trouble.

[vovannikov]

@amgebauer, you raised a very important point, it will be tackled. I will turn to this in the next PRs after completing this first list of actions.

[mayrmt]

@amgebauer, I agree that we might want to define our own interface to the nonlinear solver. However I believe that this is right now not the top priority. The current interface is in a disastrous state, that needs to be cleaned first. Furthermore, the current state is most likely not the fault of any design decision in Trilinos, but rather originates from our "suboptimal" approach of using (and reimplementing large parts of) NOX.

We have briefly discussed some ideas for possible abstractions. Details are unclear right now, so we need to clarify many aspects first before moving in this direction.

[sebproell]

@vovannikov I agree with the overall strategy! Some thoughts:

• We tend to accept a (temporary or permanent) loss in functionality if keeping the functionality is a major roadblock and it is not actively used/tested anyway. Just bring up any such cases and we can often quickly decide if we still need this feature or in which form.
• init and setup are just wrong, IMO. I will gladly approve any PR that removes these in favor of proper construction. This often has the side effect that you need to pass in the parameters instead of reading them from globals. Any work in this direction is much appreciated by taskforce modularization 🙏
• From my experience with the 4C code base, I can say that starting from a top-down perspective and identifying parts that are not used, merging them into a readable form, etc., helps to get familiar with the code base and, at the same time, starts to cut down the sheer number of files. However, at some point, I think @amgebauer's point is really important, namely, that we start to create a simple interface to NOX from a bottom-up perspective. What I mean by that is to design this interface on a clean slate, informed by the requirements 4C has, but without adhering to any preconceived interfaces that we or Trilinos use today. If we really want to use the NOX interface and make other people use it in their implementations (see e.g. Add first version of new reduced lung module #304 (comment)) this interface has to be sane. Most importantly, simple things should be simple, regardless of which physics exactly I am working in. The absolute minimum for me would be to perform a Newton-Raphson when I have a function that evaluates a residual and a jacobian based on our vectors, without any other design restrictions (inheritance hierachies) forced on me. (edit: you already replied while I was writing. Feel fee to integrate what is useful into the other issue)

[sebproell]

@mayrmt I would even say, right now, there is no interface to NOX, or at least none I could identify. Actually, this is kind of my point; we should define one and interact with it sooner rather than later. We need this abstraction to interact with our Core::LinAlg::Vector (#84). The fact that it currently holds Epetra_Vector is a detail that we need to stop relying on. The non-existent NOX interface is what is holding up the next steps in further cleaning the vectors.

[vovannikov]

@sebproell, thank you for your hints. Indeed, in the whole refactoring to be performed within #300 I am targeting to get rid completely of the explicit usage of Epetra_Vector and switching to Core::LinAlg::Vector, but that it is for the next steps. I think keeping this goal in mind will also help to identify non-optimal design decisions in the NOX interface which force others to develop their own implementations.