Add adaptive tolerance scaling for boundary and gradient algorithms in variational optimization - #410
Open
leburgel wants to merge 3 commits into
Open
Add adaptive tolerance scaling for boundary and gradient algorithms in variational optimization#410leburgel wants to merge 3 commits into
leburgel wants to merge 3 commits into
Conversation
Codecov Report❌ Patch coverage is
🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds adaptive tolerance scaling, where the tolerance of the contraction algorithm is set based on the current norm of the gradient (default scaling factor of
1.0e-3). The tolerance of the gradient algorithm in turn is set based on the contraction tolerance (default scaling factor1.0e1).On the README example, these default settings give a 1.5x speedup in walltime needed to reach a given energy value starting from the same initial guess. I'll see what the tests say for now, and do some more trials in the meantime.
At the same time, this reworks the way the per-iteration info metrics are stored and added. Previously, the
contraction_metricsandgradnorms_unitcellgot a new entry every time cost function was called. These function evaluations don't necessarily match the iterations of the optimization loop. In particular, entries were added for every rejected step during the line search, which just seemed needlessly confusing. I changed to workflow to record the current values in the cost function, but only add entries in thefinalize!routine, which is actually called after every iteration (i.e. every accepted step).This is also in anticipation of adding preconditioning, which naturally requires access to the current gradient norm.