Setting OVF as a custom field term

[Harrison Jin]

Hello,

I want to create a custom SOT field in order to simulate both STT and SOT effects in a PMA racetrack. Would it be possible to upload an OVF containing the XYZ components of the custom SOT field using AddFieldTerm()? 

I have tried this with some existing OVF files already and it seems that the method of loading the contents of the OVF using a NewVectorMask results in incompatible data type for AddFieldTerm(). Is there any way to implement this?

Thank you,

Harrison Jin

[Josh Lauzier]

Hi,

If you just want STT and SOT, I think the easiest would be to just set J normally, use the built in STT, and use custom fields SOT referencing J, instead of trying to import the SOT field itself. That way, there is no need to try to load a field file (you can load J itself from an OVF if necessary for some reason). Is there a reason you're trying to load an SOT field? You should be able to base both STT and SOT off of J and avoid this issue entirely. Because J is already a Quantity (and also, it has a method so you can promote an OVF/slice to J).

For instance, in the mumax tutorial session 4 starting on slide 45, the custom field example showing SOT technically has both STT and SOT. The STT term isn't explicitly turned off, so you can just set the normal STT parameters to extend that example.

If that isn't an option for some reason, there is not currently a way to upload an arbitrary OVF into a field. The issue is you need to make it into a Quantity (and as you noted, NewVectorMask only gives you a slice), and in base mumax there is no way to promote a slice up to a Quantity. There's basically two ways around this: One is to reuse some existing Quantity (usually J, but this means you won't be able to use J for other things. Unfortunately there are not many arbitrary Quantities to repurpose). Or two, there are two forks that have features for arbitrary Quantities. There are two forks that have this feature (I mentioned here), but you would need to be able to copy one those features and recompile mumax yourself. One of those forks has a simple function to promote an arbitrary slice to a Quantity, which should do what you want. I haven't yet tested it myself yet, though. But in theory, you should be able to just copy/paste that ~20 lines of code, and recompile.

Best,
Josh L.

[Harrison Jin]

Thank you for the response and clarification. 

Session 4 of the workshop was indeed the original solution I used for this issue when I was still using a uniform current density. However, I am now using a current density mask that models non-uniform current density distribution in each cell due to a racetrack with changing width. To do so I am loading in the custom current density distribution as an OVF using the NewVectorMask() method as well. My thought was that perhaps I could also try to calculate the effective SOT field at each grid cell based off of the values already in the custom current density mask, instead of maybe having to generalize the effective field as one singular value for the entire racetrack. I would assume from your last response that it would also not be possible to create a distribution of SOT field by operating on the XY components of current density that I set using the following process:

myData := loadfile("p4_5v.ovf") // p4_5v.ovf is a flattened ovf containing the XY components of current density for a Nx by Ny grid
mask_4 := newVectorMask(Nx, Ny, 1)
mask_4 = myData

J.add(mask_4, 1) // to apply mask to J

Would this be a correct assumption? If so, I understand and will start looking into the listed alternatives.

Respectfully,

Harrison Jin

--
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/ANK1q5qQ8N0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mumax2+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mumax2/cdb9e192-9c7c-42fd-ae20-c821664eda82n%40googlegroups.com.

[Josh Lauzier]

Hi,

If you have a non-uniform J, then you will indeed need to make some tweaks, but there is an easier way. In that example, they used

p := Constvector(0,-1,0)

However, recall back on slide 41, that p = sign(alphaH) j cross n. So instead you can do something like

J=vector(-2e11,0,0)

nhat:= Constvector (0,0,-1)
p:= Cross(J,nhat)
aj      := Const(1*(hbar/2.*alphaH/e/d/ms))

Basically the changes are: define p directly based on J, instead of being a constvector. There is a factor of J_SOT in aj the prefactor, so that needs to be set to 1 to avoid double counting the magnitude of J, as we are now setting J directly. If you replace these in the example workshop script session4_2a (and explicitly disable Zhangli/Slonczewski, just to compare to the example which did not have STT due to how things were defined), it should give identical results as the example. 

For your script, you will want to adjust nhat and sign(alphaH) for your situation, and since you want STT, leave the relevant STT term(s) enabled.  For the nonuniform J as in your case, instead of setting J=vector(-2e11,0,0) directly, you can do 

J.Add("p4_5v.ovf",1) 

(You can skip the newVectorMask part, the result of loadfile is already a slice, the same as NewVectormask, so it is redundant). 

Cheers,
Josh L.

[Harrison Jin]

I understand, I will give it a try. Thank you very much for your help and time!

Respectfully,

Harrison Jin

To view this discussion visit https://groups.google.com/d/msgid/mumax2/946d2c3b-5c56-4d4a-aa54-f5f4c62f164en%40googlegroups.com.