Question about 3D simulations with Slonczewski torque and one spacer layer

[Joan Manel Hernàndez Ferràs]

I was using mumax to do some calculations on a 3D structure with fixed layer, one spacer and the free layer.
I have some questions related to way to define the spacer layer. I was trying several ways and I've got different results.

 I include at the end of the message a simplified version of the code to manifest these discrepancies that appear even in the case of a single 2D layer simulation calculated in 3D.

This example simulates one layer Py film(3nm thick) with an applied current on a circular contact at the centre with an external magnetic field (with some "unphysical" spatial dependence).

I suggest to run this simulation in three situations defined by setting different values to the parameters Lz  and full_universe (defined at the beginning of the code): 

 
A) Lz=1 and full_universe= true: This corresponds to a true 2D calculation, 1 single layer. In this case the result is some spin dynamics with vortices pairs that annihilate emitting SW.

B) Lz=2 and full_universe= true: This corresponds to a true 3D calculation, defining the geometry as the full simulation area and setting the Msat and Aex of the second layer to 0. This in my opinion should be equivalent to the previous case.
This case results in some spin dynamics too, with vortices pairs that annihilate emitting SW but the spatial distribution of vortices looks more random.

C) Lz=2 and full_universe= false:  This corresponds to a 2D simulation but setting the geometry to consider only layer(0).
This should be also equivalent to A) but the results are quite different. The effect of the current in this case seems to be less effective. Only a small excitation appears.

( another case still remains Lz=1 and full_universe= false but is absolutely equivalent to case A).

I don't know what is the correct way to define the spacer layer. I am getting, in the "production simulation" very different results depending on how I define it.


********************CODE*****************************
Lz:=2
full_universe:=true

LL:=256
SetGridSize(LL, LL, Lz)
SetCellSize(3e-9, 3e-9, 3e-9)
SetPBC(1,1,0)
R := 15e-9
A_circ := 3.1415926535*R*R

if !full_universe {setGeom(layer(0))}
if full_universe {setGeom(universe())}
curr := -5e-3 
trun:=0.5e-8 
Aex = 13e-12 
Msat = 800e3 
alpha = 0.02 
lambda  = 1. 
epsilonprime = 0. 
temp=0. 
B_ext = vector( 0.1,  0, 0) 

m = Uniform(1,0,0) 

DefRegion(1, layer(0).intersect(ellipse(2*R,2*R)))
DefRegion(2, layer(1)) 

Msat.setregion(2,0.)
Aex.setregion(2,0.)

B_ext.setregion(1, vector(.05 ,.05,0.)  )
fixedlayer.SetRegion(1, vector(1., 0.,0.))
j.SetRegion(1,vector(0,0,Curr/A_circ ))
pol.setregion(1,.8)

print("Evolving...")
tableautosave(2e-12)
run(trun)

[Arne Vansteenkiste]

Hi Joan,

in your case, the 2D and 3D simulations are *very* different cases. In 3D, you also get Zhang-Li STT in the z direction because of the current along Z.  You can disable Zhang-Li if you think this is physical.  Case C) is a  bit more puzzling. Please double-check your assumptions using the web interface: does the geometry look like you expect, are Slonczewski, Zhang-Li torques zero where you expect them to be zero, etc.?

-Arne;

--
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.

[Joan Manel Hernàndez Ferràs]

Hi Arne

Thanks for your rapid response.

I understand that cases A and B can be slightly different due to Zhag Li ST term. But the biggest differences are with case C.

Another point :

I got error messages when using the sentences 

DisableSlonczewskiTorque=true

and 

DisableZhangTorque=true

: undefined: DisableSlonczewskiTorqueque=true

(the error message always repeat the 3 last caharacters of any undefined variable)

And using "DisableSlonczewskiTorque:=True" has no effect

I am using the windows version of mumax3.6.1

El dijous, 15 gener de 2015 10:20:59 UTC+1, Arne Vansteenkiste va escriure:

[Arne Vansteenkiste]

I'm afraid I cannot reproduce your problem on linux with mumax3.6.1. So either the windows version was mispackaged or there is some other windows-specific bug. 

Are you able to recompile on windows or try your file on linux? I can't build for windows right now.

To unsubscribe from this group and stop receiving emails from it, send an email to mumax2+unsubscribe@googlegroups.com.

