The Xf_ThermHeunEvolve OOMMF extension is a combination of the Oxs_RungeKuttaEvolve evolver that comes default with OOMMF, and the thermal fluctuation model that is in the UHH_ThetaEvolve evolver. The Xf_ThermHeunEvolve extension was created to allow the simulation of thermal fluctuation effects on a magnetic ensemble using Heun’s method, which was shown to be more stable in [1].

The thermal fluctuations may be modeled as an effective field derived by Brown [2]:

\textbf{H}_{Thermal} = \xi\sqrt{\frac{2\alpha k_{B} T}{\left(1+\alpha^2\right)|\gamma|\mu_{0}M_{sat}Vol\Delta t}}

According to the OOMMF user guide:

\gamma=\text{Gilbert gyromagnetic ratio}
\alpha=\text{Gilbert damping factor}
\mu_{0}=\text{permeability of free space}
M_{sat}=\text{saturation magnetization}
k_{B}=\text{Boltzmann constant}
Vol=\text{Volume of magnetic domain/particle}
Delta t=\text{time step of simulation}

gamma has a default value of -2.211times{}10^{5}\text{m/A}\cdot\text{s}. M_{sat} is the saturation magnetization in \text{A/m}, and \mu_{0} is the permeability of free space with a value of 4\pi\times10^{-7}.

The Specify block for the Xf_ThermHeunEvolve class has the form

