Adding to_xarray method for Field object which returns field value as an xarray.DataArray.

1. Typically, the returned DataArray has four dimensions, namely x, y, z, and comp. The first three corresponds to geometry while the fourth dimension corresponds to the components of field. comp dimension has field.components as co-ordinates.
2. If the Field object is a scalar field, the comp dimension is 'squeezed' and the DataArray has only three dimensions corresponding to the geometry.
3. Instead of giving fourth dimension (i.e. comp) the name of the field, the name is assigned to the DataArray itself. The default name is 'field', but it can be changed with name parameter.
4. The units of the field can be set with units parameter. Units of geometry dimensions are set to mesh.attributes['unit'] if the attribute exists, otherwise set to 'm' (meter).

Execution times for 1M cells:

• Reading

mode   old    new   speedup
==== ======= ====== =======
bin4 1730 ms  21 ms   82
bin8 1860 ms  36 ms   52
text 4920 ms 401 ms   12

• Writing

mode    old    new   speedup
==== ======== ====== =======
bin4 63000 ms  56 ms   1125
bin8 64000 ms  84 ms    762
text 69000 ms 4510 ms    15

Filesizes are

• 2.9M for bin4
• 5.8M for bin8
• 15M for txt

Test

• field with mesh.n = (100, 100, 10)
• creation of a new field with mesh.n = (10, 10, 10) and passing the old field to value

Performance improvement:

• old implementation (using that the field is callable): ~ 6.5 s
• new implementation (interpolation done by xarray): ~ 5 ms

@swapneelap This is probably the first use case for your new method.

@lang-m I've made the initial critical changes we discussed and added tests.

There are two main issues that I have at the moment that it would be good for you to look at if you have time:

• [x] Typesystem - as I am not familiar with the type system I've not too sure how to do the correct types for things like units and pmin etc. this is causing some errors in the tests. e.g. allowing complex numbers
• [x] html representation - this is causing some tests to fail now that I have changed the repr to include pmin and pmax rather than p1 and p2. I don't know all the html code off of the top of my head so I'm hoping it will be a quicker fix for you but let me know if not.

Dear Ubermag team, I encountered a problem in simulating a multilayer structure. I don't know what it means to define a three-dimensional value in field. I don't know if I rely on this value and norm=Ms to determine the initial magnetic moment distribution of this material. There is a non-magnetic layer in the multilayer structure that I simulate. How should I define its value for this non-magnetic region? I define the value of field through the following figure function, but when I am creating field, the program reports an error. How can I solve this problem to achieve the desired results?

Hi there, Have you considered integrating mumax-view as a tool to visualize 3D fields ? Compared to k3d, it is faster as it is compiled to wasm and has better shaders out of the box. I'm not sure if it's possible to embed it as a notebook widget in a similar way to k3d. Also it would require a few changes to be called through python. I doubt this would be an easy task but k3d can be insanely slow even on top-end workstations ( single-threaded js can only go so far ). I also think mumax-view is a beautifully written software that deserves more attention and it might shine as part of the Ubermag framework.

After merging #86 we have to review __repr__ for Region, Mesh, Field, and FieldRotator. Representation strings are difficult to read because of bad formatting and relatively much information.

Probably the most convenient way for accessing individual components of a vector field is to have a method which returns a scalar field. The question is how this method should be named and called. Maybe

field.component("x")

Also, we can allow the argument to be 0, 1, 2

Should Field class be able to set its value with another field like:

f1 = Field(mesh, dim=3, value=(0, 0, 1))
f2 = Field(mesh, dim=3)

f2.value = f1

Or f2.value = f1.value is already sufficient?

• renamed: dim -> nvdim
• renamed: components -> vdims
• removed: coordinate_field
• removed: typesystem decorator

Todo

• [x] check doctests
• [x] update docstrings

Simplifies array creation and mathematical operations with fields.

This had been implemented previously but I had initially removed it when rewriting the as_array function.

Determining the array for callable or dict for value is more complex and therefore not anymore done automatically. Instead, the numpy default (np.float64) is used by default. Furthermore, these types of value only occur during creation by the user where a different dtype can be easily specified (so we don't have any issues with wrong data types during operations on fields).

updates:

• github.com/pre-commit/pre-commit-hooks: v4.3.0 → v4.4.0
• github.com/pycqa/isort: 5.10.1 → 5.11.4
• github.com/nbQA-dev/nbQA: 1.5.3 → 1.6.0
• github.com/PyCQA/flake8: 5.0.4 → 6.0.0
• github.com/psf/black: 22.10.0 → 22.12.0

At present the use of atol and rtol in the method is a bit confusing. Moreover, the method fails if one of the points in the two meshes that are equal to or close to 0.0. We can refactor it to take into account the exponent of the cell dimensions, for example.