ubermag / oommfc

OOMMF calculator.

ubermag

Marijan Beg^1,2, Martin Lang², Samuel Holt^2,3, Swapneel Amit Pathak^2,4, Ryan A. Pepper⁵, Thomas Kluyver⁶, Jeroen Mulkers⁷, Jonathan Leliaert⁷, and Hans Fangohr^2,4,8

¹ Department of Earth Science and Engineering, Imperial College London, London SW7 2AZ, UK
² Faculty of Engineering and Physical Sciences, University of Southampton, Southampton SO17 1BJ, UK
³ Department of Physics, University of Warwick, Coventry CV4 7AL, UK
⁴ Max Planck Institute for the Structure and Dynamics of Matter, Luruper Chaussee 149, 22761 Hamburg, Germany
⁵ Research Software Group, University of Birmingham, Birmingham B15 2TT, UK
⁶ European XFEL GmbH, Holzkoppel 4, 22869 Schenefeld, Germany
⁷ Faculty of Sciences, Ghent University, Krijgslaan 281, S12, 9000 Ghent, Belgium
⁸ Center for Free-Electron Laser Science, Luruper Chaussee 149, 22761 Hamburg, Germany

Description	Badge
Tests
Linting
Releases
Coverage
Documentation
YouTube
Binder
Platforms
Downloads
License
DOI

About

ubermag is a Python package, integrated with Jupyter, providing:

• Meta package for Ubermag project,

• Logging control in Ubermag packages.

It is available on Windows, MacOS, and Linux. It requires Python 3.8+.

Documentation

APIs and tutorials are available in the documentation. To access the documentation, use the badge in the table above.

Installation, testing, and upgrade

We recommend installation using conda package manager. Instructions can be found in the documentation.

Binder

This package can be used in the cloud via Binder. To access Binder, use the badge in the table above.

YouTube

YouTube video tutorials are available on the Ubermag channel.

Support

If you require support, have questions, want to report a bug, or want to suggest an improvement, please raise an issue in ubermag/help repository.

Contributions

All contributions are welcome, however small they are. If you would like to contribute, please fork the repository and create a pull request. If you are not sure how to contribute, please contact us by raising an issue in ubermag/help repository, and we are going to help you get started and assist you on the way.

Contributors:

License

Licensed under the BSD 3-Clause "New" or "Revised" License. For details, please refer to the LICENSE file.

How to cite

1. M. Beg, M. Lang, and H. Fangohr. Ubermag: Towards more effective micromagnetic workflows. IEEE Transactions on Magnetics 58, 7300205 (2022).

2. M. Beg, R. A. Pepper, and H. Fangohr. User interfaces for computational science: A domain specific language for OOMMF embedded in Python. AIP Advances 7, 56025 (2017).

3. Marijan Beg, Martin Lang, Samuel Holt, Swapneel Amit Pathak, Ryan A. Pepper, Thomas Kluyver, Jeroen Mulkers, Jonathan Leliaert, and Hans Fangohr. ubermag: Meta package for Ubermag project. DOI: 10.5281/zenodo.3539495 (2022).

Acknowledgements

• OpenDreamKit – Horizon 2020 European Research Infrastructure project (676541)

• EPSRC Programme Grant on Skyrmionics (EP/N032128/1)

oommfc's Issues

How can I install oommfc ???

Hello,
I am new to working with the software and trying to learn OOMMF by following the Tutorials.
I tried to install Anaconda and run oommfc.
After running oommfc by this command: conda install --channel conda-forge oommfc
I got the following message:

============================= warnings summary =====================================
anaconda3\envs\EMADI\lib\site-packages\pyreadline\py3k_compat.py:8
C:\Users\emadi\anaconda3\envs\EMADI\lib\site-packages\pyreadline\py3k_compat.py:8: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working
return isinstance(x, collections.Callable)

-- Docs: https://docs.pytest.org/en/stable/warnings.html
==================== 81 passed, 6 skipped, 1 warning in 760.12s (0:12:40) =========================

and also when I import oommfc in python, I got the error message:
ModuleNotFoundError: No module named 'oommfc'
How can I install oommfc?
Can someone help me out, please?

Many thanks in advance
sedighe

LaTeX output. doesn't render in readthedocs

Output cells 5 and 6 on https://oommfc.readthedocs.io/en/latest/ipynb/spatially_varying_parameters.html#Spatially-varying-parameters show LaTeX source instead of the rendered equations.

