OOMMF Runtime Error on Win10

Question

OOMMF Runtime Error on Win10

lbreth opened this issue 4 years ago · 21 comments

Hi, I am posting this problem, because all notebooks so far worked fine on my Win10 machine (in a conda environment), except periodic-boundary-conditions.ipynb. The following error was raised:

I tried:

restarting the kernel and run all cells again
shutting down jupyter notebook completely
conda update ubermag

but unfortunately nothing worked. Any ideas?

Answer 1 · 2020-06-25T19:37:13.000Z

Hi @lbreth, thank you for your question and sorry for encountering that problem. I will investigate this and get back to you.

Answer 2 · 2020-06-26T06:50:36.000Z

Hmm. I am getting this exact error also. *.mif files are appearing though.

Answer 3 · 2020-06-26T07:17:41.000Z

I am also experiencing the same in running the program "ERROR in OOMMF run"

Answer 4 · 2020-06-26T08:07:02.000Z

It might be valuable to note that at least for myself, I had OOMMFTCL defined prior, and it is holding the cached result of the path even after I deleted the environment variable. Do you guys have the same environment variable defined?

I've tried to do some debugging on my own here, and running

import oommfc as oc
runner=oc.oommf.get_oommf_runner()
oc.oommf.status()

returns 0 and a note that "OOMMF found and running."

I tried to run an example that is shown in the comments of driver.py, and that ran successfully. There was no RuntimeError thrown.

However, still, when attempting the periodic-boundary-conditions notebook the initial error is received upon plotting in the first instance of running the code, then the RuntimeError is thrown.

Answer 5 · 2020-06-26T22:53:14.000Z

@marijanbeg, I noticed some useful information in my command prompt window that may be useful to solve this:

2.0a2 Loop error:
Error thrown from inside "Oxs_Run" --- Oxs_Ext error inside Run() function of driver Oxs_MinDriver: --- Oxs_Ext ERROR: Import mesh to Oxs_DMExchange6Ngbr::GetEnergy() routine of object Oxs_DMExchange6Ngbr: is not an Oxs_RectangularMesh object.
Boxsi run end.
<10312> oommf.tcl 2.0a2  panic:
child process exited abnormally
 <1> mmarchive killed
 <2> mmarchive killed

I'll note that I am using 2.0a2, and I cannot readily get 2.0a1 to be picked back up by oommfc. I've tried to set the associated cache bool to False and resetting the oommf_tcl to the envvar that I redirected to the ubermag install of 2.0a1, but I can't seem to get it to redirect to use ubermag's 2.0a1

Answer 6 · 2020-06-26T23:31:01.000Z

Hi @lbreth, @Harry-09, and @catrevil, thank you for you comments. It took me some time to investigate this since I am not a Windows user and have to do everything through Virtual machines. Here is the summary of the problem:

"Built-in" DMI extension Oxs_DMExchange6Ngbr is a Cnv class DMI and it does not support periodic boundary conditions. Therefore, we wrote our own extensions for Cnv, T(O), and D2d crystallographic classes. Unfortunately, we can compile and package them only for Linux and MacOS, so when OOMMF is installed using conda, you have all those extensions available by default. On Windows, you cannot do that because OOMMF by default does not support DMI with periodic boundary conditions and we have to use precompiled OOMMF and package it as such as a conda package. This is independent of the OOMMF version you are using.
There is a way how to solve this problem using docker. When you have docker installed on your machine, and drive the system, docker image will be pulled automatically from the cloud, a container (small imaginary linux machine) created, simulations run inside the container, and then the container is automatically destroyed. I am in the process of making a tutorial how this can be done. However, in order to make it as straightforward as possible, and to require as little as possible user input, I have to do some changes in oommfc.

In summary: This is a limitation of OOMMF since it does not support DMI with PBC. We wrote our own extensions for OOMMF in order to support all DMI classes as well as PBC, but we can package them using conda only for Linux and MacOS. I made a mistake by showing you a DMI PBC example during the workshop before explaining how to deal with this issue on Windows - apologies. I will do my best to make a tutorial before the next session and ask you all for a few days patience.

I will leave this issue open until we resolve it.

Answer 7 · 2020-07-01T05:04:31.000Z

Dear catrevil sir
I tried as above you told, but i am getting same error. Can u help me to fix the runtime error issue.

Answer 8 · 2020-07-01T06:03:50.000Z

One thing i noticed here when i run dynamics domain wall (problem discussed in tutorial) there is no run time error.

Answer 9 · 2020-07-01T06:49:58.000Z

@gaurav123shukla please take a reading of this reply from Marijan:

