GithubHelp home page GithubHelp logo

mailhexu / tb2j Goto Github PK

View Code? Open in Web Editor NEW
65.0 8.0 29.0 3.04 MB

a python package for computing magnetic interaction parameters

License: BSD 2-Clause "Simplified" License

Python 99.55% Shell 0.45%
dft heisenberg-model siesta wannier90 spin dynamics tight-binding

tb2j's Introduction

Python application Documentation Status Build Status Downloads

Description

TB2J is a open source python package for calculating the magnetic interaction parameters in Heisenberg models from DFT. It use the magnetic force theorem and take the local rigid spin rotation as a perturbation in the Green's function method.

The TB2J project is initialized in the PhyTheMa and Nanomat teams in the University of Liege.

The features include:

  • Calculates parameters in Heisenberg model, including isotropic exchange, anisotropic exchange, Dyzanoshinskii-Moriya interaction.
  • Can use the input from many DFT codes with Wannier90, e.g. Abinit, Quantum Espresso, Siesta, VASP, etc.
  • Can use input from DFT codes with numerical orbitals from Siesta, OpenMX and ABACUS.
  • Calculate magnon band structure from the Heisenberg Hamiltonian.
  • Generate input for spin dynamics/Monte Carlo codes MULTIBINIT.
  • Require only ground state DFT calculation.
  • No need for supercells.
  • Calculate magnetic interaction up to large distance.
  • Minimal user input, which allows for a black-box like experience and automatic workflows.
  • Versatile API on both the input (DFT Hamiltonian) and the output (Heisenberg model) sides.

For more information, see the documentation on https://tb2j.readthedocs.io/en/latest/

Dependencies

  • python (tested for ver 3.6)
  • numpy
  • scipy
  • ASE (atomic simulation environment)
  • matplotlib (optional) if you want to plot magnon band structure directly.
  • sisl (optional) for Siesta interface

Installation

pip install TB2J

Message:

  • We welcome contributions. If you would like to add the interface to other codes, or extend the capability of TB2J, please contact us! <mailhexu_AT_gmail_DOT_com>

tb2j's People

Contributors

adrybakov avatar antelmor avatar mailhexu avatar uagaro avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

tb2j's Issues

Discussion on the number of magnon bands

Hello, I would like to ask you a question about a problem when calculating magnon band structure. When I consider Jani and DMI in my calculation, why the number of bands drawn is three times the number of atoms and there are many splits? When Jani and DMI are not considered, the three bands of the same atom have the same value, so there are no splits, but when Jani and DMI are considered, the three values are different, but they are all drawn resulting in many bands, is this reasonable?
CrI3rotateandmerge.zip

ValueError: operands could not be broadcast together with shapes (4,4) (3,3)

I encountered an error, plz tell me how to solve it.

$ wann2J.py --spinor --groupby spin --posfile POSCAR --efermi -0.21 --kmesh 6 6 1 --elements Cr --prefix_spinor wannier90 --emin -5.3 --emax 2.21

TB2J version 0.7.4.5
Copyright (C) 2018-2020 TB2J group.
This software is distributed with the 2-Clause BSD License, without any warranty. For more details, see the LICENSE file delivered with this software.

Reading atomic structure from file ./POSCAR.
Reading Wannier90 hamiltonian: non-colinear spin.
Starting to calculate exchange.

Green's function Calculation started.
100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 100/100 [00:45<00:00, 2.22it/s]
Traceback (most recent call last):
File "/soft/anaconda3/envs/TB2J/bin/wann2J.py", line 186, in
run_wann2J()
File "/soft/anaconda3/envs/TB2J/bin/wann2J.py", line 181, in run_wann2J
orb_decomposition=args.orb_decomposition
File "/soft/anaconda3/envs/TB2J/lib/python3.6/site-packages/TB2J/manager.py", line 234, in gen_exchange
exchange.run(path=output_path)
File "/soft/anaconda3/envs/TB2J/lib/python3.6/site-packages/TB2J/exchange.py", line 775, in run
self.calculate_all()
File "/soft/anaconda3/envs/TB2J/lib/python3.6/site-packages/TB2J/exchange.py", line 727, in calculate_all
self.get_rho_atom()
File "/soft/anaconda3/envs/TB2J/lib/python3.6/site-packages/TB2J/exchange.py", line 583, in get_rho_atom
[np.trace(x) * 2 for x in pauli_block_all(tmp)])
File "/soft/anaconda3/envs/TB2J/lib/python3.6/site-packages/TB2J/pauli.py", line 131, in pauli_block_all
MI = (M[::2, ::2] + M[1::2, 1::2]) / 2.0
ValueError: operands could not be broadcast together with shapes (4,4) (3,3)

