Postprocessing mumax3 data in Python

[Diksha Prajapati]

Hello everyone,

I am trying to perform the post processing of mumax3 data in Python. I referred to the "Skyrmion excitation  example". Kindly refer the code below:

# Stack all snapshots (4D arrays) of the magnetization on top of each other

# The results in a single 5D array (first index is the snapshot index)

m = np.stack([fields[key] for key in sorted(fields.keys())])

# Select the z component and the (only) layer z=0

mz = m[:,2,0,:,:]

# Apply the FFT for every cell

mz_fft = np.fft.fft(mz, axis=0)

https://colab.research.google.com/github/JeroenMulkers/mumax3-tutorial/blob/master/postprocessing.ipynb

I want to ask few questions in this code. As I am not able to understand it properly.

1. Does the single 5D array which is forming after stacking all 4D array(ovf files) is an array which contains value of (mx,my,mz) of each cell at different time?

2. How can I select y-component instead of z-component? I tried to do so and selected it as below-

my = m[:,1,0,:,:]

But I am getting error as below:

 value error: All input arrays must have the same shape.

Can someone please tell me what does it mean by the shape of input array?

I would be very thankful if someone can explain it to me.

With Regards,

Diksha

[Josh Lauzier]

Hi,

1)

Yes, the single 5D array (called "m") in the script contains mx,my,mz. To pick which magnetic component, it is the 2nd index. 0 for the x-component, 1 for the y, and 2 for z. The 5 indexes are: time (using : tells it you want all of these), the magnetization component, then the z portion of the structure, then y, then x. So it is stacking all of the time components, the y-component (if it is set to 1). So m[:,1,0,:,:] is grabbing all of the snapshots in time, with the y component of the magnetization, the 0th z-layer (indexing in python starts at 0, and there is only a single layer in the z), all the y layers, and all the x layers.

2)

Changing the second index from 2 to 1 should indeed get you the y-component of the magnetization. If that is the only change you made, it should not cause that error by itself. The error is related to some other change.

It would also help to post the entire error, as it is likely happening in the previous line 'm = np.stack([fields[key] for key in sorted(fields.keys())])'. Python gives error messages that lets you trace back to which line caused issues, and the issue likely happened before the script even got to the line 'my = m[:,1,0,:,:]'.

The shape of the input array comes from the OVF data. So for instance, if you have 45 snapshots of a structure that is 32x32x1 cells, the np.stack function will stack 45 arrays of 3x1x32x32, resulting in a single 45x3x1x32x32 array. However, if there is an OVF that doesn't match those sizes for some reasons (say you ran a previous script with a different structure, and didn't clear the output folder. Or you canceled a simulation mid-run), it will give an error. For instance if you had 45 3x1x32x32 arrays, but one left over 3x1x20x20 array from a previous script in the same folder. It won't know what to do with that 3x1x20x20 array to make it stack properly, since it is not the same size as the 3x1x32x32 arrays, and give this error.

You should check the fields variable and see what size each array is (alternatively, just check the OVF files themselves generated by mumax). Somewhere in there, you likely have a bad (mis-sized) OVF file. Most likely, you have a left over OVF sitting in the folder from some other task that is the wrong size. The read_mumax3_ovffiles python script from the colab just grabs all OVFs in a folder based on the OVF filetype, so if you have a leftover OVF from a different sized script in the same folder or something, it will give an error.

For example if you were generating 45 OVF files, but you cancelled it and shortened it to 25 to test faster. The new script will overwrite the first 25 OVFs automatically, but the second 20 old files will just sit in the directory, and still be seen by the rread_mumax3_ovffiles function. And if you cancelled midway through say the 45th run, that 45 OVF file will only be half-full or empty. 

For more discussion with someone who had a similar type of error (and some suggestions on how to actually check the size of the arrays), see this discussion: https://groups.google.com/g/mumax2/c/XxHBnRRD_wk/m/MgW3ZOM-AwAJ

Best,

Josh L.

[mumax2]

Thank you so much Josh, this is very helpful.

Regards,

Diksha

[Diksha Prajapati]

Dear Josh,

The total number of  keys generated also consist one key named "regions000000", because in my original source code I defined total 18 regions and saved them. This particular key is causing problem in stacking all the .ovf files when I am giving the command as below:

 m = np.stack([fields[key] for key in sorted(fields.keys())])

Even if I am deleting .ovf and .npy corresponding to regions000000, it is generating every time when I am running the code. Could you please suggest something to sort this problem out. Hoping to hear from you soon. Thank you.

With regards,

Diksha

[Josh Lauzier]

Hi,


Having any other type of OVF file in the folder will cause that problem, since the python program just grabs all OVF files without distinguishing. There are two ways to solve the problem, while still saving the regions OVF. One is to change the line in the python function read_mumax3_ovffiles:

p = run(["mumax3-convert","-numpy",outputdir+"/*.ovf"], stdout=PIPE, stderr=STDOUT)

to something like

p = run(["mumax3-convert","-numpy",outputdir+"/m*.ovf"], stdout=PIPE, stderr=STDOUT)


This way, mumax3-convert looks for files of the form m*.OVF. This should only capture OVF files that start with m (* is a wildcard character, so anything between m and .ovf will be seen. Note if you have any other OVF files that start with m, they might still trigger, so you would have to get even more specific with the filenames it's searching). The other solution would be to move the regions file out of the folder. Adding something like

os.rename("C:\files\regions000000.ovf", "C:\backup\regions000000.ovf")

would move the file from the 'files' folder to the 'backup' folder. You would need to give the full file paths- where the regions OVF exists, and where you want it moved to. Of course, if you use this method, you should move the file before the program tries to read all the other OVFs.

Best,

Josh L.

[Diksha Prajapati]

Thank you so much Josh, it worked for me.

With regards

Diksha 

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/mumax2/92ae2f9d-378f-483f-ad3e-b0bcbf629895n%40googlegroups.com.