[Joan Manel Hernàndez Ferràs]

I'm sorry ,

It was my fault, I associated mx3 files with old mumax 3.5 version in which these parameters were not defined .

I'll try to compare the A and B cases with ZL term disabled

The point was that option C (defining the geometry as only the magnetic materials) was much faster but gives very different results.

 

El dijous, 15 gener de 2015 11:25:43 UTC+1, Arne Vansteenkiste va escriure:

I'm afraid I cannot reproduce your problem on linux with mumax3.6.1. So either the windows version was mispackaged or there is some other windows-specific bug. 

Are you able to recompile on windows or try your file on linux? I can't build for windows right now.

[Joan Manel Hernàndez Ferràs]

Hi Arne

Finally I think I can summarize the results 

I am simulating one single magnetic layer but considering a simulation box of several layers. 

With Zhang-Li Term disabled, it is equivalent to simulate empty layers as (a)  Msat=0 and Aex =0 or (b) being excluded of the simulation setting the geometry (setgeometry() command) to the magnetic material region.

I finally choose to perform all tests by defining the "setgeometry() the magnetic material (setgeometry(layer(0)))

IN ORDER TO OBTAIN THE SAME MAGNETIC EVOLUTION I MUST MULTIPLY THE CURRENT DENSITY BY THE NUMBER OF LAYERS OF THE SIMULATION (despite that the magnetic material is only one layer)

Considering that the current is parallel to the z axis (perpendicular to the layer) the current density should be independent of the number of layers, isn't it?

[Joan Manel Hernàndez Ferràs]

Hi again Arne

I was looking at your code  

In the file slonczewski.go  it is defined thickness := float32(mesh.WorldSize()[Z])

This parameter is the total thickness of the simulation area including non magnetic layers, and this is used as the free layer thickness in the computation of the torque in slonczewski.cu (flt variable).

This is true only if the free layer extends over all the simulation thickness. But in the case of stacking several layers (magnetic and no magnetic or free and fixed layers)  the "flt" parameter used  in slonczewski.cu  must be only the thickness of the free layer

I understand that there is no easy solution to this problem. Would it be possible to introduce an external parameter to fix this quantity in the slonczewski torque  computation.  

Thanks and regards,

  

[Arne Vansteenkiste]

I see, that might be the cause indeed. But just setting the thickness won't fix everything. Slonczewski works on all layers I believe, so if you want to have it only in one layer you are still in bad luck. 

Perhaps Mykola might comment?

[Mykola Dvornik]

If you want to be consistent with OOMMF then it has to be thickness of the free layer. I believe in OOMMF the default value is the thickness of the whole structure. So it won't hurt if this could be settable, i.e. like in OOMMF.

Theory-wise I would not expect fixed layer to contribute to the value, since it is where spin-polarized current is coming from. However I don't see any reasons why other layers should not be accounted for.

-Mykola

[Arne Vansteenkiste]

I think the way Slonczewski is implemented, you should never include the fixed layer and spacer in your simulations anyway.   

[Mykola Dvornik]

There might be some dipolar coupling between fixed and free layers. So people like to have that one accounted for.

Making it settable with the default value of worldsize.Z should be transparent. If it is OK with you then I can do it?

-Mykola

[Arne Vansteenkiste]

In my opinion, you should pre-calculate the stray field of the polarizer and apply it as an external field.  

If the polarizer layer is explicitly included in the simulation, then people will expect it to be, well, the polarizer layer and may not set FixedLayer = ....

Making the free layer thickness settable may encourage this kind of misuse. In the end it's just a matter of convention but I'd rather have it strict than open up the freedom to do even more wrong simulations without realizing so.

On Fri Jan 16 2015 at 3:31:03 PM Mykola Dvornik <mykola....@gmail.com> wrote:

There might be some dipolar coupling between fixed and free layers. So people like to have that one accounted for.

Making it settable with the default value of worldsize.Z should be transparent. If it is OK with you then I can do it?

-Mykola

On Fri, Jan 16, 2015 at 3:22 PM, Arne Vansteenkiste <a.vanst...@gmail.com> wrote:

I think the way Slonczewski is implemented, you should never include the fixed layer and spacer in your simulations anyway.   