[Important] Theoretical Discussion

In the example of SrMnO3, if we additionally consider the Mn-O exchange interaction J in the TB2J software, what is different with the only considered Mn-Mn one. Assuredly, the J between Mn atoms is dominated, while the J between Mn-O is negligible. For most magnetic systems, it is reasonable to only consider the J between magnetic atoms. In this case, the calculated J between the total energy mapping and magnetic force method are consistent. However, if the exchange interaction J between the magnetic and ligand atoms is considerable. Is it credible when we only concern the J between magnetic atoms.

assigned_basis.txt

In every run of wann2J.py a file "assigned_basis.txt" is created outside of the TB2J_results directory (in the directory of the script`s execution to be exact). It comes from the function auto_assign_basis_name() defined in utils.py.

I tracked down calls of this function and it is called in several places, in particular:
manager.py (1)
manager.py (2)
manager.py (3)
manager.py (4)
manager.py (5)
Oiju.py
myTB.py
utest.py

And in every case it seems to me that appearance of the file itself is not desired.

Therefore, since appearance of this file is confusing, I suggest to change the behaviour of the code in that sense.

I see two simple solutions:

  • Solution1
    To redefine default value of write_basis_file from 'assigned_basis.txt' to None, then the file will appear only if it is desired, but not as a side effect.
  • Solution2
    To make it appear in the TB2J_results directory by changing the function auto_assign_basis_name() and it`s calls in a particular way.

I can open a pull request for either first or second solution, so the question is: which one do you prefer? Or do you plan to address this issue in a different way?

P.S. One more question, which came from this investigation: there is a number of unused imports in the code, do you keep them with a reason, or are they just left there historically?

Desired improvements

I hope that when calculating spin waves it can be changed to setting the coordinates of the K points yourself, instead of by high symmetry point names, because the positions of some points that one wants to calculate are not in the fields given.

TB2J to Vampire.UCF

dear developer,

I checked the VAMPIRE source code and Manual. (ver 5)

VAMPIRE offer 6 exchange interactions format

  • isotropic
  • vectorial
  • tensorial
  • normalised-isotropic
  • normalised-vectorial
  • normalised-tensorial

Manual say 'normalized' but 'normalised' is correct ;)

I checked double counting issue when calculate Tc.