Probably not specific to OOMMFC, but here we have an example.

$\frac{\partial \mathbf{m}}{\partial t}=-\gamma_{0}^{*} \mathbf{m} \times \mathbf{H}_\text{eff}+\alpha \mathbf{m} \times\frac{\partial \mathbf{m}}{\partial t}$

Support for Xf_ThermSpinXferEvolve

Hi!
Is there any kind of support for Xf_ThermSpinXferEvolve?
https://kelvinxyfong.wordpress.com/research/research-interests/oommf-extensions/oommf-extension-xf_thermspinxferevolve/

Thanks

Use new discretisedfield syntax

Extending tests

At present, we do not have tests for the mif file being written by oommfc for a given simulation. It will be good to add these to ensure proper testing and avoid bugs like #136.

std problem 5 test failing

Just trying with the latest version as of now:

import oommfc
oommfc.test()

all tests pass, apart from this:

============================================================================== FAILURES ==============================================================================
___________________________________________________________________________ test_stdprob5 ____________________________________________________________________________

    @pytest.mark.oommf
    def test_stdprob5():
        name = "stdprob5"

        # Remove any previous simulation directories.
        if os.path.exists(name):
            shutil.rmtree(name)

        # Geometry
        lx = 100e-9  # x dimension of the sample(m)
        ly = 100e-9  # y dimension of the sample (m)
        lz = 10e-9  # sample thickness (m)

        # Material (permalloy) parameters
        Ms = 8e5  # saturation magnetisation (A/m)
        A = 1.3e-11  # exchange energy constant (J/m)

        # Dynamics (LLG + STT equation) parameters
        gamma = 2.211e5  # gyromagnetic ratio (m/As)
        alpha = 0.1  # Gilbert damping
        ux = -72.35  # velocity in x direction
        beta = 0.05  # non-adiabatic STT parameter

        system = oc.System(name=name)
        mesh = oc.Mesh(p1=(0, 0, 0), p2=(100e-9, 100e-9, 10e-9),
                       cell=(5e-9, 5e-9, 5e-9))
        system.hamiltonian = oc.Exchange(A) + oc.Demag()

        def m_vortex(pos):
            x, y, z = pos[0]/1e-9-50, pos[1]/1e-9-50, pos[2]/1e-9
            return (-y, x, 10)

        system.m = df.Field(mesh, value=m_vortex, norm=Ms)

        md = oc.MinDriver()
        md.drive(system)

        system.dynamics += oc.Precession(gamma) + oc.Damping(alpha) + \
            oc.STT(u=(ux, 0, 0), beta=beta)

        td = oc.TimeDriver()
        td.drive(system, t=8e-9, n=100)

        mx = system.dt["mx"].as_matrix()

>       assert -0.03 < mx.max() < 0
E       assert 0.32890981244484879 < 0
E        +  where 0.32890981244484879 = ()
E        +    where  = array([-0.00585324,  0.07644325,  0.10511611,  0.14835181,  0.22632496,\n        0.27594319,  0.30758326,  0.32858074, ...587295,  0.20530587,  0.2046604 ,  0.20404881,\n        0.20356513,  0.20327149,  0.20319252,  0.2033168 ,  0.20360366]).max

oommfc/oommfc/tests/test_stdprob5.py:56: AssertionError
------------------------------------------------------------------------ Captured stdout call ------------------------------------------------------------------------
2017/7/21 9:12: Calling OOMMF (stdprob5/stdprob5.mif) ... [0.7s]
 <1> mmarchive killed
 <2> mmarchive killed
2017/7/21 9:12: Calling OOMMF (stdprob5/stdprob5.mif) ... [10.1s]
 <1> mmarchive killed
 <2> mmarchive killed
 <3> mmarchive killed
------------------------------------------------------------------------ Captured stderr call ------------------------------------------------------------------------
<86365> killoommf  Oc_Config warning:
Tcl version mismatch:
	/Users/fangohr/anaconda3/envs/joommf-dev2/lib/tclConfig.sh from 8.5.19
	Running Tcl 8.5.9
<86404> killoommf  Oc_Config warning:
Tcl version mismatch:
	/Users/fangohr/anaconda3/envs/joommf-dev2/lib/tclConfig.sh from 8.5.19
	Running Tcl 8.5.9
========================================================================= 3 tests deselected =========================================================================
======================================================== 1 failed, 126 passed, 3 deselected in 138.09 seconds ========================================================

OOMMFC version used:

