New feature: energy minimization (for hysteresis simulation)

448 views
Skip to first unread message

Ahmad Syukri bin Abdollah

unread,
Jun 20, 2015, 11:13:20 PM6/20/15
to mum...@googlegroups.com
Greeting mumax community!

I've recently implemented a steepest descent method for energy minimization, following Exl et al., JAP 115, 17D118 (2014) doi:10.1063/1.4862839 (also implemented in Abert's fork of MicroMagnum, magnum.fd, see Abert et al., JAP 116, 123908 (2014) doi:10.1063/1.4896360 for comparison with regular RK45F). This is suitable for simulations where fast dynamics are not considered e.g. hysteresis simulations.

It has recently been committed into the master branch of mumax/3 on github. I'd like to thank Arne for the code cleanup, and for the honor of being the first commit for the first "community" version of mumax3!

(Ack, I realized that I accidentally document it as conjugate gradient method! Correction pending…)

Implementation notes:
1. As with Relax(), simulation time is saved before Minimize(), and restored after it completes.
2. Also as with Relax(), thermal excitation is turned off.
3. While it is known to work with traditional LLG effective field (B_anis + B_demag + B_exch + B_ext), I've not determined whether it correctly works with STT (Slonczewski or Zhang-Li). I hope someone familiar with STT can help verify.
4. Convergence of solution is checked via magnitude of magnetization change, dm (magnum.fd uses dm/dt instead). Minimization stops when the maximum of last samples of dm (number determined by MinimizerSamples, defaults to 10) is smaller than a threshold, MinimizerStop, which defaults to 1e-6. From my experience, anything smaller will not converge (due to numerical floor limit).
5. Time step is calculated according to Barzilian-Borwein rule, but set to 1e-4 when division by zero occurs. Exl's paper mentions use of inexact line search when new computed energy is still larger than previous samples, but I didn't implement this.

While it is faster than solving regular LLG for most problems, it can still get stuck on certain stiff situations (I observed this especially when there are vortexes). Also, as Arne points out in the documentation (example page), it might fail on very high energy states like random magnetization.

Again, I'd like to thank Arne for the merge, and also congratulate him on his move to Google. I've always admired your golang-fu, and I hope you get to maximize its potential over there, where it was born!

Regards,
Ahmad Syukri bin Abdollah

Felipe Garcia

unread,
Jun 23, 2015, 9:47:55 AM6/23/15
to mum...@googlegroups.com
Thanks a lot, very nice job. It works very nice for depinning fields. As you mention it has problems with vortices but  I think this a general problem of nucleation not of your mehtod.

Regarding STT, I think it will not work because the STT is not defined by any energy. Example of this are STT oscillators. It will work I think for case where there is only field like torque contributions, but I don't think is a general situation.


Best regards,
Felipe Garcia

--
You received this message because you are subscribed to the Google Groups "mumax2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mumax2+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Michael Schmidt

unread,
Jul 17, 2016, 7:24:53 PM7/17/16
to mum...@googlegroups.com
Hello,

can the minimize() solver handle spacer layer set up by layers(). It
seems not and this is a limitation


setGridSize(4096, 512, 4)
setcellsize(48.828125e-9, 39.0625e-9, 10e-9)
border:= Cuboid(200e-6, 20e-6, 40e-9)
spacer:= layers(2,3)
multilayer:= border.sub(spacer)
setgeom(multilayer)

//mumax 3.9.1c windows_amd64 go1.3.3 (gc)
//CUDA 6050 GeForce GTX 980(4096MB) cc5.2, using CC35 PTX

Thanks for your time and advice


Am 21.06.2015 um 05:13 schrieb Ahmad Syukri bin Abdollah:
> Greeting mumax community!
>
> I've recently implemented a steepest descent method for energy
> minimization, following Exl et al., JAP 115, 17D118 (2014)
> doi:10.1063/1.4862839 <http://dx.doi.org/10.1063/1.4862839> (also
> implemented in Abert's fork of MicroMagnum, magnum.fd
> <http://micromagnetics.org/magnum.fd/>, see Abert et al., JAP 116,
> 123908 (2014) doi:10.1063/1.4896360
> <http://dx.doi.org/10.1063/1.4896360> for comparison with regular
> RK45F). This is suitable for simulations where fast dynamics are not
> considered e.g. hysteresis simulations.
>
> It has recently been committed into the master branch of mumax/3 on
> github. I'd like to thank Arne for the code cleanup, and for the honor
> of being the first commit for the first "community" version of mumax3!
>
> (Ack, I realized that I accidentally document it as conjugate gradient
> method! Correction pending…)
>
> Implementation notes:
> 1. As with Relax(), simulation time is saved before Minimize(), and
> restored after it completes.
> 2. Also as with Relax(), thermal excitation is turned off.
> 3. While it is known to work with traditional LLG effective field
> (B_anis + B_demag + B_exch + B_ext), I've not determined whether it
> correctly works with STT (Slonczewski or Zhang-Li). I hope someone
> familiar with STT can help verify.
> 4. Convergence of solution is checked via magnitude of magnetization
> change, dm (magnum.fd uses dm/dt instead). Minimization stops when the
> maximum of lastsamples of dm (number determined by MinimizerSamples,
> defaults to 10) is smaller than a threshold, MinimizerStop, which
> defaults to 1e-6. From my experience, anything smaller will not
> converge (due to numerical floor limit).
> 5. Time step is calculated according to Barzilian-Borwein rule, but
> set to 1e-4 when division by zero occurs. Exl's paper mentions use of
> inexact line search when new computed energy is still larger than
> previous samples, but I didn't implement this.
>
> While it is faster than solving regular LLG for most problems, it can
> still get stuck on certain stiff situations (I observed this
> especially when there are vortexes). Also, as Arne points out in the
> documentation (example page), it might fail on very high energy states
> like random magnetization.
>
> Again, I'd like to thank Arne for the merge, and also congratulate him
> on his move to Google. I've always admired your golang-fu, and I hope
> you get to maximize its potential over there, where it was born!
>
> Regards,
> Ahmad Syukri bin Abdollah
> --
> You received this message because you are subscribed to the Google
> Groups "mumax2" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mumax2+un...@googlegroups.com
> <mailto:mumax2+un...@googlegroups.com>.

Mykola Dvornik

unread,
Jul 18, 2016, 3:59:54 AM7/18/16
to mum...@googlegroups.com
Could you please be more specific about ' It seems not and this is a limitation'?

Michael Schmidt

unread,
Jul 18, 2016, 7:46:38 AM7/18/16
to mum...@googlegroups.com
Hello and sorry,

I saw now I mixed something up, seems minimize also works with spacer,
but I had some relax() scripts for hysteresis, where by simply replacing
relax with minimize simulatino did not work in that way that simulation
is starting but not really outputting any data (PNG or ovf) and I get an
empty folder with only

duration
exitstatus
log
alive
start
host
stdout

files

log being empty

I will look further into the scripts what might cause this. Sorry again.

Best regards





Am 18/07/2016 09:59, schrieb Mykola Dvornik:
> Could you please be more specific about ' It seems not and this is a
> limitation'?
>
> -----Original Message-----
> *From*: 'Michael Schmidt' via mumax2 <mum...@googlegroups.com
> <mailto:%27Michael%20Schmidt%27%20via%20mumax2%20%3cmu...@googlegroups.com%3e>>
> Reply-to: mum...@googlegroups.com
> *To*: mum...@googlegroups.com <mailto:mum...@googlegroups.com>
> *Subject*: Re: [mumax2] New feature: energy minimization (for
> hysteresis simulation)
> *Date*: Mon, 18 Jul 2016 01:25:00 +0200

etre...@berkeley.edu

unread,
Jul 21, 2017, 4:15:05 PM7/21/17
to mumax2
Hello, I was wondering if you have any tips for implementing hysteresis including STT, or non-field-like contributions?

Thank you!

Felipe Garcia

unread,
Jul 21, 2017, 4:48:05 PM7/21/17
to mumax2
Hello, I think that  unless you can find an energy term associated (and standard STT has not one) the only thing you can do it is to do loops with the current and integrate it for a given amount of time the LLG equation for each current value. Maybe you can establish a threshold of change over the last nano second or something like that but not much more.

Regards,
Felipe

On Fri, Jul 21, 2017 at 10:15 PM, <etre...@berkeley.edu> wrote:
Hello, I was wondering if you have any tips for implementing hysteresis including STT, or non-field-like contributions?

Thank you!

--
You received this message because you are subscribed to the Google Groups "mumax2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mumax2+unsubscribe@googlegroups.com.

etre...@berkeley.edu

unread,
Jul 28, 2017, 4:05:22 PM7/28/17
to mumax2
Thanks for the reply!
I was looking at the implementation of relax. It looks like at first it finds the energy minimum and then minimzes the torque, however, rk23 updates the torque at each step (therefore includes STT). So could relax() be used to make hysteresis loops with STT? I know it is slow though.


On Friday, July 21, 2017 at 1:48:05 PM UTC-7, pkwgarcias wrote:
Hello, I think that  unless you can find an energy term associated (and standard STT has not one) the only thing you can do it is to do loops with the current and integrate it for a given amount of time the LLG equation for each current value. Maybe you can establish a threshold of change over the last nano second or something like that but not much more.

Regards,
Felipe
On Fri, Jul 21, 2017 at 10:15 PM, <etre...@berkeley.edu> wrote:
Hello, I was wondering if you have any tips for implementing hysteresis including STT, or non-field-like contributions?

Thank you!

--
You received this message because you are subscribed to the Google Groups "mumax2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mumax2+un...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages