Open anne-glerum opened 6 years ago
Hi Anne, I agree this is a bit inconsistent, but not solving anything when setting Number of nonlinear iterations to 0 also seems a bit surprising to me (what if somebody expected to 'just do a linear solver' when setting this number to 0). Are you only concerned about the initial refinement stage? Then this would be quite similar to #1690, maybe the solution that I described there would already work?
I think the rationale that we've always had was this, in analogy to figuring out whether we need to keep iterating based on the tolerance: In order to determine whether we've reached the tolerance, we need to assemble the system (to compute the residual), and that gets us most of the way there to already doing one solve, so let's just do that as well. Here, the situation is different because you decide based on the number of iterations, not whether a tolerance was reached.
I'm in favor of always doing one iteration because otherwise there is really nothing you can say about the solution: it could simply be random numbers. Or how would you want to initialize the solution otherwise?
I have currently two use cases where I find it useful to be able to use 0 iterations.
When I am trying to construct initial conditions on large meshes to see whether I constructed them correctly. Solving the system in this case is unnecessary and expensive (and sometimes even impossible, when I have made a mistake, and then there won't be output to see what I did wrong).
When I am doing a pre-refinment, based on the (still to merge) isoterms plugin. This only uses the temperature to do the refinement, so every solving step is a waste of time.
This is also why the Newton solver is currently implemented as a for loop.
@gassmoeller although I can follow you reasoning, if we want to follow that reasoning for the nonlinear iterations, we should always do nonlinear iterations + 1 for everything. I think that that would become counter-intuitive quickly. The way I think about it is that if you are using a nonlinear solver to solver a nonlinear problem, all solves you do are nonlinear iterations. Therefore I would find it not logical that if the user specifically specifies that he/she wants 0 nonlinear iterations, that he/she gets 1 nonlinear iteration (and if he/she set it to 1, they also get 1).
@gassmoeller concerning #1690, Isn't the parameter Max nonlinear iterations in pre-refinement
meant for this? This parameter I find very useful, like for the cases Menno describes. With the restructuring of the solvers, this parameter now also always leads to at least 1 nonlinear iteration.
@anne-glerum @gassmoeller @bangerth @MFraters
It seems like there are two possible solutions to the problems outlined here and in #1690:
Max nonlinear iterations in pre-refinement
to Max initial adaptive refinement solves
. Allow the number to be >=0. Modify the code. Deprecate the original parameter name.Skip initial adaptive refinement solves
and default to False. Assert Max nonlinear iterations in pre-refinement
to be >0. If the latter parameter is declared, then assert that "Skip initial adaptive refinement solves" is False.I would probably favour the second possibility, both in terms of backwards compatibility and to separate linear from nonlinear solves. In both cases, I would argue that there should be an assertion that Max nonlinear iterations
is >0.
Opinions?
@jaustermann is this one fixed by your master plan?
@bobmyhill Not sure ... @gassmoeller does what we have discussed for #1690 fix this?
Not quite. #1690 will allow to skip the nonlinear iterations in pre-refinement (so that part is resolved), but it will not allow to use 0 nonlinear iterations (=no solve) in later timesteps. Is that something we want/need?
Ok, after a long discussion a number of us agreed on the following:
Skip solution during initial refinement
and Skip initial conditions during initial refinement
, and a new solver scheme do_not_solve
(for various application cases in which the initial refinement does not depend on the solution / does not depend on the initial conditions / or users want to check the initial conditions and the solver does not converge)set Max number of nonlinear iterations in pre-refinement = 0
and set Max nonlinear iterations = 0
, because we could not agree on what that would mean in terms of how many iterations should be done (one solver, or no solve at all). Also it would be unclear what that would mean for solver schemes like single Advection, iterated Stokes
(would it only skip the Stokes solution or also the advection equation?). We do allow Max nonlinear iterations = 1
and it shall be equivalent to using the single Advection, single Stokes
solver scheme.Since much of the above is independent of each other, and we should not break compatibility except for corner cases it can be implemented in separate small pull requests instead of one big change and everyone is welcome to implement their favorite part of the above specification.
Because of the do ... while loop, the iterated solver schemes always perform at least one nonlinear iteration, even though the 2 parameters controlling the maximum number of nonlinear iterations can be set to 0. Besides this behavior being unexpected when setting the max number to 0, in the initial refinement phase it can be really useful not to do any iterations (when not refining based on a solution variable). Maybe we could change the loops to while loops?