moose icon indicating copy to clipboard operation
moose copied to clipboard

Started the Convergence system

Open joshuahansel opened this issue 1 year ago • 2 comments

This PR revives https://github.com/idaholab/moose/pull/26744.

This creates a new system: Convergence. See https://github.com/idaholab/moose/issues/24128.

I'm putting this up now so that I can document some TODOs. Because it's in a messy state, I plan to squash everything into one commit before merging.

Tasks that remain:

  • [ ] Consider any necessary changes for the checkConvergence() API. Currently I have iteration index as the one and only argument, since we may want to use the same convergence class for multiple types of convergence check, and different types of convergence check will need to obtain that index differently. The same argument can be applied to others. Also I think that some classes will only be compatible with certain types of convergence check. We would probably want to do some checking to make sure it's used in a compatible way. Perhaps we should have some kind of IterationType argument? I'm open to other ideas.
  • [ ] Understand the role of EquationSystems - does it do anything to set convergence parameters in there? Should Convergence being doing that? Some parameters in ResidualConvergence are unclear on if they're actually used, like the linear solve parameters. They get set in the EquationSystems object (which might be eventually set to PETSc), but at least some do not seem to come back into the class in the convergence check, maybe only getting used in libMesh's own convergence checks?
  • [ ] Throw an error if the user supplies any shared convergence parameter to the executioner when they supply a ResidualConvergence? The current behavior is to allow the executioner parameters but override them. That's maybe the simplest implementation-wise, but seems very error-prone for users.
  • [ ] Improve PostprocessorConvergence to perform checks of execute_on. Here the Convergence would need to know what kind of iterations it will be used with, so we need to think about how to do this.
  • [ ] If ResidualConvergence needs to have interaction with EquationSystems, have it be a singleton? Otherwise you could have some construction-order-dependent behavior.
  • [ ] Address any relevant comments from https://github.com/idaholab/moose/pull/26744.

joshuahansel avatar Oct 14 '24 21:10 joshuahansel

Job Documentation, step Docs: sync website on 87d0ee0 wanted to post the following:

View the site here

This comment will be updated on new commits.

moosebuild avatar Oct 15 '24 00:10 moosebuild

Job Coverage, step Generate coverage on 87d0ee0 wanted to post the following:

Framework coverage

f35734 #28848 87d0ee
Total Total +/- New
Rate 85.09% 85.11% +0.02% 87.08%
Hits 106774 106976 +202 593
Misses 18703 18715 +12 88

Diff coverage report

Full coverage report

Modules coverage

Contact

f35734 #28848 87d0ee
Total Total +/- New
Rate 90.45% 90.41% -0.05% 89.87%
Hits 4936 4957 +21 71
Misses 521 526 +5 8

Diff coverage report

Full coverage report

Full coverage reports

Reports

Warnings

  • framework new line coverage rate 87.08% is less than the suggested 90.0%
  • contact new line coverage rate 89.87% is less than the suggested 90.0%

This comment will be updated on new commits.

moosebuild avatar Oct 16 '24 01:10 moosebuild

I'm considering renaming ResidualConvergence to FEProblemDefaultConvergence since it does more than check residual norms. It has tolerances for xnorm and snorm too, for example.

joshuahansel avatar Oct 23 '24 22:10 joshuahansel

OpenMPI failure is a lie. Invalidate makes different tests fail.

joshuahansel avatar Oct 30 '24 13:10 joshuahansel

@GiudGiud @lindsayad Ready for review

joshuahansel avatar Oct 30 '24 14:10 joshuahansel

lots of functions longer than 6 lines

Most of those are inherited technical debt 😄 For example, there was a bunch of cut and paste from problems into convergences. My long-term plan here is to destroy these convergences in favor of smaller pieces. I see these convergences (e.g., FEProblemConvergence) as temporary objects for backwards-compatibility. Then, refactored, smaller convergences replace them in time.

joshuahansel avatar Oct 30 '24 17:10 joshuahansel

Yes that makes sense. You already cut out the "min/max" iter based convergence from that object.

GiudGiud avatar Oct 30 '24 19:10 GiudGiud

@GiudGiud @lindsayad Ready for another round. I believe I've addressed your comments, so please check them off to confirm.

joshuahansel avatar Oct 31 '24 20:10 joshuahansel

Broke next:

https://civet.inl.gov/job/2536243/ https://civet.inl.gov/job/2536245/

loganharbour avatar Nov 07 '24 20:11 loganharbour

Fixing with https://github.com/idaholab/moose/pull/29028

joshuahansel avatar Nov 07 '24 23:11 joshuahansel