Adds Zeeman (external field) term to calculation

[alexhroom]

This PR makes it possible to provide an external magnetic field to the calculation. This is done via a new dataclass called MagneticField which contains a vector and a g_tensor list of arrays. Fixes #72

This PR also adds two examples:

• antiferro_ef.py, which is tutorial 29 for MATLAB spinW. This is the antiferro chain with added anisotropies and an external magnetic field applied.
• ferromagnet_gtensor.py, an example for a simple ferromagnetic chain with an explicit field and g-tensor specified.

[mducle]

Looks good. Some minor comments about the constants (bohr magneton).

[mducle]

We should probably use scipy.constants instead - the syntax is a bit unwieldy though:

MU_B = scipy.constants.physical_constants['Bohr magneton in eV/T'][0] * 1000

Also, scipy.constants is a bit of a big table and importing it takes ~1s - so it might be better for us to have our own table... I don't know, I'm 50-50 :/

[alexhroom]

I suggest we shelve that idea for now and if we need more constants in future we can switch to use scipy.constants?

[mducle]

One of the strengths of SpinW was that it had a lot of examples for users to see and copy, but at the moment, the examples here are very opaque and geared towards testing the code. We should decide:

• Should test examples be easily understood and useable by users as templates for their own calculations?
• Or should we have two sets of examples - a "raw" set as currently defined geared towards testing and another set of examples made for users?

@RichardWaiteSTFC @lucas-wilkins what do you think?

What prompted this was seeing the InternalClasses wrapper - and the fact that we have to pass different classes into the examples function depending on whether we want python or rust calculations - I think it's ok for this PR, and adds flexibility when we need to add other helper classes. But, ideally, for users they'd define the same Atoms, Couplings, MagneticFields and can then just set a use_rust or use_python flag, and an internal driver will pick the right classes (or would it be better to just use the Python classes in user facing applications and an internal converter to rust that is needed? @alexhroom what do you think?)

[alexhroom]

@mducle The impression I was working under is that we have the raw examples so that I can test the spinwave calculation routines while Lucas is still working on the API. Ideally, when the API is complete, these examples would be replaced with ones constructed using the user-facing classes and serve as both examples and test data, but right now they have to be written using internal classes because we don't have user-facing ones!

As far as I'm aware the plan when pySpinW is complete is that we have the user-facing classes, and then we have an internal routine that converts them to the arguments used by the spinwave calculation.

Maybe we should have an issue to put together an ADR on this?