Forced fixed time step with temperature simulations

[kahlos]

I get the following error when trying to run a temperature simulation (temp = ...) with any solver

Finite temperature requires fixed time step. Set FixDt != 0.

Reading the rk45 source, I see that the 437e026 commit tried to get adaptive time step to work with temperature simulations.

Is this error simply because the temperature.go hasn't been updated to reflect the changes? Can this be updated and an adaptive time step now be used?

[barnex]

This is not an error. The commit you are referring to was our best attempt to make this possible. Even though the solver was stable, the result was not necessarily physically correct due to subtle feedback between temperature and the time step. So it is still disallowed on purpose.

[kahlos]

Ah I see, thanks!

[deltaf]

BTW, mumax paper also mentions that you can't use rk45 with at temperature.

Therefore, only Mumax3’s Euler and Heun solvers (IV) can be used as they do not require torque continuity between steps.

Not sure if it is still the case, as it is not specified in the online docs (I think it should be mentioned explicitly though).

[kahlos]

As far as my own tests show, RK45 cannot be used with the temperature function. The simulation will still run, but it gives results significantly different to Heun, which qualitatively look incorrect.

mumax should throw an error or automatically switch to the Heun solver if the temp function is used.

[deltaf]

Should we file another bug report then?

I also noticed that mumax doesn't come with a nontrivial unit test for temperature.
The only test that turns on temperature (rk4temperature.mx3) interestingly uses 4th-order Runge-Kutta, not Heun or Euler.
It would be nice if they include the verification program mentioned in mumax paper (which reproduces Fig 8).

[deltaf]

Another thing is the documentation for that solver (which apparently isn't in the mumax paper --maybe you can try that solver?) isn't clear:

Classical 4th-order Runge-Kutta method. Intended for simulations where a fixed, relatively large time step is desired.

What is "relatively large"? Relative to what? Is it determined by exchange strength? Gilbert damping? Is 1e-12 "relatively large"? How about 1e-17?

[barnex]

If you just want results I strongly suggest to just use RK12 with a fixed time step. You can determine the time step, e.g., by first running at zero temperature with adaptive RK12 to get an idea of the maximum step.

The other solvers have been modified to work (presumably correctly) at finite temperature, but this is more intended for specialist tuning rather than general use.

If you believe rk45 is buggy with finite temperature, please confirm this by making arrhenius plots comparing an ensemble of simulations with rk45 to an ensemble of simulations with rk12, using the exact same time step. If those results are different, then yes you should file a separate bug for that.

[deltaf]

please confirm this by making arrhenius plots comparing an ensemble of simulations with rk45 to an ensemble of simulations with rk12

Well I certainly am not able do that, because there is no "arrhenius plot" in what I'm doing: there's a myriad temperature-dependent phenomena related to magnetism. While I can't go to specifics at the moment, I'm seeing significant differences with rk45.
And I don't know the specifics, but kahlos also confirmed above that there are significant differences with rk45 at finite temperatures.

That being said, do you mind if I asked for the mumax code that reproduces the arrhenius plot in mumax paper? For some reason, it isn't a part of standard unit tests.

using the exact same time step

Using the same time step with rk12 and rk45 results in a totally different error per step, so I'm guessing you're referring to the time step required by rk12 (which is several orders magnitude smaller for the same error/step).

presumably correctly

Do you have a set of in-house unit tests to confirm this? If yes, could you add them to the repo?

Either way, I'm hoping you can at least update the docs.