We currently only use a small subset of the tests in micromagnetictests because we only import a few test.

In oommfc we import all tests (from micromagnetictests.calculatortests import *). It would be good if we could use the same here.

Hello @samjrholt and @lang-m, I read the other day on the Mumax3 docs that one can add multiple Zeeman fields. I wanted to use this in one of the simulations, and hence, I have opened a PR for the same.

@SeregaKR suggested adding support for RunWhile in mumax3c in #81. We have a few questions on this topic.

1. What conditions (and how many) does mumax3 support in RunWhile?
2. Are any of these conditions already present in any way in micrimagneticmodel?
3. Is it worth making this part of the TimeDriver rather than a separate driver?
4. Can mumax3 combine multiple conditions with logic operators?

We do in general like the following suggestion:

td = mc.<...Driver>()
td.drive(system, condition="MaxTorque > 0.005")

At present we use just one repetition for the PBC. Is this enough for all the cases? When should one use more and should we let the user decide this?

Incorporate the ability to add text directly to the mx3 file as a catch all for methods that are not currently implemented and advanced users.

• Add code to mumax3c
• Add Ms to mx3 files
• Add region_relator to system
• Informative error message
• Use mesh to create slices

Review runner in mumax3c and oommfc to remove potential code duplication.

For example, at present, DMI energy is not added to the table. Refactor the driver_script to take such issues into account.

Hi,
thanks for creating this great tool.

I think found an issue when there's a nan Ms set in the output .mx3 file:

Msat.setregion(2, nan) 

This line:

Thanks!

Users currently don't notice that certain features (e.g. spin currents) are not supported and not added to the mx3 files. It would be good if we could raise NotImplementedErrors for the features that are currently missing.

In the ubermag meta-package we execute all unit tests from all subpackages. We generally cannot assume that mumax3 is installed on a system. We could have a second fixture to skip all tests if mumax3 is not available.

Add functionality to allow micromagneticdata to work with mumax3c
ubermag/micromagneticdata#28

• Change to using mumax3 regions
• Relate ubermag regions to mumax3 regions
• Deal with energies between mumax3 regions
  - [ ] Check available energies in mumax3
• Compatible with micromagneticmodel

• Which equation is used for DMI type Dind (interfacial Cnv type)? [My guess would be it is equivalent to Cnv_z in OOMMF].
• Can we fix the spins in one of the regions?
• Can we save multiple steps for mindriver, relaxdriver?
• What type of data can we use in compute?
• Can there be a need to have multiple subregions in the Ms = 0 part (outside the sample)?
• Proper definition of boundary conditions.

• Update repository metadata
• Update devtools
• Update Ubermag

Mumax3 expects a vector field for J, OOMMF a scalar field for u (hard-coded in x direction). mumax3c should check whether the field u is a scalar or vector field. For best compatibility I would convert a scalar field to a vector field and add 0 for the additional two directions.

• Time-dependent energy terms
• Check compute for mumax3
• Can Ms=0 all be the same region?
• Check available energies in mumax3
• PBC more than 1 repeat
• Spatially dependent Zeeman Field
• Magnetoelastic coupling
• Advanced running e.g. RunWhile, steps, and SetSolver
• Fixed Magnetisation Subregions
• Output step mumax3 equivilent?
• Add evolvers, i.e. spin currents
• Global DMI and subregions of A

Scripts do not finish running if there are too many unique Ms values.

• #7
• #43
• #15
• #14
• #16
• #9
• #18
• Document and comment code
• Complete all TODO in driver.py
• #28
• #27
• #26
• #22
• Output table mumax3
• Output file types
• #35
• #40
• #41

Cleanup in the end

• Use master branch from micromagnetictests