(https://github.com/richard-evans/vampire/blob/4c9651daecc86c3e6b6df0c8055fcd9e89fd900c/src/exchange/energy.cpp)

please check line 102.

VAMPIRE spin hamiltonians are
Hexc

When I solve this problem, i get Tc=1038 K of Fe bcc
image

best regards,
Jun Gyu Lee

ask for help

Hello, I would like to know if Jani and DMI are taken into account in the latest version of TB2J when calculating the magnon band structure. When I perform the --no_Jani and --no_dmi operations under the TB2J_magnon.py command after calculating the task with abacus and generating the exchange.xml file with TB2J, I get no change in the magnon band structure. However, when I remove the parts about Jani and DMI from the exchange.xml file, the calculated magnon band structure has changed, I would like to know what is going on and whether these changes are reliable?

TB2J the choice of cell is impoartant?

Dear sir!
recently i got this beautiful software. I find taht the use of WFs from DFT codes can be used to generate J parameters. But i have one simple but important question:
it is need to get accurate J with primitive cell? even it is not the ground state? for example, a AFM strcuture need supercell. so when i calculate J with TB2j , do i need generate WFs using AFM supercell or primitivecell which must be FM?

thanks!

Desired improvements

I hope that when calculating spin waves it can be changed to setting the coordinates of the K points yourself, instead of by high symmetry point names, because the positions of some points that one wants to calculate are not in the fields given.

Error in lattice parameters

I would like to ask why the lattice structure in the exchange.out file obtained from TB2J calculations is so much different from the crystal structure in my input file, causing the interface software to not find the correct symmetry when detecting the exchange.out file. Does this mean that the exchange parameters are calculated with such a structure and is the result reasonable?

[ENH]: Code style

Hello!

Is there any code style in TB2J?

If no, then what do you think about adopting Black?

Best,
Andrey

Problem with translate_home_cell = .true.

Dear developers,

I just experience a problem using TB2J (Github version 0.3.5), on top of Wannier90.
If I add the line "translate_home_cell = .true." to the Wannier90, TB2J stops with the backtrace below.
This error disappear if I comment this line.

Green's function Calculation started.
Traceback (most recent call last): | (ETA: --:--:--)
File "/u/tnico/TB2J/bin/wann2J.py", line 4, in
import('pkg_resources').run_script('TB2J==0.3.5', 'wann2J.py')
File "/raven/u/system/soft/SLE_15/packages/x86_64/anaconda/3/2020.02/lib/python3.7/site-packages/pkg_resources/init.py", line 667, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/raven/u/system/soft/SLE_15/packages/x86_64/anaconda/3/2020.02/lib/python3.7/site-packages/pkg_resources/init.py", line 1470, in run_script
exec(script_code, namespace, namespace)
File "/u/tnico/.local/lib/python3.7/site-packages/TB2J-0.3.5-py3.7.egg/EGG-INFO/scripts/wann2J.py", line 154, in
File "/u/tnico/.local/lib/python3.7/site-packages/TB2J-0.3.5-py3.7.egg/EGG-INFO/scripts/wann2J.py", line 150, in run_wann2J
File "/u/tnico/.local/lib/python3.7/site-packages/TB2J-0.3.5-py3.7.egg/TB2J/manager.py", line 170, in gen_exchange
File "/u/tnico/.local/lib/python3.7/site-packages/TB2J-0.3.5-py3.7.egg/TB2J/exchange.py", line 567, in run
File "/u/tnico/.local/lib/python3.7/site-packages/TB2J-0.3.5-py3.7.egg/TB2J/exchange.py", line 521, in calculate_all
File "/u/tnico/.local/lib/python3.7/site-packages/TB2J-0.3.5-py3.7.egg/TB2J/exchange.py", line 326, in get_all_A
File "/u/tnico/.local/lib/python3.7/site-packages/TB2J-0.3.5-py3.7.egg/TB2J/exchange.py", line 296, in get_A_ijR
File "/u/tnico/.local/lib/python3.7/site-packages/TB2J-0.3.5-py3.7.egg/TB2J/pauli.py", line 133, in pauli_block_all
ValueError: operands could not be broadcast together with shapes (9,9) (10,10)

matrix multiplication seems incorrect

Dear Developers,
There are places in the code trying to do matrix multiplication with
np.einsum('ij, ji-> ij')
However, it seems that ('ij,ji->ij', A, B) is actually element-wise multiplication of A and B.T
the correct way should be
np.einsum('ij,jk', A, B)
which is matrix multiplication of A and B
or simply to use
t = self.get_Delta(iatom) @ Gij_up @ self.get_Delta(jatom) @ Gji_dn
is fine as commented out in the code

In my opinion, matrix multiplication instead of element-wise multiplication is what you want to do.
The results can be essentially different.

Problem in plotting magnon_band.pdf

Dear Developers,
Thank you very much for this nice code :-)

Here I have a problem about plotting [magnon_band.pdf] using [TB2J_magnon.py]
Attached is the magnon dispersion of BCC Fe.
When I use [v0.4.4.1], there is no problem.
However, when I use a higher version ([v0.6.0] and [v0.6.1]), the plot looks strange.

Here I used the same [exchange.xml] for the two cases.
The only difference is the effect of [TB2J_magnon.py --qpath GNPGHN] from the different version of TB2J.

Thanks :-)
With best regards,
Kyohoon

magnon_band_v0.4.4.1.pdf
magnon_band_v0.6.0.pdf

[ENH]: Test suite

Hello!

While making #37 I realised that there is no clear test suite for the TB2J.

If there is some, please correct me.

I propose the following strategy using pytest + hypothesis for the discussion:

  • Folder "utest" in the root folder (or other name with "test" in it)
  • Inside "utest" folder the files and folder repeat the structure of the "TB2J" folder from the root folder.
  • Each file and folder in the "utest" starts from the "test_"
  • Each file and folder in the "utest" contains unit tests for the corresponding functions and classes of the package.
  • Each function in the "utest" starts with "test_" and
  • Each class in "utest" starts with "Test"
  • Each class and function in the "utest" has the name of the class or function from the package for which it is written (if applicable).

With this strategy the tests can be run with the command from the root folder (after pip install pytest hypothesis):

pytest -s 

Example:

