ukaea / ukaea/PROCESS

Allow the convergence tolerance to adapt automatically

Open
#602 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Convergence
Dominant language
Python
Stars
71
Forks
27
Avg merge
2d 18h
Merged PRs (30d)
33

Description

In GitLab by @mkovari on Jan 9, 2018, 10:45

In Issue #425 we made the convergence tolerance epsvmc a scan parameter, so that we can investigate whether a tight tolerance is causing problems with convergence. It might be possible to improve on this with an automatic system, as follows.

  • Option 1. (not implemented)
    If VMCON fails to converge after a specified number of iterations, maxcal, then epsvmc is automatically increased by a factor of 10.
    This procedure is repeated until either VMCON converges, or epsvmc exceeds 0.1
    A suitable message would be output to let the user know what has happened, and a new value of ifail would be created for this situation.
    Comments relate to Option 1

  • Option 2 (implemented)
    Store the best solution vector achieved during the run, and output this instead of the last solution, with a suitable warning. Note that this is the vector with the lowest convergence parameter, not the one with the lowest constraint residuals.

This turns out to be very easy to code inside VMCON:

if(sum < best_sum_so_far)then
           best_sum_so_far = sum
           best_solution_vector = x
end if
...
if (nfev >= maxfev) then
...
   !  Error return because there have been maxfev calls of fcnvmc1
   info = 2
   x = best_solution_vector
   sum = best_sum_so_far
   return
end if
etc

The terminal output for an unconverged run now looks like this:

==>   11  vmcon iterations. Normalised FoM =   1.942  Residuals (sqsumsq) = 4.5E-05  Convergence param = 1.0E-04
Best solution vector will be output. Convergence parameter =  7.752E-05

Bug: The values of the iteration variables output at the head of the output file were not the same as the values in the body of file. Fixed, I think, by correctly initialising the best_solution_vector.

  • If VMCON fails for any reason, the code could try a different value of epsfcn (finite difference step length for the numerical derivatives required by VMCON). Could be smaller or larger, or try both!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the VMCON handling of epsvmc, maxcal, epsfcn, and the best_solution_vector behavior described in the issue. Clarify whether the remaining scope is automatic tolerance changes, alternative finite-difference steps, or both. Done should include the selected fallback behavior, a suitable warning, and the specified output or failure status.

Written by the indexing model from the issue text.

Assessment

Tech stack
fortran
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.