Add Magnetoelastics to the minimizer - #171
Open
jplauzie wants to merge 7 commits into
Open
Conversation
might need to add something to handle uniform translations/rotations, otherwise seems ready
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.
Hi,
This is a first pass at extending the steepest descent minimizer to work with elastics/magnetoelastics. The main changes are in minimizer.cu/removerigidbodies.cu. This shouldn't change any existing behavior if magnetoelastics are not enabled.
This takes the same approach that the existing magnetic steepest descent minimizer does, but for the elastic system: Do a steepest descent method on the displacement using just the force, dropping the transient eta/velocity term (as the precession term gets dropped in magnetics), with Barzilian-Borwein steps. The characteristic step sizes for the magnetic and elastic systems are very different, so magnetic and elastic steps are alternated until both systems hit their separate convergence criteria.
There are two big differences compared to the magnetic minimizer:
The dudu term in the BB1 rule has a habit of underflowing in float32 while it's being constructed, so there is a temporary rescaling, but this falls out once the actual BB step is constructed and has no effect on the results.
to match the magnetic minimizer, the convergence criteria is a lastDu (one could instead monitor the force?). Rigid body modes (uniform translation/rotation) will inflate this, causing the minimizer to take many more steps than is necessary, even after it's reached equilibrium, so they're just subtracted off. Currently, I subtracted them off of u/force directly. You could maybe do this just for the convergence check, instead of u itself. Convergence wise, either way is fine. I noticed the values for u can get quite large in long runs/minimizes, ~3e-9 or so, and I wasn't sure if that could cause noise problems if du is say ~1e-16 or so in float32, so i went with cleaning u directly. There is a flag to disable removerigidbodies, just in case someone doesn't want it.
I think minimizer.cu is mostly ready to go, absent a few minor tweaks. I need to pull out the diagnostic messages, and probably removerigidbodies does not need to be done every step, so performance-wise every 100steps or so is fine. The minimizer portion will work without removerigidbodymodes, it just inflates the number of steps it takes if it's not used.
removerigidbodymodes works mechanically (at least for simple test cases of uniform rho and a plain 2-D geometry). There's definitely some nonsense in terms of readability, unnecessary use of doubles on the GPU, etc. In principle it has the code to handle non-uniform rho/other geometries, but I've only tested against uniform 2-D sheets after i ran into the donut issue. I'm back from visiting family, so I should be able to get this cleaned up in the next few days.
So far, I've only tested it with FMs, with a uniform 2-D geometry, and a few starting magnetic configurations (uniform, vortex, etc), and it converges to the same states that a long run (25ns) does. It alsohandles a user-applied body-force. The function hooks are there for it to work with AFMs/altermagnets, but I don't know as much about them for magnetoelastics so I haven't tested them yet. I also don't know what would be a good test script for the test suite?
This PR also has 1 extra feature; I added a call to clean rigid modes to the time solver. This is still experimental and needs to be tested further, but it seems to be allowing the adaptive time solver to take larger steps for some scripts (not all). I'm still confirming it's not spurious, but I did not expect it to do anything at all, so that was a bit surprising.
magnetoelastictest3.txt
Attached is a script which shows a significant difference (on my machine, with cleaned rigid modes it takes ~2:15 to run. Without, ~9:52). So far, it seems to be scripts where PBC is disabled (so the no-traction BCs are used), and that are run for at least a few ns where there is any difference. My initial guess would be, cleaning rigid modes is compensating for some of the instability generated by the no-traction BCs that would otherwise build up over time? (Alas, not all of it. The donut shaped geometry is still unstable). More typical scripts like the ME dispersion script show no difference.