On Fri Jan 16 2015 at 10:05:09 AM Mykola Dvornik <mykola....@gmail.com> wrote:

If you want to be consistent with OOMMF then it has to be thickness of the free layer. I believe in OOMMF the default value is the thickness of the whole structure. So it won't hurt if this could be settable, i.e. like in OOMMF.

Theory-wise I would not expect fixed layer to contribute to the value, since it is where spin-polarized current is coming from. However I don't see any reasons why other layers should not be accounted for.

-Mykola

On Fri, Jan 16, 2015 at 9:26 AM, Arne Vansteenkiste <a.vanst...@gmail.com> wrote:

I see, that might be the cause indeed. But just setting the thickness won't fix everything. Slonczewski works on all layers I believe, so if you want to have it only in one layer you are still in bad luck. 

Perhaps Mykola might comment?

On Thu Jan 15 2015 at 5:22:27 PM Joan Manel Hernàndez Ferràs <joan.manel.hernandez@gmail.com> wrote:

Hi again Arne

I was looking at your code  

In the file slonczewski.go  it is defined thickness := float32(mesh.WorldSize()[Z])

This parameter is the total thickness of the simulation area including non magnetic layers, and this is used as the free layer thickness in the computation of the torque in slonczewski.cu (flt variable).

This is true only if the free layer extends over all the simulation thickness. But in the case of stacking several layers (magnetic and no magnetic or free and fixed layers)  the "flt" parameter used  in slonczewski.cu  must be only the thickness of the free layer

I understand that there is no easy solution to this problem. Would it be possible to introduce an external parameter to fix this quantity in the slonczewski torque  computation.  

Thanks and regards,

  

--
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.

For more options, visit https://groups.google.com/d/optout.

--
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.

For more options, visit https://groups.google.com/d/optout.

--
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.

For more options, visit https://groups.google.com/d/optout.

--
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.

For more options, visit https://groups.google.com/d/optout.

--
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.

[Mykola Dvornik]

Fair enough. In my opinion, it won't hurt if  this could be explicitly stated in the API documentation. At the end of the day people might just tune J accordingly.

-Mykola

---

From: Arne Vansteenkiste
Sent: ‎16/‎01/‎2015 15:42
To: mum...@googlegroups.com
Subject: Re: [mumax2] Question about 3D simulations with Slonczewski torqueand one spacer layer

To unsubscribe from this group and stop receiving emails from it, send an email to mumax2+un...@googlegroups.com.

[Kelvin Fong]

Not sure if I understood the problem completely but for full 3D, is the Pol value shared between Slonczewski torque and Zhang-Li in the API? I made a separate hack that allowed me to define a separate Slonczewki torque with Pol and J that is totally different from Zhang-Li for the purpose of simulating domain wall structures that have spin Hall effect in the underlayer. Maybe that might help in this case. From a numerical point of view, Pol can be scaled to account for the difference between cell thickness and actual structure thickness.

Then, combined with the FixedSpins that Mykola already implemented, a separate polarization layer may be defined to simulate the effect of a reference layer.

Kelvin

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.

--
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.

--
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.

--
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.

--
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.

[Arne Vansteenkiste]

@Kelvin: that's a pretty nice solution. I think I'll provide the 2 separate polarizations and then remove EnableZhangLiTorque and EnableSlonczewskiTorque. The only caveat being that one should not forget to set fixedlayer.

[Mykola Dvornik]

Will you retain the default behavior?

-Mykola

---

From: Arne Vansteenkiste
Sent: ‎19/‎01/‎2015 09:05

To: mum...@googlegroups.com
Subject: Re: [mumax2] Question about 3D simulations with Slonczewski torqueand one spacer layer

[The entire original message is not included.]

[Arne Vansteenkiste]

How about replacing 'Pol' by, e.g.,  'PolZL' and 'PolSlon'. It is a backwards incompatible change which I don't like to make. But scripts with 'Pol' will break so they won't give unexpected results.  DisableZhangLiTorque and DisableSlonczewskiTorque become obsolete as they correspond to PolZL=0 and PolSlon=0, which I would set as defaults.  Can anyone think of a cleaner solution?

[Mykola Dvornik]

