Eigenvalue executioner improvement for supporting Picard iteration

[YaqiWang]

Rationale

During refactoring Picard iteration to enable Picard iteration for steady-state calculations including eigenvalue calculations, I found few issues.

When Eigenvalue is master:

1. Possibly SLEPc options are not set properly during Picard iteration causing a SLEPc error;
2. EigenSystem does not support evaluating L2 norm of the entire residual of the eigen problem;
3. Initialization of eigen calculation in SLEPc solver is desired to be moved out so that we can perform some evaluations between initialization and eigen solve. It also make the solver able to use the solution of previous Picard iteration as the initial guess.

When Eigenvalue is sub-app:

1. An SLEPc error was observed when the eigenvalue calculation is called the third time during Picard iteration:

   0]PETSC ERROR: Argument out of range
   [0]PETSC ERROR: Too many EPS monitors set

2. Screen output is not prefixed properly. I was getting something like

   18 SNES Function norm 2.478709290258e-11 

   instead of

   sub0:   18 SNES Function norm 2.478709290258e-11 

3. The convergence history is not colored.

Description

These issues need to be fixed. Actually our major motivation of switching to the new eigenvalue executioner is to make the Picard iteration for multiphysics calculations simpler and more efficient.

Impact

Better usability of the new eigenvalue solver.

[YaqiWang]

Tag @fdkong .

[fdkong]

I will take care of this once the picard refactoring #12735 is merged.

[YaqiWang]

Thanks Fande. The tests are at bf7d106c80452f323614045257074b608ba7d9de.

[YaqiWang]

@fdkong Update on this issue: the new hash in current next branch for the tests is b1277db.

[awr5209]

Has there been any progress on this issue, or maybe a workaround? I've been getting the "Argument out of range, too many EPS monitors set" error on the third solve when using Eigenvalue as a sub-app.

[fdkong]

Has there been any progress on this issue, or maybe a workaround? I've been getting the "Argument out of range, too many EPS monitors set" error on the third solve when using Eigenvalue as a sub-app.

I have added some fixes to libmesh side, and it might help. Could you take a try, and report it back

[fdkong]

Make sure you have this commit https://github.com/libMesh/libmesh/pull/2160

[awr5209]

Your fixes worked! Thank you!

[YaqiWang]

I can confirm that eigenvalue problem as a MultiApp is now working, although some minor output issues. Also there is no way to let the eigenvalue subapp to use the previous solution as the initial guess. Eigenvalue problem as master still does not work.

[YaqiWang]

I'd like this issue to be reopened because Item 3 when Eigenvalue is master, Item 2 and 3 when Eigenvalue is slave are not fixed yet. Using the previous solution as the initial guess in multiapp should also be taken care off (I did not list it in my original issue). Possibly the initialization on the solver side has been in place possibly with SlepcEigenSolver<T>::set_initial_space, but it has not been used yet. I am also not sure SlepcEigenSolver<T>::set_initial_space requires copying solution vector, it will be ideal to avoid that. It should behave like what we have with snes. A minor thing related with the tests of this issue in moose/test/tests/problems/eigen_problem: in the inputs with Eigenvalue executioner, the eigen kernels are better to have a negative sign since we changed the sign during fixing #13728.

Another very important desired improvement: free_power_iterations should be considered as initial free power iterations, during Picard iteration, we should not need more free power iterations because the solution is already fair close to the final solution. If we do need free power iterations during Picard iteration, we should have another parameter like free_power_iterations_in_picard. Nonlinear Newton iteration converges faster than free power iterations, thus having unnecessary free power iterations is a waste. This free_power_iterations_in_picard should be affect things inside EigenProblem::solve, while free_power_iterations should be in place in side of Eigenvalue::init.

[YaqiWang]

Tag @permcody and @fdkong since I do not have power to reopen issues.