Hi @lbreth, @Harry-09, and @catrevil, thank you for you comments. It took me some time to investigate this since I am not a Windows user and have to do everything through Virtual machines. Here is the summary of the problem:

"Built-in" DMI extension Oxs_DMExchange6Ngbr is a Cnv class DMI and it does not support periodic boundary conditions. Therefore, we wrote our own extensions for Cnv, T(O), and D2d crystallographic classes. Unfortunately, we can compile and package them only for Linux and MacOS, so when OOMMF is installed using conda, you have all those extensions available by default. On Windows, you cannot do that because OOMMF by default does not support DMI with periodic boundary conditions and we have to use precompiled OOMMF and package it as such as a conda package. This is independent of the OOMMF version you are using.

There is a way how to solve this problem using docker. When you have docker installed on your machine, and drive the system, docker image will be pulled automatically from the cloud, a container (small imaginary linux machine) created, simulations run inside the container, and then the container is automatically destroyed. I am in the process of making a tutorial how this can be done. However, in order to make it as straightforward as possible, and to require as little as possible user input, I have to do some changes in oommfc.

In summary: This is a limitation of OOMMF since it does not support DMI with PBC. We wrote our own extensions for OOMMF in order to support all DMI classes as well as PBC, but we can package them using conda only for Linux and MacOS. I made a mistake by showing you a DMI PBC example during the workshop before explaining how to deal with this issue on Windows - apologies. I will do my best to make a tutorial before the next session and ask you all for a few days patience.

I will leave this issue open until we resolve it.

What you'll notice is the primary problem was how they were able to implement some extras in ubermag, but these do not play well in windows. Further inspection of the thread before your most recent replies will note that the issue ~~has been~~ will be resolved soon. What this means is that the suggested fixes mention in the reply I quoted ~~have been~~ will be implemented soon. The only path of resolution is to acquire ubermag which has the fix, when this is available. This is trivial, once the solution is complete! 😄

The code that I posted was used to debug to the source of the issue, it does nothing to fix anything related to the problem, nor any problem, really, just a method of trying to see what was not working and why. I did not figure it out, but Marijan did and ~~fixed~~ will soon fix the issue!

As for why it does not appear in the domain wall dynamics tutorial, you must ask yourself, is there a definition of boundary condition made in this example? And the answer to this is no, which is why the problem did not make itself evident, as it was never encountered.

Answer 10 · 2020-07-01T07:07:40.000Z

Hi all, new Ubermag conda packages are being built at the moment and will be available soon :)

Answer 11 · 2020-07-01T22:40:51.000Z

Hi all, thank you for your patience - building conda packages took much longer than we thought. The following should be a solution:

Please install docker on Windows: https://www.docker.com/products/docker-desktop
Update ubermag (conda update ubermag)

And ideally, that's it. Ubermag should be able to detect what OS you have and how to run OOMMF (in standard OOMMF installed via conda or inside a docker container). Please note that the first run is going to take some time, because a docker image must be pulled from the cloud. All other runs in the future are going to be as fast as running them on Conda-installed OOMMF. I do not have a Windows machine in quarantine, so I am not able to test everything properly, so if anything does not work, since Windows is full of surprises, please let me know.

For more details, there is a short tutorial (only if you want to be explicit): https://oommfc.readthedocs.io/en/latest/ipynb/docker-simulations.html

I am going to cover all this during the next live session as well.

Answer 12 · 2020-07-03T18:39:39.000Z

Hi all, did this docker solution work for you or you still have issues running DMI simulations? As I said, I do not have a Windows machine in quarantine to test it, so it would be good if somebody can check this for me :)

Answer 13 · 2020-07-03T19:48:07.000Z

Hi Marijan, I did try it as you described above, but unfortunately it did not work. I still get that same errorneous behavior as described initially. I am actually wondering if it has sthg to do with the "division by zero" issue that seems to be present already before calling OOMMF (see screenshot in my initial posting). Cheers!

Answer 14 · 2020-07-03T19:57:23.000Z

I am currently setting Docker up on my Windows side of my desktop (I had it in a WSL Ubuntu install, and not my Windows OS), so I will verify soon if the solution works.

@lbreth did you specify a runner for the driver? If you received the same tcl runner error, you likely missed this step. (I did, too!) I recommend taking a look at the choosing runners tutorial (as I soon will, too!) and seeing if this allows you to use the Docker runner (as will I! (did you install Docker?)).

Answer 15 · 2020-07-03T21:27:37.000Z

