Documentation for installing OOMMF should be updated, because tk-dev, tcl-dev are required for its compilation.

• for code installed via pip, this should reflect the pip version

When OOMMF simulation is run in Docker container, we mount a shared directory between the container and host machine. All files that are created by Docker are write-protected for the host machine, which makes it difficult to modify or remove them.

At the moment, in all packages, we have:

url='https://github.com/joommf/joommfutil',
author='Computational Modelling Group',
author_email='[email protected]',

Should we maybe use joommf.github.io for url and joommf-users email?

For instance, __repr__ method in Exchange class should return Exchange(A=8.78e-12). Similarly, Hamiltonian and Dynamics classes are expected to return "a sum" of individual term representations. For example, Exchange(A=8.78e12) + Demag() + Zeeman(H=(0, 0, 1e6)).

I could not install tclsh from the instructions in the repository. I had to create a tclsh symbolic link:
cd /usr/bin; sudo ln --symbolic tcl8.6 tclsh

I also required the following environment variables, which were not documented:
OOMMF_TK_CONFIG=/usr/lib/x86_64-linux-gnu/tk8.6/tkConfig.sh
OOMMF_TCL_CONFIG=/usr/lib/x86_64-linux-gnu/tk8.6/tclConfig.sh
OOMMF_TK_INCLUDE_DIR=/usr/include/tk/
OOMMF_TCL_INCLUDE_DIR=/usr/include/tcl/

I am running Ubuntu 14.04, and installed tcl and tk from the tcl-dev and tk-dev packages in apt.

At the moment system.hamiltonian = Exchange(A) does not work, because Hamiltonian object is expected.

Quantity class should be implemented to represent material parameter constants, such as exchange energy constant, Dzyaloshinkii-Moriya energy constant, Gilbert damping, etc. The class should be, for example, able to:

• assign units to values,
• provide latex representation in Jupyter notebook.

Between energyterm.py and hamiltonian.py as well as between dynamicsterm.py and dynamics.py in micromagneticmodel package cross-imports exist. This might cause problems.

An abstract Field class should be created in a new repository, so that both finite difference and finite element fields can be derived from it.

An appropriate repository name would probably be discretisedfield (with British "s"), because this name is available in PyPI.

There is a lot of code repetition for checking the input arguments in classes as well as repetition when defining several different properties with essentially the same behaviour.

units and headers are attributes providing lists, but times is a method (need to call times() to get the data). To make this consisted, we could turn times into a property (which called get_times).

This issue follows the decision to abandon Python2 support #10.

It should not be possible to add multiple exchange or DMI energy objects to the Hamiltonian. This enhancement is to restrict physically meaningless models as well as not to take care of whether specific calculators support multiple exchange energies.

Having multiple Zeeman or Anisotropy energies can be physically possible, so this restriction at the moment should be made only for Exchange and Demag objects.

If OOMMF is not installed (or/and OOMMFTCL environment variable) does not exist, it should make a docker container from Docker Hub and run simulations in it.

Files are exchanged via shared directory.

Currently, in the TimeDriver classes, the saving of the magnetisation is hard coded. We need to expose the option to save the other fields that OOMMF allows. For each energy class, we can also save the field and the energy density. The syntax for this (with Oxs_UniformExchange as the example) is:

Destination archive mmArchive
Schedule Oxs_UniformExchange::Field archive Step 1
Schedule "Oxs_UniformExchange::Energy density" archive Step 1

replace Step with Stage/Done as necessary.

The inverted commas around the energy density part is needed because strings are first class citizens in Tcl, and the space gets misinterpreted otherwise.

Because of the inconsistencies between Python 2 and Python 3, the code gets more complicated and also testing becomes more difficult. This is mainly a problem with continuous integration and testing in multiple different Docker containers.

Should we rename attribute header to headers to be plural and in line with times and units?

Because the definitions of abstract methods cannot be accessed by tests, they should be ignored in the test coverage reports.

In order to test running OOMMF simulations inside docker on Travis, we need to enable docker to be run inside docker.

Arguments used to create a mesh should be renamed:

• cmin to p1
• cmax to p2
• d to dxdydz or cell

This issue is closely related to #2 and #12.

If eventually is decided that fidimag should use the finite difference Mesh, another arguments, such as periodicity should be added.

It should not be possible to set the time (t) and nsteps (n) on a Driver to negative values.

TimeDriver.drive currently accepts negative values without raising a ValueError and gets 'stuck' (nothing happens at all) when executed.

Should testing packages (pytest, codecov, coverage, nbval) be installed when our package is installed via pip?

For instance, Exchange should be imported as

import oommfc as oc
oc.Exchange(A)