commit 23c5baf96788e8d1c40dbdf5325d4216a658ddaa (HEAD -> master, origin/master, origin/HEAD)
Author: Thomas Kluyver 
Date:   Wed Jun 21 12:02:26 2017 +0100

    Change how we check for a conda environment on Windows

Rewrite OOMMF class tests

At the moment, OOMMF class tests rely on the environment variables that are set on Travis. Because of this, some of the OOMMF tests fail on different machines. They should be rewritten.

Import warning

When importing oommfc, I get the warning:

/Users/ryan/anaconda3/envs/oommfc/lib/python3.5/site-packages/matplotlib/__init__.py:1357: UserWarning:  This call to matplotlib.use() has no effect
because the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

  warnings.warn(_use_error_msg)

Add standard problem 1 test

This standard problem includes running hysteresis driver and should be covered in tests.

Tell user when OOMMF is called

We should inform user when OOMMF is called. An option could be to write to terminal OOMMF is called. This may take a while.

The reason for this is so that user knows when OOMMF is computing something and that user should wait.

test_stsdprob5 failure

• Installed oommfc via conda
• installed joommf via pip install
• on OS X

Running

    >>>import joommf
    >>>joommf.test()

results in this error

=========================================================== FAILURES ============================================================
_________________________________________________________ test_stdprob5 _________________________________________________________

    @pytest.mark.oommf
    def test_stdprob5():
        name = "stdprob5"

        # Remove any previous simulation directories.
        if os.path.exists(name):
            shutil.rmtree(name)

        # Geometry
        lx = 100e-9  # x dimension of the sample(m)
        ly = 100e-9  # y dimension of the sample (m)
        lz = 10e-9  # sample thickness (m)

        # Material (permalloy) parameters
        Ms = 8e5  # saturation magnetisation (A/m)
        A = 1.3e-11  # exchange energy constant (J/m)

        # Dynamics (LLG + STT equation) parameters
        gamma = 2.211e5  # gyromagnetic ratio (m/As)
        alpha = 0.1  # Gilbert damping
        ux = -72.35  # velocity in x direction
        beta = 0.05  # non-adiabatic STT parameter

        system = oc.System(name=name)
        mesh = oc.Mesh(p1=(0, 0, 0), p2=(100e-9, 100e-9, 10e-9),
                       cell=(5e-9, 5e-9, 5e-9))
        system.hamiltonian = oc.Exchange(A) + oc.Demag()

        def m_vortex(pos):
            x, y, z = pos[0]/1e-9-50, pos[1]/1e-9-50, pos[2]/1e-9
            return (-y, x, 10)

        system.m = df.Field(mesh, value=m_vortex, norm=Ms)

        md = oc.MinDriver()
        md.drive(system)

        system.dynamics += oc.Precession(gamma) + oc.Damping(alpha) + \
            oc.STT(u=(ux, 0, 0), beta=beta)

        td = oc.TimeDriver()
        td.drive(system, t=8e-9, n=100)

        mx = system.dt["mx"].values

>       assert -0.03 < mx.max() < 0
E       assert 0.32890981244497575 < 0
E        +  where 0.32890981244497575 = ()
E        +    where  = array([-0.00585324,  0.07644325,  0.10511611,  0.14835181,  0.22632496,\n        0.27594319,  0.30758326,  0.32858074, ...587295,  0.20530587,  0.2046604 ,  0.20404881,\n        0.20356513,  0.20327149,  0.20319252,  0.2033168 ,  0.20360366]).max

anaconda3/envs/joommf2/lib/python3.6/site-packages/oommfc/tests/test_stdprob5.py:56: AssertionError
----------------------------------------------------- Captured stdout call ------------------------------------------------------
2018/7/3 16:43: Calling OOMMF (stdprob5/stdprob5.mif) ... [0.6s]
 <1> mmarchive killed
 <2> mmarchive killed
2018/7/3 16:43: Calling OOMMF (stdprob5/stdprob5.mif) ... [8.7s]
 <1> mmarchive killed
 <2> mmarchive killed
 <3> mmarchive killed
======================================= 1 failed, 257 passed, 2 skipped in 223.65 seconds =======================================
Out[4]: 1

Update notebooks

Are we actually running the --nbval tests on travis?

Looks to me as if we are not. There is some duplication of commands in target "test-docker" and in .travis.yml, and the --nbval-lax command is in the Makefile target, but as far as I can see we are not actually calling that on Travis.