\text{Specify Xf\_ThermHeunEvolve:}\textit{name}~\{
            \textit{region1 region2 }\cdots


Most of these options appear also in the Oxs_EulerEvolve class. The repeats have the same meaning as in that class, and the same default values except for relative_step_error and error_rate, which for Xf_ThermHeunEvolve have the default values of 0.01 and -1.0, respectively. Additionally, the alpha, gamma_LL and gamma_G options may be initialized using scalar field objects, to allow these material parameters to vary spatially.

Simulations with thermal fluctuations are enabled using the parameters temperature and tempscript. The parameter temperature sets the temperature of thermal fluctuations in units of Kelvin. Heating effects may be simulated using the tempscript, which behaves similarly to Jprofile from Oxs_SpinXferEvolve. The Tcl procedure defined by tempscript should return a scalar and is used to give a time varying profile to temperature. Only spatially uniform temperature is allowed in the simulation, and temperature should be given as a scalar constant. The inputs given to the Tcl procedure defined in tempscript may be from the list of arguments specified in tempscript_args. The list must be from the following: stage, stage_time, total_time.

The parameter uniform_seed sets up the random number generator used to generate the thermal fluctuation field for thermal simulations. (Developmental note: thermal simulations seem to have random errors if this is not set during simulations with non-zero temperature.)

The allow_signed_gamma parameter is for simulation testing purposes, and is intended for advanced use only. There is some lack of consistency in the literature with respect to the sign of \gamma. For this reason the Landau-Lifshitz-Gilbert equations are presented above using the absolute value of \gamma. This is the interpretation used if allow_signed_gamma is 0 (the default). If instead allow_signed_gamma is set to 1, then the Landau-Lifshitz-Gilbert equations are interpreted without the absolute values and with a sign change on the \gamma terms, i.e., the default value for \gamma in this case is -2.211\times 10^{5} (units are \text{m/A}\cdot\text{s}). In this setting, if \gamma is set positive then the spins will precess backwards about the effective field, and the damping term will force the spins away from the effective field and increase the total energy. If you are experimenting with \gamma > 0 , you should either set \alpha \leq 0 to force spins back towards the effective field, or disable the energy precision control (discussed below).

The two controls min_step_headroom (default value 0.33) and max_step_headroom (default value 0.95) replace the single step_headroom option in Oxs_EulerEvolve. The effective step_headroom is automatically adjusted by the evolver between the min_headroom and max_headroom limits to make the observed reject proportion approach the reject_goal (default value 0.05).

The method entry selects a particular Runge-Kutta implementation. It should be set to one of rk2, rk2heun, rk4, rkf54, rkf54m, or rkf54s; the default value is rkf54. The rk2 and rk4 methods implement canonical second and fourth global order Runge-Kutta methods [1], respectively. For rk2, stepsize control is managed by comparing \dot{{\textbf{m}}} at the middle and final points of the interval, similar to what is done for stepsize control for the Oxs_EulerEvolve class. One step of the rk2 method involves 2 evaluations of \dot{{\textbf{m}}}. The rk2heun method implements Heun’s method and is essentially a modified version of the forward Euler method. Heun’s method calculates \dot{{\textbf{m}}} at the initial and the predict step, and uses the average of the two as the actual \dot{{\textbf{m}}} for calculating the next step.

In the rk4 method, two successive steps are taken at half the nominal step size, and the difference between that end point and that obtained with one full size step are compared. The error is estimated at 1/15th the maximum difference between these two states. One step of the rk4 method involves 11 evaluations of \dot{{\textbf{m}}}, but the end result is that of the 2 half-sized steps.

The remaining methods, rkf54, rkf54m, and rkf54s, are closely related Runge-Kutta-Fehlberg methods derived by Dormand and Prince [2, 3]. In the nomenclature of these papers, rkf54 implements RK5(4)7FC, rkf54m implements RK5(4)7FM, and rkf54s implements RK5(4)7FS. All are 5th global order with an embedded 4th order method for stepsize control. Each step of these methods requires 6 evaluations of \dot{{\textbf{m}}} if the step is accepted, 7 if rejected. The difference between the methods involves tradeoffs between stability and error minimization. The RK5(4)7FS method has the best stability, RK5(4)7FM the smallest error, and RK5(4)7FC represents a compromise between the two. The default method used by Oxs_RungeKuttaEvolve is RK5(4)7FC.

The remaining undiscussed entry in the Xf_ThermSpinXferEvolve Specify block is energy_precision. This should be set to an estimate of the expected relative accuracy of the energy calculation. After accounting for any change in the total energy arising from time-varying applied fields, the energy remainder should decrease from one step of the LLG ODE to the next. Xf_ThermSpinXferEvolve will reject a step if the energy remainder is found to increase by more than that allowed by eprecision. The default value for eprecision is 1e-10. This control may be disabled by setting eprecision to -1.

The Xf_ThermHeunEvolve module provides the same five scalar outputs and three vector outputs as Oxs_RungeKuttaEvolve, plus the scalar output “Temperature.”

[1] W. Scholz et al., “Micromagnetic simulation of thermally activated switching in fine particles,” Thesis, 1999
[2] W. F. Brown, “Thermal fluctuations of a single-domain particle,” Physical Review vol. 130, no. 5, pp. 1677-1686, Jun. 1963.

3 comments on “Xf_ThermHeunEvolve
  1. Kevin says:

    Is it OK to realize the thermal fluctuation field by an energy class, not evolver.


    • xfong says:

      Yes and no. The issue is that all evolvers pick up energy classes. However, it does not make sense for the CGEvolve evolver to pick up energy classes such as Xf_STT or thermal fluctuation. CGEvolve is optimized for finding energy minimum near a initial point. A thermal fluctuation field will constantly change the minimum and hence, CGEvolve will not be guaranteed to reach convergence. On the other hand, the time-based evolvers such as Oxs_SpinXferEvolve are not looking for the energy minimum. So it is fine for things like thermal fluctuation and spin-transfer torque to be captured as an energy class. However, the energy calculated by the time evolver is not guaranteed to be correct in this case.


      • Kevin says:

        Thank you. I saw you implement the thermal fluctuation within RungeKutta Time evolver. Is it equivalent to do it in an energy class? What I wanna do is similar to thermal fluctuation, but I don’t wanna modify the evolver class. It’s kind of difficult.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Recent Posts
Recent Comments
%d bloggers like this: