This one has been a long time in the making! Here it is, ready for you to try:
Calculate Magnetic Anisotropy Energy (MAE) using DFT
I've tried a number of different approaches to try to speed up the prediction of a magnetic material's magnetocrystalline anisotropy energy. None of them worked, so we're left with first-principles DFT calculation. It uses ABACUS to implement the tight-binding force-theorem approach to MAE calculation. Expect run times to take anywhere from 15 minutes to 3 hours, depending on the number of atoms in your cell and the difficulty to converge.
This is going to be a paid API, and a pricy one at that. But as far as I know, this is the only API of it's kind. If you were doing magnetic material research, like we are over at #permanent-magnets, building something like this would take 100s of hours and expertise in HPC infrastructure, DFT software compilation, and deep understanding of first-principles physics and materials science. Hopefully this API can save you from some of those requirements.
Missing rare-earth element orbitals and potentials. When I find appropriate source files for these missing elements, I'll update. Your request will fail (at no cost) if the endpoint does not support your elemental system.
Initially, the API rejects requests with cells greater than 20 atoms. This is temporary and an arbitrary limit. It is primarily to prevent excessive runtimes, at least until I get the more performant methods of MAE calculation working.
I'm still testing the API and this approach. If you find something, let me know in the comments.
I would recommend against modifying any of the defaults. I've done a lot of testing to find a "good enough" set of parameters such that we get values we can trust, without breaking the bank and running calculations for many hours. See this API primarily as a screening tool.
If you absolutely do want to make some adjustments, here's a brief overview on what might happen.
method: Currently only the total energy difference approach is implemented. As more methods get added, this should decrease cost and wall-time significantly. Total energy difference approach requires SCF calculations with SOC + noncollinear spin for each magnetization direction, so it is the most expensive.
directions: Valid to change, you may want to test "110" or another off-axis magnetization direction. One of these being the easy or hard axis is rarer, which is why I've omitted them by default.
ecutwfc: Unlikely to make much of a differnce. Already at a happy medium between cheap and accurate enough. Took the value of 65 from NovoMag's work.
kspacing: This parameter has the greatest effect on runtime. Defines the k-point mesh. The default value of 0.16 is fairly balanced. It should still be high enough resolution to capture MAE within +/- 0.2 MJ/m^3. For screening, this is more than accurate enough. Be aware that if kmesh is too coarse, you may get erroneously large MAE values, even though they may seem reasonable.
scf_thr: Haven't seen a huge impact by this parameter. Default is on the low end for plane wave basis, but should be sufficient. Shrink (get closer to zero, like 1.0e-8) for more accurate results.
scf_nmax: Another parameter that has been tuned to protect against running too long. Default of 100 iterations should work for many materials, but not all. You would see a error thrown if convergence was not achieved within the limit. In this case, I recommend trying again with a larger value, like 200. This still may not be enough. In that case, prefer to decrease kspacing for a finer mesh.
smearing_sigma: Would not recommend changing this parameter for screening. You may want to decrease sigma for subtler SOC effects.
As mentioned before, expect runtime under default parameters to be on the order of 10 minutes to 3 hours. Ouro will send you a notification when the job is done so don't worry about keeping your machine open or waiting around.
I am still working on making sure the proper framework is in place such that API providers are compensated for compute and resources required by them, while also protecting the user from unwarranted charges like if there is an immediate failure preventing the use of the API endpoint. Related to that is more dynamic cost calculation. Ouro currently holds the position that total cost to run an endpoint should be know by the user before they decide to use it, but because compute time can be variable there isn't a great way to make sure both parties are completely satisfied. I'll be working on this very soon.
Now let's look at an example response and make sure we understand everything.
For each magnetization direction, we show total energy of the system in eV. It is from the difference between the largest and smallest of these that we derive MAE. Because the only differences between magnetization directions is the effect of spin-orbit coupling, we are able to compute MAE this way.
It is here we also see why MAE prediction is such a challenging property to predict. The total system is tens of thousands of electron volts, yet the energy differences (and MAE) is only a few meV. This is why such costly DFT runs are required.
mae_mj_per_m3 is usually the value most people look at, though we include other common ways of reporting MAE, like meV / atom (mae_mev_per_atom) and eV / cell (mae_ev).
You'll notice calculation_id is returned. This is a bookkeeping ID on my end. We store all raw calculations from the DFT run. If you'd like to access that data, reach out to me and this ID will be used to fetch the full data.
A new API is available to calculate magnetic anisotropy energy (MAE) using first-principles DFT with ABACUS. It’s designed for researchers who need accurate MAE values and are willing to run longer calculations. Expect 30 minutes to 2 hours per job, depending on system size and convergence. The service runs on an A100 GPU and is priced as a paid API.