Suggested action: update so that Makefile target is used inside docker in .travis.yml.

Is it worth checking if the OOMMF version installed is compatible with the OOMMF we are using?

It is possible that OOMMF changes its API (and format in the MIF files over time). Should we check at oommfc start up time that the version we see is sufficiently recent?

What is probably more likely to happen is that OOMMF requires an extension to be present which is not installed, and then the run will fail. We can to some degree produce a helpful error message with this issue: https://github.com/joommf/oommfc/issues/29,

But should we take it further? We could - at the beginning of a run, call OOMMF with a tiny test problem for each non-standard extension we use to check it is installed, and report accordingly if it isn't? Or does OOMMF even have a mechanism to report all available extensions?

Calling OOMMF occasionally shows ~6 second overhead

This problem is observed on OS X (so far). In a non-reproducible fashion, sometimes calling OOMMF (through OOMMFC) takes about 6 seconds whereas at better times it takes about 1 second.

(The 1 second can be reduced further.)

A convenient way to test this, is to run this command:

(joommf) bash-3.2$ python -c "import oommfc; oommfc.test_oommf_overhead()"

The output could read:

2017/4/19 20:51: Calling OOMMF (example-macrospin/example-macrospin.mif) ... [0.9s]
 <1> mmarchive killed
 <2> mmarchive killed
 <3> mmarchive killed
Duration of calling OOMMF through oommfc: 1.835s
oommfc.oommf.status(): {'host': True, 'docker': True}

When the 6 second delay is active, one of the timing numbers (0.9 or 1.835?) seconds increases to ~6 or 7 seconds.

We have started the performancetests to dig into this. (Mostly adding logging so far.)

Damping Constant alpha: how to set for both equilibrium state and dynamic response?

Is it possible to set two different alpha damping constants for both the equilibrium state and the dynamic response of the applied field? How would I do this?

Test OOMMF setup with tiny test problem

I have seen a case where the oommf.tcl +version worked fine but calling OOMMF didn't work for any real simulation work. This had to do with confusion about multiple Tk/Tcl versions installed on the system. It would be good to be able to detect this situation.

I propose that we have a tiny tiny micro magnetic problem that we can run for this purpose. For example a single cell (i.e. macro spin) run. We could even take problem where we know the analytic solution and compare the computed output (at very few data points) with that solution.

This should be able to run very quickly, so that we can inject it in various places to see whether we are ready to embark on a larger calculations

OOMMF M1 build

