Add relative error check in adaptive time stepping algorithm for rk23…

[xfong]

…, rk45dp and rk56 time steppers

[godsic]

@xfong

First of all, that you very much for the effort and for sharing this one with us.

Could you please

• elaborate a bit on motivation for using relative error control;
• provide some example .mx3 scripts where it helps overcome absolute error control limitations;
• comment on what to expect performance- and precision-wise.

[xfong]

* The adaptive time steeping control will benefit in cases where absolute errors of 1e-5 are much smaller than relTol * value of interest. This can help the transient simulation use larger time steps and hasten the completion of simulations. * The fixes are directly compatible with the existing .mx3 files with no modifications needed. The limitations on my side are that I do not have the tools to perform the benchmarking that you want and I suggest you can check the differences in runtimes on your set up. Also, it is more likely that the changes will benefit simulations that typically run for a long time. * At least 5% faster transient simulations are expected for simulations that typically take 30 minutes or longer to complete Best, Xuanyao (Kelvin) FONG Assistant Professor Department of Electrical & Computer Engineering, Faculty of Engineering National University of Singapore 4 Engineering Drive 3 Singapore 117583 Office E4-05-23 Phone: +65-6516-6658 Fax: +65-6779-1103 Email: [email protected] From: Mykola Dvornik <[email protected]> Sent: Wednesday, November 18, 2020 4:17 PM To: mumax/3 <[email protected]> Cc: xfong <[email protected]>; Mention <[email protected]> Subject: Re: [mumax/3] Add relative error check in adaptive time stepping algorithm for rk23… (#275) @xfong <https://github.com/xfong> First of all, that you very much for the effort and for sharing this one with us. Could you please * elaborate a bit on motivation for using relative error control; * provide some example .mx3 scripts where it helps overcome absolute error control limitations; * comment on what to expect performance- and precision-wise. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#275 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRJYBLAY6QZBUSXPSDH5KLSQN7ITANCNFSM4TZTMT2Q> . <https://github.com/notifications/beacon/ABRJYBK5RPQ75RKOULPLMZTSQN7ITA5CNFSM4TZTMT22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFN5YICI.gif>

[godsic]

@xfong

• please be prepared for a long review process as this pull request touches very sensitive part of mumax3;
• please restructure your code in a way, that using RelErr = 0 exactly follows the current code, while RelErr > 0 triggers your modifications.

[xfong]

I need to update the code in the branch to meet your requirements. Best, Xuanyao (Kelvin) FONG Assistant Professor Department of Electrical & Computer Engineering, Faculty of Engineering National University of Singapore 4 Engineering Drive 3 Singapore 117583 Office E4-05-23 Phone: +65-6516-6658 Fax: +65-6779-1103 Email: [email protected] From: Mykola Dvornik <[email protected]> Sent: Wednesday, November 18, 2020 6:26 PM To: mumax/3 <[email protected]> Cc: xfong <[email protected]>; Mention <[email protected]> Subject: Re: [mumax/3] Add relative error check in adaptive time stepping algorithm for rk23… (#275) @xfong <https://github.com/xfong> * please be prepared for a long review process as this pull request touches very sensitive part of mumax3; * please restructure your code in a way, that using RelErr = 0 exactly follows the current code, while RelErr > 0 triggers your modifications. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#275 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRJYBPOI32GU5HSNCNSHNLSQOOJ5ANCNFSM4TZTMT2Q> . <https://github.com/notifications/beacon/ABRJYBNKQYRHSXPXMVBZ7IDSQOOJ5A5CNFSM4TZTMT22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFN6JE3A.gif>

[JonathanMaes]

It seems that the value used in setMaxTorque() is inconsistent between different solvers. [NOTE: this was already the case before this PR]

• Here in RK56 (also RK45dp and RK23), setMaxTorque() is set with the torques acting on the final magnetization state (i.e. the torqueFn() values after the final cuda.Madd<n>(m, m0, ...) is performed).
• However, in e.g. RK4 (also Heun and Euler I think?), setMaxTorque() is set with the torque acting on the magnetization considered in the last stage of the RK solver (i.e. the torqueFn() values before the final cuda.Madd<n>(m, m0, ...) is performed).

Which of these two possibilities do we consider most correct?

EDIT: the reason for not calculating the final torque in RK4 etc. is that this would significantly decrease performance for simulations at nonzero temperature because then this final torque can not be re-used. Therefore, it seems that the final torque evaluation of k2 in the original RK56 code could be omitted similar to how it was done in the RK4 solver.

[JonathanMaes]

There is no need to re-calculate this (at zero temperature, at least) if k2 is stored at the end of the Step anyway.

[JonathanMaes]

Hi, thanks for your contribution!

@xfong Could you elaborate a bit on how your code works?

You claim that it can provide a >5% performance increase, but as far as I understand your code, an extra if statement (checking the relative error) was added in the part of the original if statements where the step was accepted. If that check fails, the solver undoes the step anyway. Hence, it seems to me that your extra if statements provide an extra pathway to undo the step, so I fail to see how this can increase performance. Am I missing something here?

Would using a total tolerance (something like tol = AbsTol + RelTol*torque) be an option, which combines the absolute and relative tolerances into a single check?

[xfong]

The AbsTol imposes a very strict check especially in steps with large changes in magnetization. The relative tolerance check allows the step to be accepted as long as the error is small relative to the change in magnetization. It is this that enables larger steps to be accepted by the steppers, which then leads to the roughly 5% faster runtimes across all the transient simulations found in the ./test directory.

Hi, thanks for your contribution!

@xfong Could you elaborate a bit on how your code works?

You claim that it can provide a >5% performance increase, but as far as I understand your code, an extra if statement (checking the relative error) was added in the part of the original if statements where the step was accepted. If that check fails, the solver undoes the step anyway. Hence, it seems to me that your extra if statements provide an extra pathway to undo the step, so I fail to see how this can increase performance. Am I missing something here?

Would using a total tolerance (something like tol = AbsTol + RelTol*torque) be an option, which combines the absolute and relative tolerances into a single check?