Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question on different solvers, skyrmions simulations and topological charge. #605

Open
sfragkos opened this issue Nov 8, 2021 · 5 comments

Comments

@sfragkos
Copy link

sfragkos commented Nov 8, 2021

Dear Spirit users and developers,

I'm new on Spirit and I have a question on the different solver of LLG equation.

I'm trying to simulate skyrmions on a material with hex2d120 lattice. When I open my input file with the GUI, all the spins are ferromagnetically alligned and I push the "Random" button in the "Configurations" tab in order to start my skyrmion configuration. Is this method correct? I'm asking this because it seems that the skyrmion formation depends a lot on the initial spin configuration.

I also saw that there are many solvers of the LLG equation. Which is the best and most accurate for simulating skyrmions? From my previous experience on atomistic spin simulations, I used the Heun one. In addition, I saw the "Direct Minimization" checkbox in the "Parameters" tab. Is it accurate to use it?

And my last question is on topological charge calculations. What is the proccess to do such a calculation? Can I make a heatmap of "External field vs Temperature"?

I know it's a lot to ask but I am a little bit confused. I really hope you can answer me one by one all my questions.

Best regards,
Sotirios Fragkos

@MSallermann
Copy link
Member

MSallermann commented Nov 8, 2021

Hello there,
I'll try to give a relatively comprehensive answer.

[...] Is this method correct?

It entirely depends on what exactly you want to simulate, which you did not really describe. All I can say is that, starting from a random configuration and minimizing the energy will give you some kind of imperfect skyrmion lattice (only if the parameters of your Hamiltonian allow for that of course). In general you will have some defects in this lattice, depending on your boundary conditions, system size and initial configuration. A time-consuming way to find the ground state of your system which is not so biased by the initial configuration (but still by the other two factors) would be to perform simulated annealing with the Monte Carlo method. You could also "hand-craft" an initial skyrmion lattice in a python script. If you instead want to study isolated skyrmions, I would suggest to to start from the ferromagnetic configuration and just insert a skyrmion, which you can find under "local configurations". As I said, it depends ...

I also saw that there are many solvers of the LLG equation. Which is the best and most accurate for simulating skyrmions? From my previous experience on atomistic spin simulations, I used the Heun one. In addition, I saw the "Direct Minimization" checkbox in the "Parameters" tab. Is it accurate to use it?

This is indeed a bit of a confusing subtlety. Under the "LLG" method two technically distinct things are lumped in together. One is the time-evolution of a spin configuration (potentially at finite temperature) using the LLG equation and the other is the local energy minimization starting from an initial configuration. Which of the two you perform depends on the solver you use.

  • The LBFGS_XXX and VP_XXX solvers always perform an energy minimization. I recommend one of the LBFGS solvers for this task. The direct minimization parameter has no effect on them.
  • All the other solvers perform a time evolution, but if you activate the direct minimization parameter they will ignore the precessional part of the LLG and therefore perform a direct minimization. Let me stress, that it is not recommended to do this and just for educational purposes.
    As far as I am aware the Depondt solver is a good default choice for time evolutions. But Heun should work fine as well.

And my last question is on topological charge calculations. What is the proccess to do such a calculation? Can I make a heatmap of "External field vs Temperature"?

In a monolayer system, it would more or less look like this

from spirit import quantities
# other imports etc
with state.State("input.cfg") as p_state:
    # set up configuration/perform simulation
    # ...
    topological_charge = quantities.get_topological_charge(p_state)
    # ...

Of course you can make a heatmap. In a python script you would have to loop over temperature and the external field, perform the simulation, gather the data, and then plot the heatmap. Aside from the "perform the simulation" step, this isn't anything specific to Spirit and just an exercise in general Python scripting.

I hope that helps.

@sfragkos
Copy link
Author

Hello!

Thank you very much! This was actually really helpful!

Both VP and LBFGS give great results. I just have one more question.

In both cases, when I check the "Temperature" checkbox in the "Parameters" tab of the LLG and I set the desired temperature (or any value), nothing is changing to my system.

Do you know why is this happening?

Best regards.

@MSallermann
Copy link
Member

MSallermann commented Nov 10, 2021

Just to reiterate: The VP and the LBFGS solvers find a spin configuration that locally minimizes the energy, that is to say we are only interested in a final configuration where the torque on every spin vanishes. These configurations are of course not unique. Which one you end up with is influenced by the initial configuration and even the solvers. To a certain extent, one could say, it is arbitrary.

Now keep in mind that the energy depends only on the spin configuration (and the Hamiltonian) and not explicitly on the temperature. It only depends implicitly on the temperature, because the temperature causes random perturbations to the spin configuration.
That all is to say that adding a temperature influence to these solvers makes no sense, since the problem is entirely contained in the mapping between spin configuration and energy. That is why nothing is happening when you set a finite temperature.

To see a temperature dependence, you have to perform a time evolution with any of the solvers suited for that (see my comment above) and the direct_minimization parameter turned off. In practice, you would often find a configuration with the LBFGS solvers and then use different methods/solvers to study the temperature dependence.

@sfragkos
Copy link
Author

Thanks again for your answer.

Therefore, if for example I want to study the skyrmion population, I should use a "time-evolution" solver, since they don't rely on the initial spin configuration. If I use an local energy minimization solver, from what I've seen, different initial configuration (but same Hamiltonian paprameters) give different population of skyrmions.

What I'm interested in now, is to make the hysteresis loop (Normalized Magnetization - Applied field) at 0K, in the presence of skyrmions (including DMI). I performed some calculations with the GUI. Which solver do you propose for this? A time-solver seems like the obvious answer due to the problem stated above.

Best regards

@GPMueller
Copy link
Member

I should use a "time-evolution" solver, since they don't rely on the initial spin configuration

That is not correct. The time-evolution at 0K might reach a different energy minimum, but it will of course always depend on the initial configuration. At finite temperature (>0K) it will depend on even more factors.

Regarding the solvers, @MSallermann provided some pretty detailed descriptions above, but if you want to know more you should be able to find all relevant details in the Phys. Rev. B 99, 224414 (2019) paper and the cited literature.

Finally, I would recommend automating the calculation of a hysteresis loop with a Python-script instead of using the GUI. If you write out your final spin configurations you can easily check the results in the GUI after completing a full loop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants