Closed ddahlbom closed 1 year ago
Thanks a lot, David! I am currently working on some projects. These features will be very helpful! I will test them with my problem.
These features will be very helpful! I will test them with my problem.
Thanks, @Hao-Phys. I should emphasize this was mostly designed for quick optimization or relatively small systems. I don't really know how well it will perform for more complicated situations and will likely need some more work/heuristics to be effective for larger problems. (And of course it will always be faster if you have an analytical gradient.) Let me know your experience if you try it!
EDIT: As Kipton pointed out in the meeting, the gradient from Sunny is really an analytical gradient. So you would probably only get a benefit by writing your own gradient if you highly optimized for that particular case (i.e., can implement optimizations that are not possible in Sunny because of its general nature).
The set_forces!
has been changed to set_energy_grad_dipoles!
and set_energy_grad_coherents!
and associated sign changes were made.
Some simple tests were added as well.
I will merge after the CI completes. This should be largely independent of any of the other changes, excepting Kipton's refactor of interactions.
PR 100!
This should give a general way to optimize spin configurations to minimize energy. Works in both
:dipole
and:SUN
modes. It relies onOptim.jl
and defaults to LBFGS.The intended use is just the touching up of spin configurations near the ground state. The function for this is
minimize_energy_touchup!(sys)
. It just runs for a maximum of 40 iterations and gives a warning if the optimizer hasn't converged.There's also a function
minimize_energy!(sys)
, which seems to work for random initial configurations. It checks whether any of the quasi-stereographic coordinates has "wandered too far." If so, it halts the optimization, reparameterizes the coherent states, and starts it again.It seems to be sufficiently fast for small unit cells.
All the functions called inside the optimization procedure are non-allocating except
optim_energy
, which allocates becauseenergy(sys)
allocates. It would probably be worth looking into this, unless there's some structural reason for it.(Apologies for my git incompetence. I should have squashed a bunch of things along the way.)