I am not really sure if it is reasonable, since spin-polarized current is external to the system and therefore should not distinguish between Slon and ZL. In my opinion this should be default behavior, i.e. PolZL = PolSlon. Perhaps one can keep Pol variable that once set propagates to both PolZl and PolSlon. Otherwise PolZL and PolSlon could be set independently.  

-Mykola

[Joan Manel Hernàndez Ferràs]

Sorry, message follows...

I want to comment that there is another unsolved question: how to introduce a time dependent (not so-)fixed layer (perhaps is better to call it polarizer) which evolution is calculated by mumax, that induces a time dependent ST on the free layer. 

This would imply to set the fixedlayer() field in the free layer to be (proportional to )  the magnetization of the polarizer. This is a really non-local interaction,  

I don't know if this possibility has any meaning or interest for you. 

 Joan Manel

[Arne Vansteenkiste]

This would mean a complete re-design of the Slonczewski interaction in mumax. I myself do not plan to make this change in the near future. Sorry for that.

--

[Mykola Dvornik]

In theory this could be prototyped in go:

1. Fix time step.

2. Do step

3. Calculate mp as norm(M) in fixed layer.

4. Repeat

If works this could be added as an extensions. 

  

-Mykola

[Arne Vansteenkiste]

With the caveat that FixedLayer (mp) is a Region-wise defined quantity ;-)

[Mykola Dvornik]

for prototyping one could do pbc, get quasi-uniform precession and go with a single region.

-Mykola

[Arne Vansteenkiste]

Yes.

[Mykola Dvornik]

So Joan are willing to do this prototyping?

-Mykola

[Joan Manel Hernàndez Ferràs]

Hi Mykola,

It would be great to collaborate  with your project and make it even more useful.

But I think that first of all I should learn Go, Cuda... and finally how mumax internally works.

fixedlayer is region specific but in this case it needs to be specified cell by cell It's a modification that it out of my possibilities...

In the most general case It would be necessary to define a kernel to specify the contribution of the magnetization of each cell to the polarization of the current at any other cell: fixedlayer(i) =K(i,j) * m(j)  

where K(i,j) is different from zero only if i belongs to the free layer and j belongs to the polarizer. 

El dilluns, 19 gener de 2015 12:19:18 UTC+1, godsic va escriure:

[Arne Vansteenkiste]

Perhaps we should take this discussion off the mailing list and work via a github issue?

[Mykola Dvornik]

So Joan could you please open feature request ticket by following https://github.com/mumax/3/issues ?

-Mykola

[Joan Manel Hernàndez Ferràs]

Done?

You received this message because you are subscribed to a topic in the Google Groups "mumax2" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mumax2/-JhEUOMH7sY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mumax2+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

---

Aquest correu electrònic s'ha verificat mitjançant l'Avast antivirus. www.avast.com

[Kelvin Fong]

My thoughts and experiences.

I think it depends on the structure being investigated. My projects explore hypothetical structures and in many cases, we need to simulate currents moving in separate directions across separate interfaces. This can cause the spin polarization to be different. For example, in the three terminal structure originally proposed by Fukami for fast STT-MRAM, the write current path moves in the domain wall stripe while the read current path tunnels across the oxide. It seems theoretically correct to assume that if the current flows at the same time, the polarization factors can be different.

Another example is the case of nano-magnets grown on heavy metals (MgO/Co/Pt and MgO/CoFeB/Ta experiments). The spin current due to spin Hall effect can be modeled using PolSlon. But there may possibly be current flow in the magnetic layer, which I think should be modeled using Zhang-Li torque. Here, PolSlon should be different from PolZl too.

Going forward, it will actually be nice if the API allows the user to specify individual modules, and possibly multiple copies of the same module but each copy having different parameters. This is actually how its done in OOMMF. The down side is that if the user doesn't know what he is doing, things get broken really quickly. In the end, it is a tradeoff regarding how much control you want the user to have. The way I see it, you give the most flexibility if the user have most control. But users may be knocking at your door 24/7 to ask for help debugging code.

Maybe it will be nice to redo the discussion forums to have users post their problems and other users reply with their solutions like in the uMag mailing list in NIST? Alternatively, make the test files more visible to the users or give more examples in the manual? I know that you have a lot of test cases already listed in the manual and it doesn't make sense to add to it since most are project-dependent.

Kelvin