This also applies to micromagneticmodel.

This will also simplify import statements in the code.

Maybe have stages, steps, and time at the left, followed by mx, my, mz, and maybe Hx, Hy, Hz, and the max_spin angles. Then show the other columns in alphabetical order.

See for example table in https://github.com/joommf/oommfc/blob/master/docs/ipynb/standard_problem4.ipynb (at the moment in output cell [16]).

Other constants such as elementary charge, Bohr magneton should be added to consts.

The OOMMFField class with its separate repository is derived from the finite difference Field class and only adds two methods for reading and writing OOMMF (.omf, .ohf) files. This functionality should be moved to the new discretisedfield repository.

This change is to make method names shorter.

At the moment, a system object contains system.dt which is a pandas dataframe and is created from the OOMMF .odt file.

The easiest and most obvious way of getting total and individual term energies is

system.total_energy()
system.exchange_energy()

which internally would read the pandas dataframe and return a value.

However, we want to have a clear hierarchy in the interface of what belongs to what. Also, what if we have multiple zeeman or anisotropy energies with different names... So, the most correct way of computing energies would be:

system.hamiltonian.energy()  # total energy
system.hamiltonian.exchange.energy()  # exchange energy

In a similar way, at the moment we access the parameters:

system.hamiltonian.zeeman.H
system.hamiltonian.exchange.A

The problem with this is that system.hamiltonian.exchange object should know about the dataframe which is an attribute of the system. This is not possible to solve in an elegant way. Two possibilities are:

1. We internally pass system down to exchange, so that exchange has an attribute e.g. memberof which would be system.
2. Another way, which would make the interface messy is to compute individual term energy as

system.hamiltonian.exchange(system)

I can imagine this would be the case if we implemented new micromagnetic code which would compute the energy (given m). For instance,

system.hamiltonian.exchange(m)

Any thoughts?

Derived classes should be instantiable and they are not abstract any more.

All setup.py files should be checked to make sure that we include all dependences.

oommfc.oommf.check() -> do tests to confirm that OOMMF can be found.
If we can call OOMMF (we may ask OOOMMF for its version number to check this), we could be silent.

If we cannot call OOMMF, we can print message with details:

• is OOMMTCL set? If so, to where. Does the path exist?
• are we attempting to use docker? If so, can we talk to the docker machine?

We could have an extra switch to raise an exception if OOMMF cannot be found (useful for automatic tests).

oommfc.test() should check if OOMMF/docker are on the machine and, only if they are, run the tests.

In order to allow interactive matplotlib plots in Jupyter notebooks, matplotlib.use("nbagg") should be used. However, if this command is in the python script, this causes problems with testing and plotting outside of Jupyter notebooks.

oommfc.oommf.version() -> return string with OOMMF version number

Field class is missing Jupyter notebook representation method.

Final term derived classes in micromagneticmodel should be instantiable. In other words, script method (previously called calculator_script) should raise 'NotImplementedError'.

In order to make code consistent, all latex strings that are returned for the representation in Jupyter notebooks should be private class properties.

Also, it should be possible for the user to obtain _latex_str in an appropriate format so that equations can be easily copied/pasted into reports, manuscripts.

After all related issues are solved, a UML diagram should be created.

Mesh class should be defined in the discretisedfield repository.

Using that class, an abstract mesh class with script method should be derived in micromagneticmodel.

This issue is closely related to issue #2 .

Object names should be valid Python variable names, not just any string.

Constants, such as mu0 are defined in micromagneticmodel. Somehow, they should be available in oommfc.

By checking whether

docker version

runs, we can check if docker is installed and running.

Current docker run command exits with 0 even when unit tests fail.

There is probably an additional flag for docker run.

At the moment, we have

import matplotlib
matplotlib.use("nbagg")

in __init__.py file(s) across packages. This works fine only when the code is run from the command line python3 filename.py or inside Jupyter notebook.

However, inside python3 or ipython kernel, we cannot import the package because nbagg is not supported.

Do we need a default backend? If yes, what it should be?

(If we do not have a default one, we get warnings when packages are imported across different platforms, issue001 in discretisedfield).

At the moment if OOMMF is installed on the host machine, it is run on the host. If not, it is run inside Docker. User does not have any control of this process and cannot decide where to run OOMMF.

It would be useful, especially for testing, to specify via interface, where to run OOMMF. However, it is not clear how that should be specified. The most natural place would be in drivers or in its drive method. For instance,

td = oc.TimeDriver()
td.where = "host"  # or "docker"
td.drive(system, t=1e-9, n=100)

or

td = oc.TimeDriver()
td.drive(system, t=1e-9, n=100, where="host")

Also what would be the better name instead of where?