Make the FEProblem creation more straight-forward

Motivation

Griffin uses a custom action to create problems for particular discretization schemes. Recently, we hit an issue with that custom problem creation related with the name of the FEProblem and restart. During steady-state calculation for generating a checkpoint file, I used Problem/type to test a new feature in the custom problem type. Griffin writes the checkpoint file with the default problem name in CreateProblemAction in MOOSE. In the following transient calculation, I only set Problem/restart_file_base, with which Griffin creates the custom problem and names the problem differently. Because of this name mismatch, the transient run does not restart the equation system of the problem. Checking the code in MOOSE for problem creation, I think there should be a way to create the problem more straight-forwardly without losing any flexibility, like allowing applications to create their own type of problem.

A minor issue can also be fixed during this improvement: Problem/name is not honored by CreateProblemDefaultAction when Problem/type is not set, or when CreatProblemAction is not in action.

Design

My suggestion is to let MooseApp holds a member variable for the problem type. This problem type defaults to FEProblem, and can be changed to EigenProblem if an eigenvalue problem is to be solved by MOOSE. MooseApp provides a setter to this variable to allow applications to change the problem type. We can remove CreateProblemAction and only keep CreateProblemDefaultAction, which will use the problem type held in MooseApp and the parsed parameters to create the problem. We can do this because in a MOOSE simulation, there should be and must be only one problem.

We probably can get rid of two member functions MooseApp::useNonlinear() and MooseApp::useEigenvalue() and make the code even simpler.

@lindsayad, @GiudGiud and @roystgnr were at the conversation of discussing this issue.

Impact

This can make using custom problem types simpler and avoid any potential name conflict during restart. Griffin will need to be patched if any changes are to be made in problem creation. There could be other applications affected. However, no impact to users is expected.

idaholab / moose