Accelerate energy minimization using Optim.Manifold feature#453
Merged
Accelerate energy minimization using Optim.Manifold feature#453
Optim.Manifold feature#453Conversation
kbarros
force-pushed
the
optim-manifold
branch
from
178df5f to
abe95fe
Compare
ddahlbom
reviewed
Nov 15, 2025
Member
ddahlbom
left a comment
ddahlbom
left a comment
There was a problem hiding this comment.
This is really nice.
I tried it locally on a few simple examples. I'll try it later today on a few more complicated cases just to put it through its paces, but this looks great to me.
| u = (2v + (1-v²)*n) / (1+v²) # stereographic projection | ||
| return u | ||
| # Manifold where the first nspins are normalized spheres of dimension | ||
| # (nelems-1). Any remaining data is interpreted in the Euclidean metric. |
Member
There was a problem hiding this comment.
What is the reason for the "tail" being interpreted in the Euclidean metric? Is this condition ever met in normal usage?
Member
Author
There was a problem hiding this comment.
That's needed to support minimize_spiral_energy!, where the Euclidean "tail" is the spiral propagation wavevector k. Eventually we might also include the axis of rotation as an optimization variable.
There are some minor problems: - Vacancies not handled - Line search errors if stepsize goes to infinity (but projected point is finite).
kbarros
force-pushed
the
optim-manifold
branch
from
f85f136 to
0a278c5
Compare
kbarros
added a commit
that referenced
this pull request
Nov 19, 2025
This implementation avoids the need for "CG restarts" that would reset the stereographic projection axis. As a consequence, energy minimization can sometimes converge much faster (speedups ranging from 30% and 1000%, depending on problem).
kbarros
added a commit
to Sagar-Ramchandani/Sunny.jl
that referenced
this pull request
Nov 19, 2025
…uite#453) This implementation avoids the need for "CG restarts" that would reset the stereographic projection axis. As a consequence, energy minimization can sometimes converge much faster (speedups ranging from 30% and 1000%, depending on problem).
kbarros
referenced
this pull request
Nov 30, 2025
kbarros
referenced
this pull request
Nov 30, 2025
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
2 participants
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.
Energy minimization operates on spins subject to a normalization constraint. Originally, we imposed this constraint using stereographic projection. That strategy requires occasional restarts of the optimizer to allow for an update of the stereographic projection axis.
This PR removes the stereographic projection logic and instead uses the
Optim.Manifoldfeature to "retract" the optimization variables onto the spheres (or complex hyper-spheres, in the case of SU(N)). With this approach, "restarts" of the optimizer are rarely necessary, and energy minimization becomes much more efficient as a result. This new implementation also seems to achieve better precision.This PR will work robustly once JuliaNLSolvers/LineSearches.jl#185 is merged and released. That bug fix will allow the optimizer to "recover" from a line search that travels very far away from the allowed sphere. A related feature request is JuliaNLSolvers/LineSearches.jl#186, which would impose a maximum distance on the line search.