root/
├── ...
├── TB2J/
│   ├── file1.py
│   │   ├──> def function_1():
│   │   └──> class MyClass:
│   ├── submodule/
│   │   └── file2.py
│   │       └──> def function_2():
│   └── ...
├── utest/
│   ├── test_file1.py
│   │   ├──> def test_function_1_behaviour():
│   │   ├──> def test_function_1_raises():
│   │   └──> class TestMyClass:
│   ├── test_submodule/
│   │   └── test_file2.py
│   │       └──> def test_function_2():
│   └── ...
└── ...

P.S. An example of this strategy can be looked at in one of my repositories.

XYZ posfile

Dear developers,

It seems that at the moment it is possible to provide an apparently valid --posfile option with an XYZ file (supported by ASE).
However, this leads to a zero Cell parameter matrix, which lead to a singular matrix at some point in the code.

Probably this should be check.

Error when running the last step wann2j

Reading atomic structure from file ./POSCAR.
Reading Wannier90 hamiltonian: spin up.
Reading Wannier90 hamiltonian: spin down.
Starting to calculate exchange.

Traceback (most recent call last):
File "/beegfs/home/b00004/anaconda3/bin/wann2J.py", line 186, in
run_wann2J()
File "/beegfs/home/b00004/anaconda3/bin/wann2J.py", line 156, in run_wann2J
gen_exchange(path=args.path,
File "/beegfs/home/b00004/anaconda3/lib/python3.9/site-packages/TB2J/manager.py", line 98, in gen_exchange
exchange = ExchangeCL2(tbmodels=(tbmodel_up, tbmodel_dn),
File "/beegfs/home/b00004/anaconda3/lib/python3.9/site-packages/TB2J/exchange.py", line 72, in init
self.set_tbmodels(tbmodels)
File "/beegfs/home/b00004/anaconda3/lib/python3.9/site-packages/TB2J/exchangeCL2.py", line 30, in set_tbmodels
self.Gup = TBGreen(self.tbmodel_up,
File "/beegfs/home/b00004/anaconda3/lib/python3.9/site-packages/TB2J/green.py", line 92, in init
self._prepare_eigen()
File "/beegfs/home/b00004/anaconda3/lib/python3.9/site-packages/TB2J/green.py", line 156, in _prepare_eigen
self.evals, self.evecs = self._reduce_eigens(self.evals,
File "/beegfs/home/b00004/anaconda3/lib/python3.9/site-packages/TB2J/green.py", line 98, in _reduce_eigens
istart, iend = ts[0], ts[-1] + 1
IndexError: index 0 is out of bounds for axis 0 with size 0

I use similar structure, i have succussfully got the results. but at this time sth wrong

TB2J with vasp

Dear Developers,

I wanted to know if we can use TB2J with a combination of VASP+Wannier90.

Thanks,

Alex

illegal instrucion (core dumped)

dear developer,

I did a non-collinear calculation with epenmx for a unit cell of 12 atom. I encountered this problem with tb2j-openmx :

Loading from scfout file OK!
starting to calculate exchange.
Green's function calculation started.
Illegal instruction (core dumped)

These are the details of my pc:
memory 64 GiB
processor intel xeon(R) CPU E5-2620 v2 @ 2.10GHz * 24

How can I fix this problem?
Thank you in advance for your help

ask for help

thanks for inventing this good software
I have a question. When fitting Wannier, do we only require that the localization of magnetic atoms is good?
waiting for your answer

[BUG] Atoms named not as chemical symbols (ase crash)

When a wannier90 calculations are done with the atom labels, that are different from the chemical symbols (i.e. Fe1 and not Fe), the wann2J.py crashes. The deep source of the error with code examples is described here:
https://gitlab.com/ase/ase/-/issues/1448

Apparently, ASE does not consider this to be a bug, so I am writing about it here. Unfortunately, I can not share the input and output files at the moment. I may add a toy example this week, if necessary. To reproduce, one should name atoms in .win files as described here.

TB2J version: 0.8.1 and 0.7.7

Truncated line in documentation

* emin, emax, and nz: During the calculation, there is a integration :math:`\int_{emin}^{emax} d\epsilon` calculation. The emin and emax are relative values to the Fermi energy. The emax should be close to 0. It can be used to adjust the integration if the charge . The emin should be low enough so that all the electronic states that affect the magnetic interactions are integrated. The nz is the number of steps in this integration.

One of the sentences in the line above in the documentation is truncated. In particular, it's the following sentence: It can be used to adjust the integration if the charge .. What was supposed to be written here?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.