[ENH]: Function to dump tb2j files or a universal yaml/hdf5

[oashour]

What are you missing?

Hi Andrey,

I just discovered rad-tools last week, and I'm a huge fan. I want to use it as part of the backend of a package I'm working on to compute Magnon-dark matter interactions (similar to how I'm using phonopy for phonon-DM interactions).

Spin Hamiltonians can come from many sources. For example, they could be defined via the rad-tools Python API from parameters fitted to experiments, using parameters computed from magnetic force theorem in FLEUR, or an exchange.out TB2J file with W90/SIESTA, etc. It would be nice to have a unified format. That way, the users only have to provide one file that can be loaded to populate a SpinHamiltonian object, completely agnostic to its source (similar to a properly generated phonopy.yaml file, if you're familiar with phonopy).

What would you like to have?

I see that rad-tools has a template feature. It seems that it only lists the neighbor pairs so that the information would be incomplete regarding the exchange/SIA/DMI parameters, unit cell, atom positions, etc. Since rad-tools can already read TB2J files, it might be useful to be able to dump them as well. That's one option, but I'm personally not a fan of text files, and it would be better to use a format better suited for numerical data.

YAML would be one option, but I'm also not a fan of using that format for numerical data (which is not what it was designed for). I am partial to HDF5: it was designed for scientific computing/numerical data, and the tools to read and write it are ubiquitous, mature, and easy to use (e.g., h5py). Further, many first principles packages are (slowly) moving towards HDF5 already (e.g., VASP and Quantum ESPRESSO). It's not human-readable, but the dump_spinham_txt function works beautifully for such files.

Do you want to add anything?

I'd like to know your thoughts regarding this. I would be 100% interested in implementing this myself, and it shouldn't be too difficult. (Although it would have to wait until after the March Meeting...) Let me know what you think and what design guidelines you'd suggest for this.

OS

Linux

RAD-tools version

0.8.12

Git commit hash

No response

[adrybakov]

Hello Omar!

I am very glad to hear that you like the package!

I will answer to you message in details during next week. Shortly: I agree that something needs to be done about the formats for Spin Hamiltonians.

Cheers!

[adrybakov]

Hi again!

Future plans

First of all we are planning to release a package dedicated to magnons soon (in a span of one or two months), which takes the approach and design of RAD-tools and just make it better, more detailed and dedicated to the magnons, starting from slightly more general Spin Hamiltonian.

I believe, that is will be better to implement the output/input functions for different sources of the Spin Hamiltonians out there in the wild. In fact there is a strict and flexible specification of the human-readable file, which describe a generic Spin Hamiltonian in this new code as well as the routines for the TB2J-style inputs and soon for GROGU inputs. I think it will be wise to add interface for the FLEUR program, that you've mentioned as well.

By design this new code simply reads the Spin Hamiltonian from any file and offer convenient (I hope) python API to manipulate it as one pleases or to compute magnon-related things from it.

Spin Hamiltonian (input) data

That is to say about the Spin Hamiltonian data. There are two options here as you mentioned as well: to go for the .txt file, which is accessible to any person, even if they do not know programming very well or to go for the binary format as the HDF5, that you've mentioned. From the perspective of the developer binding this new code with HDF5 will be easy, since it is heavily relies on the numpy already. However, my feeling is that a .txt format should exist anyways, cause it makes the package and it's capabilities accessible to the wider audience.

So I really see two options to proceed:

• Keep interchangeable .txt and HDF5 files.
  • Cons:
    • Need to maintain a pair of load/dump functions for each data object (i.e. dump_spinham_txt and dump_spinham_hdf5, ...)
    • The user needs to keep track of which .txt file corresponds to a particular HDF5 file.
    • ...
  • Pros
    • Separate the human- and machine- readable part, adding more rigidity to the input source (arguable)
    • ...
• Keep only .txt file with a very well defined standard.

  • Cons

    • Heavier that the binary format for the storage of large models.
    • ...

  • Pros

    • Only one file is sufficient to keep track to (from the user side)
    • Can be checked and created with a bare eye
    • ...

I've briefly discussed this issue with the author of TB2J here.

Unifying the format.

This is the idea I want to implement as well, however it will require the coordinated efforts of the developer of different Spin Hamiltonian-based programs in order to design the file format, that suits for everyone. An alternative is to have one program, which can interface with any other and unify the API (one of the design choices for this new program, that we are writing). Personally, I think that at some point some unification will be done.

Dispersion (output) data

Another issue is how to present the results of the magnon simulation, say magnon dispersion data. The HDF5 will be handy here from the developer point of view, but the argument about the accessibility of the results of the calculations arises here as well. At the moment rad-tools outputs the data as plain test, but I am open to suggestions in the new program. Can you describe your user experience with RAD-tools? What I mean is: how do you interact with it? Only through the console scripts or within the interactive python console? Which kind of data are interesting for you? Magnon dispersion? Do you proceed the input files by yourself? Or would you prefer the unified pythonic interface to the lot?

I would be glad to hear your perspective!

Best,
Andrey