@marijanbeg calling for conda update ubermag within (ubermag) seemed to work, but only to the unkeen eye--no new updates to the actual core packages were pulled down. I called conda update ubermag once more within (ubermag) and even still, it is not made aware of any updates being available.

This is likely why @lbreth is getting errors. I get the exact same error as one would get attempting to use the ubermag install of oommf for something such as this.

I'm not sure if this is something that can be fixed as simply as ensuring the new builds are known to the appropriate servers, or how exactly that works, but I can't get conda to automatically pull down the updated oommfc and related ubermag packages. I may be doing something wrong, of course, but I would have thought it should be just that, calling for conda update ubermag within the (ubermag) environment, but this is not doing what I expect it should be doing.

Edit: I also get this divide by zero error which does not appear upon a second run of the cell which produced it, and the version of ubermag noted by conda when calling `conda list` in `(ubermag)`, after `conda update ubermag` remains 0.22 with `oommfc` still listed as 0.8.20 -- is it something to do with `conda-forge`?

Answer 16 · 2020-07-03T21:38:29.000Z

Hi, thank you both for letting me know. That's strange.

What if you try being specific: conda install --channel conda-forge ubermag=0.23. This should effectively be the same as updating.

Answer 17 · 2020-07-03T21:43:55.000Z

@marijanbeg that seemed to have done it, at least noting and updating the relevant modules/packages!
I found it strange that when I called for the update before, it removed:

python_abi conda-forge/win-64::python_abi-3.8-1_cp38

and now this has been reinstalled!

AND IT WORKS! Even after having installed the image prior to this re-updated update!! WOO!!

Edit: I still get this when we call system.m.plane( 'z' ).mpl( )

D:\miniconda3\envs\ubermag\lib\site-packages\matplotlib\quiver.py:715: RuntimeWarning: divide by zero encountered in double_scalars
  length = a * (widthu_per_lenu / (self.scale * self.width))
D:\miniconda3\envs\ubermag\lib\site-packages\matplotlib\quiver.py:715: RuntimeWarning: invalid value encountered in multiply
  length = a * (widthu_per_lenu / (self.scale * self.width))
D:\miniconda3\envs\ubermag\lib\site-packages\matplotlib\quiver.py:767: RuntimeWarning: invalid value encountered in less
  short = np.repeat(length < minsh, 8, axis=1)
D:\miniconda3\envs\ubermag\lib\site-packages\matplotlib\quiver.py:780: RuntimeWarning: invalid value encountered in less
  tooshort = length < self.minlength

which is mighty odd, but it does not reoccur when you evaluate the cell again.

Edit edit: And the autodetect works flawlessly. Major kudos to you @marijanbeg

Answer 18 · 2020-07-03T21:52:02.000Z

I also do not know what the issue with conda update could be. It is a straightforward command and should simply work.

Just to confirm I undrestood you right:

Does DMI with PBC example work on Windows?
If yes, does it work both when you specify the runner (md.drive(system, runner=...)) and when you do not specify it (md.drive(system))?
Do you get a message something like Running OOMMF (DockerOOMMFRunner)...?

Sorry for asking so many questions, but, as I said, I have no chance of testing this on a Windows machine at the moment.

Answer 19 · 2020-07-03T21:57:51.000Z

Regarding the plotting warning thrown by matplotlib: I need to investigate this a bit further, but I think I know what causes this issue. Since this is "just a warning" and disappears by running the cell again, I would treat this as a low-priority bug and would not rush fixing it right now. It is going to be addressed in the next release. I am going to raise an issue about this in our help repository just to make sure we do not forget about it.

Answer 20 · 2020-07-03T21:58:57.000Z

@marijanbeg apologies, I updated my reply after sending it, this is likely not a traditional method of how one should use github, but I digress. To answer your questions explicitly:

Yes, DMI with PBC example works on Windows.
Yes, both specifying the runner and using it without specification work.
Yes, I get a message that says precisely this. To download the image initially took a grueling 58ish seconds, but to call it after this (using explicit specification or letting the automation work) takes 1.4 seconds :)

tl;dr Everything works as intended, once the versions in which the intentions exist are present on the user's PC ;)

Answer 21 · 2020-07-03T22:03:29.000Z

Amazing! Thanks a lot for checking this for me - much appreciated @catrevil!

Let me summarise the solution here:

Update Ubermag by running conda install --channel conda-forge ubermag=0.23
Install docker https://www.docker.com/products/docker-desktop

Ubermag is then able to determine which runner it should use depending on the energy equation used and mesh boundary conditions.

matplotlib warning is going to be treated as a low-priority bug and fixed in the next release. thank you all for you help!