Add OOMMF M1 conda build and switch back to macos-latest (temporarily downgraded in #154 )

Extend documentation for all the drivers

There is a lack of proper documentation (docstrings) for different driver classes as pointed out by @lang-m.

Review detection of OOMMF

The current ways of detecting OOMMF cannot find a conda-installed OOMMF when the ubermag environment is used as a custom ipython kernel because the executable is not in the path in this situation. It would be useful to have an additional check for OOMMF in the know conda installation path relative to oommfc.

Update standard problem 3

We currently fix the length of the cube, rather than fixing A and Ms. The advantage of this approach is that the cube's size doesn't change, and thus plotting of it (including cross sections ah half heigh) are easier to do. The disadvantage is that it is slightly counterintuitive for a a problem that requires to find the the length L for which the energies of the two configurations are the same. As L is the cube size expressed in multiples of the exchange length, this is okay: we are changing the exchange length rather than the cube size to find the solution.

It might be good to update the text to explain this, though.

(We could also try to write a second version of the code that actually changes the size - if only to see how well we can support this with the init functions that would need to know the cube size. Should start a second issue if we do this.)

save magnetisation data at every field value in hysteresis loop

Hi,
Thank you very much Ubermag team for a nice project. I have a question, how is it possible for me to save the magnetisation data at every field value during the hysteresis loop recording.

In addition is it also possible to apply an external field at say a small angle with respect to x,y,z axis?

Question: Visualization of k3d mesh not the same as tutorial

OS Catalina 10.15.6
python 3.8.5

I'm wondering if you know or if it is important why the k3d visualized mesh for the tutorial is not the same as what is showing up in Jupyter Notebook? I installed with conda-forge, with no errors but some warnings. Everything else seems to be working correctly for what I have tested thus far. I tried uninstalling and reinstalling the newest Ubermag installation through conda-forge. Same thing happens.

Tutorial:

Jupyter Notebook Test:

Unpacking tuples not supported in Python 3.4

We probably ought to support this version as 3.4 is the default Python 3 install on Ubuntu 14.04 which is still in use in many places.

import oommf error

I followed the instructions that was given to me,

So, I did these steps:

1. $ conda create -n mumax_3 python=3.5
2. $ conda activate mumax_3
3. $ pip install git+git://github.com/ubermag/oommfc.git
4. conda install --channel conda-forge oommf

Then, it was still not able to import oommf:

Request for some indication for not using dynamics equation when using TimeDriver()

The simulation "runs" but nothing happens.

Fixing cells

Cells fixed in one calculation are also wrongly fixed in all subsequent calculations, if variable fixed is not "used" (i.e. using the default fixed=None) in subsequent calculations.

sarge "no stderr" on windows issue

We have an error [1] that only occurs [2] on windows. It seems to come down to a sarge object not having a 'stderr' attribute, where it would have this on Linux/OSX.

The line that actually raises the error is in this function: https://github.com/joommf/oommfc/blob/master/oommfc/oommf.py#L18

Could somebody with a windows environment and/or experience look into this, please? (maybe @rpep, @takluyver )

[1] https://ci.appveyor.com/project/conda-forge/oommfc-feedstock/build/1.0.3/job/3js9n9hwmxgjmu7t#L653
[2] conda-forge/oommfc-feedstock#1

This bug prevents our updated conda-forge package for oommfc from being built (conda-forge/oommfc-feedstock#1)

@marijanbeg - for information.

macrospin.mif not readable when using docker runner with `selinux`

When using docker as a runner for oommf, macrospin.mif is not readable. I'm using Linux (Fedora 35). The issue seems to be, that the mounted volume in the docker container lacks read/write permission. I could resolve the issue by adding a ":z" in line 345 to the volume mounting in the oommf.py (in the _call function of DockerOOMMFRunner).
I suggest the line 345 to be like this: cmd = [self.docker_exe, 'run', '-v', os.getcwd()+':/io:z',
I was not sure how to directly suggest this as a change instead of opening an issue, for me it is resolved with this change. Maybe someone can try if this breaks some functionality for MacOS.

import oommfc as oc error

The error message is attached:

Docker image

oommfc is still using OOMMF 2.0a2 when using the docker runner. This has to be updated to 2.0a3 after the new image has been created.

how to calculate the m component parallel to the applied magnetic field

Rewrite calling OOMMF tests

OOMMF calling tests for Travis are temporarily disabled. They should be rewritten after OOMMF call refactoring.

Compute secondary fields interactively

Step 1: implement this naively

Everytime hamiltonian.INTERACTION.field, or
hamiltonian.INTERACTION.energy or hamiltonian.INTERACTION.energy_density is called, we execute OOMMF to retrieve that information and return it.

Disadvantages: lots of calling of OOMMF if we need multiple field values.

Issue #10 is (expected) to be a performance improvement on this.

Compute secondary fields more efficiently

This is an improvement to follow issue #9

Develop an dependency engine so that we have some flag somewhere that records whether

• m
• H
• or interaction terms
  have changed since we computed interaction data last with OOMMF

If the user requests any of the computed interactions, we check whether we have cached data that is still up-to-date. If so, we return the cached data. If not, we call OOMMF to compute the interaction values.

Whenever we call OOMMF, we store all fields, energies and energy densities to disk and cache them.

This could be realised with the concept of 'virtual time'.

Support +platform command

In addition to be able to call oommf.version, it would be useful to be able to run oommf.platform which calls the +platform output from oommf. This gives more diagnosis output.

Spatially uniform DMI and subregions

Specifying the value of D for DMI with a real number produces an error when subregions are defined for the mesh.

Example:

• mesh with two subregions fixed1 and fixed2 (to fix cells during minimisation)
• uniform DMI defined via mm.DMI(D=..., ...)
• Error message:
  Error thrown from inside "Oxs_ExtCreateAndRegister" --- Incomplete or incorrect initialization --- Oxs_Ext initialization error in construction of Oxs_DMI_T:dmi --- Oxs_Ext ERROR in object Oxs_DMI_T:dmi: First entry in D[0] sub-list, "main", is not a known region in atlas "Oxs_MultiAtlas:main_atlas". Second entry in D[0] sub-list, "main", is not a known region in atlas "Oxs_MultiAtlas:main_atlas". Known regions:
universe
fixed1
fixed2

Bug: visible in plot_slice, but probably reference issue

See dev/bugs/issue-18.ipynb

Update/review documentation

• DMI extensions
• Evolvers at finite temperature
• Time-dependent fields/currents

Mif-file generation broken

The changes in micromagneticmodel.term.__contains__ (checking for all attributes) introduced in ubermag/micromagneticmodel#46 breaks the mif file generation. In driver.py:driver_script we use mm.Damping() in system.dynamics tests (similar for mm.Precession). Without the correct arguments these tests fail and we write wrong alpha values to the mif file.

[Bug] Parameters with scalar field written as vector field

Some of the energy terms (e.g. ZhangLi.u) can be defined with a scalar (dim=1) field. However, when writing the input for OOMMF the field is saved with extend_scalar=True (which repeats the single component three times). For ZhangLi.u OOMMF fails because it expects a scalar field but reads a vector field.

The relevant parts of the code:

oommfc/oommfc/scripts/evolver.py

Lines 24 to 25 in 547ece4

	if hasattr(evolver, "u"):
	umif, uname = oc.scripts.setup_scalar_parameter(evolver.u, "zl_u")

oommfc/oommfc/scripts/util.py

Lines 78 to 80 in 547ece4

	def setup_scalar_parameter(parameter, name):
	if isinstance(parameter, df.Field):
	parameter.write(f"{name}.ovf", extend_scalar=True)

@marijanbeg Is there any casy where we need extend_scalar=True in the input for OOMMF (because we start from a scalar field where OOMMF expects a vector field)?

No DMI Tests

I'm not sure how to subclass the micromagnetic test cases like in Exchange so I haven't written one, but there are no tests of the DMI class and they 'crystalclass' argument. The commit c08c833 fixes where when crystalclass was set to interfacial, it checked against the now removed 'kind' argument, and this would probably have been picked up by a test.

Expose the contents of the `mif` file as a string

To address the issue #139 , @fangohr and @lang-m suggested that:

• We add a method to the driver class which returns the contents of the mif file for the simulation set up as a string.
• Have an argument in the drive method for a "dry run" of the simulation which creates a mif file without running the simulation.

Personally, I am leaning towards returning the string. We can use regex to test it later maybe (?).

how to use Ubermag docker image with Jupyter notebook

Dear developers,

I tried pulling "docker pull ubermag/oommf:latest" and running it on Windows pc. It seems all fine, but I prefer running it on Jupyter with all matlibplot, numpy etc. libs just as we use it on Binder, rather than working on the terminal. I also docked Jupyter notebook, and I can run it on my browser. I got now stuck on how to combine the two, so that when I run a 'merged' image for example, oommfc, discretisedfiel, matplotlib, numpy etc can be imported on Jupyter notebook. Could you guys help me on this? Many thanks in advance!

system.m.plot_slice('x', 50e-9) displays and returns figure object

A line like

system.m.plot_slice('x', 50e-9) (as in the standard problem 3 example http://oommfc.readthedocs.io/en/latest/ipynb/standard_problem3.html), will display the figure twice:

Once because the actual plot_slice code displays it (I think - haven't looked at the code yet), the second time because the plot_slice command returns a figure object.

If we write fig = system.m.plot_slice('x', 50e-9), then the figure is only displayed once (inside the notebook). But we could say

fig

in the next line, and that will display the figure.

I think my preference would be that

fig = system.m.plot_slice('x', 50e-9)

will not display the figure, but just return the figure object. If the user wants to see it, they can either not assign the return value, i.e.
system.m.plot_slice('x', 50e-9,0), or assign it and ask the notebook to represent it in the next line, i.e.

fig = system.m.plot_slice('x', 50e-9)
fig

The situation where the figure is displayed twice is unsettling. I shall call it a bug (although it is partly a design question).

mif templates

Instead of typing tcl syntax as strings in Python, we could use templates. This way we simplify the code.

More details: ubermag/discretisedfield#105 (comment)

Produce better error message if docker doesn't work

Example notebook to follow.

Can we find and display OOMMF log file on oommf failure?

In a situation like https://travis-ci.org/joommf/oommfc/builds/342456366#L1672, it might be useful to display the OOMMF log file, which gives an indication for what error OOMMF fails. In the particular example of this run on travis, it is likely that OOMMF failed because we use the wrong name for the DMI interaction in the mid file (the OOMMF C code has been updated, but is using the 'old' OOMMF binary that doesn't support the new extension yet).

While this situation should not occur, it will be very useful for similar changes and version conflicts in the future.