Fine grained parameters

[arash-mc]

Right now I am working on a paper that needs fine-grained parameters such as Ku1 or anisotropy. As we know these are defined as regionwise parameters in the code. I tried to change the number of regions by changing the types etc. it worked but I believe the scientific results are not correct. I prefer If I could just have a LoadFile function like we have for magnetization for these parameters too. I tried the load file and EvalTo in the code but I get errors. Can anyone please say if there is a hack to do this in the scripts or implement this functionality?

[JonathanMaes]

I don't think it is possible to implement support for LoadFile like this, because Ku1 is a regional parameter. It just stores a scalar value for every region index, but LoadFile returns a 3D array.

A possible alternative is to use regions.LoadFile(...) if you have an OVF file that contains the appropriate region assignments, and then in the input script provide a mapping of region index to the desired values of your fine-grained parameters.

[jplauzie]

Hi,

I would first double check your change to number of regions. While it's not quite as flexible as having an arbitrary 3D array, going from a char (limit of 256 regions) to an int (~65,000+ regions max, depending on the type of int) should be enough for the vast majority of cases. If your script is <65,000 cells total, it should be equivalent to loading a full OVF- you can literally assign one cell per region.

It's not really possible to directly convert material parameters to a full slice/array. The reason regions are limited to a char(256), is because the memory requirements scale very poorly (exchange in particular scales as regions^2). You may have already noticed this in your implementation. And having a look-up table for regions saves a massive amount of memory compared to storing an entire array of values for each cell for material parameters.

However, one can almost do what you want with custom fields instead, if you look to "Custom effective field terms" and "custom quantities" in the API. The one roadblock is that there is currently no way for a user to define a fully spatially varying custom Quantity. You can currently only make custom Quantities using Const() and ConstVector(), or out of existing Quantities (like m or J). But there are not that many Quantities exposed to the user, only m or J are fully customizable ones. The only trick I know within existing mumax to get around this, is you can re-use J as a dummy variable, if you are not using J within your script at all for normal things (make sure to disable things like STT torques that rely on J). J is already a Quantity, so you can repurpose it and set it to arbitrary values using J.add(). I've attached an example of this (it's basically a mix of the "spinning hard drive" example on the example page, and the "Custom effective field terms" in the API). Instead of using a mask, you should also be able to use J.Add(LoadFile("current.ovf"), 1) if you prefer, as listed under Excitations in the API. You should of course be very careful with this, as it's not really meant to be used this way. It's a kludge, and not one that I've extensively tested. I did confirm it gives a nonzero B_custom and didn't seem to immediately crash, however.

If you can't abuse J in this way, there is no way to do this in current mumax. There are 2 forks (I mentioned them here, listed under 2). They aren't currently implemented in mumax though, so it would take some work to integrate them. I think (but have not tried) the one from umagnus should be easy- it should just be a matter of copy/pasting the CustomQuantity function and recompiling. Once you do that, you can load an arbitrary ovf using Loadfile() to get it as a slice/array, promote it to a Quantity, and use custom fields without kludging around with J.

customfields_using_J.txt

Best,
Josh L.