Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

elk support? #144

Open
recohen opened this issue Apr 12, 2024 · 42 comments
Open

elk support? #144

recohen opened this issue Apr 12, 2024 · 42 comments

Comments

@recohen
Copy link

recohen commented Apr 12, 2024

I tried a simple dos with elk and get the below. But when I look at your parser page I don't even see elk.
Yet pyprocar is still listed on the elk web site

Very confused.

Thank you for any help,

Ron

pyprocar.dosplot(
code='elk',
mode='plain',
fermi=0.3568473976,
dirname="./")

ValueError Traceback (most recent call last)
Cell In[22], line 1
----> 1 pyprocar.dosplot(
2 code='elk',
3 mode='plain',
4 fermi=0.3568473976,
5 dirname=data_dir)

File /central/home/recohen/cohen_env/lib/python3.11/site-packages/pyprocar/scripts/scriptDosplot.py:278, in dosplot(code, dirname, mode, orientation, spins, atoms, orbitals, items, fermi, fermi_shift, elimit, dos_limit, savefig, labels, projection_mask, ax, show, print_plot_opts, **kwargs)
274 elif orientation[0].lower() == 'v':
275 orientation = 'vertical'
--> 278 parser = io.Parser(code = code, dir = dirname)
279 dos = parser.dos
280 structure = parser.structure

File /central/home/recohen/cohen_env/lib/python3.11/site-packages/pyprocar/io/parser.py:26, in Parser.init(self, code, dir)
23 self.code = code
24 self.dir = dir
---> 26 self.parse()

File /central/home/recohen/cohen_env/lib/python3.11/site-packages/pyprocar/io/parser.py:60, in Parser.parse(self)
57 self.ebs.bands += self.ebs.efermi
59 if self.dos:
---> 60 self.dos.energies += self.dos.efermi
61 return None

ValueError: non-broadcastable output operand with shape (500,) doesn't match the broadcast shape (4,1,16,2,500)
@lllangWV
Copy link
Member

Hey,

sorry for the issue! Recently, we changed it so the fermi energy has to be given the DensityOfStates class to initialize. I forgot to update the elk code.

I pushed the update to GitHub so clone the repository from there to have the updates. Here are the commands for that:

pip uninstall pyprocar
git clone [email protected]:romerogroup/pyprocar.git
cd pyprocar
pip install .

I will try to get this in the Pypi version as soon as possible. There are some further additions to the elk interface I would like to add before updating PyPi.

code = "elk"
mag_type = ["non-spin-polarized","spin-polarized-colinear","non-colinear"][1]
data_dir = os.path.join(PROJECT_DIR,'data','examples',"SrVO3",code,mag_type, 'dos')
HARTREE_TO_EV = 27.211386245988
pyprocar.dosplot(
code=code,
mode='plain',
fermi=0.3218543102*HARTREE_TO_EV,
dirname=data_dir)

image

Here are the bands as well:

code = "elk"
mag_type = ["non-spin-polarized","spin-polarized-colinear","non-colinear"][1]
data_dir = os.path.join(PROJECT_DIR,'data','examples',"SrVO3",code,mag_type, 'ebs')

pyprocar.bandsplot(
code=code,
mode='plain',
spins=[0,1],
elimit=[-10,10],
fermi=0.3218543102*HARTREE_TO_EV,
dirname=data_dir)
image

Logan Lang

@recohen
Copy link
Author

recohen commented Apr 18, 2024 via email

@recohen
Copy link
Author

recohen commented Apr 21, 2024 via email

@recohen
Copy link
Author

recohen commented Apr 21, 2024 via email

@lllangWV
Copy link
Member

Hey!

sorry for the late reply, I only have a couple of times a week to work on pyprocar. I looked into the issue, without going into details, it had to do with how the main parser got the DOS and Structure object.

This density of states looks a little strange with the giant peak near -5eV. I am just curious what does the band structure look like?

Here are the plots for the density of states for different modes:

pyprocar.dosplot(
                code=code,
                mode='parametric',
                orbitals=[4,5,6,7,8],
                # elimit=[-2,2],
                clim =[0,1],
                fermi=0.2561435077*HARTREE_TO_EV,
                dirname=data_dir)

image

pyprocar.dosplot(
                code=code,
                mode='parametric_line',
                orbitals=[4,5,6,7,8],
                # elimit=[-5,5],
                clim =[0,1],
                fermi=0.2561435077*HARTREE_TO_EV,
                dirname=data_dir)

image

pyprocar.dosplot(
                code=code,
                mode='stack_orbitals',
                # elimit=[-5,5],
                fermi=0.2561435077*HARTREE_TO_EV,
                dirname=data_dir)

image

pyprocar.dosplot(
                code=code,
                mode='stack_species',
                orbitals=[4,5,6,7,8],
                # elimit=[-5,5],
                fermi=0.2561435077*HARTREE_TO_EV,
                dirname=data_dir)

image

pyprocar.dosplot(
                code=code,
                mode='overlay_orbitals',
                # elimit=[-5,5],
                fermi=0.2561435077*HARTREE_TO_EV,
                dirname=data_dir)

image

pyprocar.dosplot(
                code=code,
                mode='overlay_species',
                orbitals=[4,5,6,7,8],
                # elimit=[-5,5],
                fermi=0.2561435077*HARTREE_TO_EV,
                dirname=data_dir)

image

Logan Lang

@lllangWV
Copy link
Member

I forgot to mention, I pushed these updates to Git Hub repo, so get the updated version from there.

Logan Lang

@recohen
Copy link
Author

recohen commented Apr 25, 2024 via email

@recohen
Copy link
Author

recohen commented Apr 25, 2024 via email

@lllangWV
Copy link
Member

Hey!

We require users to specify the Fermi energy to maintain a consistent functional interface across various DFT codes. Our goal is for dosplot and bandsplot functions to have uniform arguments for all DFT codes, differing only in the code argument. However, there are challenges in standardizing the Fermi energy across different DFT codes.

For instance, with VASP, the Fermi energy in the bands or density of states directory is not the self-consistent Fermi energy, which is located in a different directory. This complicates maintaining a uniform interface.

While ELK naturally sets the Fermi energy to 0, solving this issue, we initially decided to standardize the interface by requiring all users, regardless of the DFT code, to specify the Fermi energy.

Thinking about this more, I am exploring alternative solutions that could exempt users from specifying the Fermi energy when it is available in the same directory used by bandsplot or dosplot. This would be the case for Quantum Espress and ELK.

I'll see what I can do, and let you know!

@recohen
Copy link
Author

recohen commented Apr 25, 2024 via email

@lllangWV
Copy link
Member

For the overlay_orbtial not displaying the f orbitals. It should include f orbitals

image

@recohen
Copy link
Author

recohen commented Apr 25, 2024 via email

@recohen
Copy link
Author

recohen commented May 29, 2024 via email

@recohen
Copy link
Author

recohen commented May 29, 2024 via email

@recohen
Copy link
Author

recohen commented May 31, 2024 via email

@lllangWV
Copy link
Member

Hey Ron,

I'll take a look! Hopefully, I can get to it today, but if not the next couple days I will.

Also, I don't understand what you
were saying about VASP needing two directories. It seems to me that the
Fermi level and DOS are in the same directory.

What I was referring to is if you compare the OUTCAR file when you run a non-self consistent to the OUTCAR file of a self-consistent file. They are not guaranteed to be the same. I have personally, noticed this in some calculations I have performed. Ideally, the Fermi energy in a non-self-consistent calculation should be very close to that of the self-consistent calculation if the charge density is well-converged and if the same k-points and smearing methods are used. However, there can be slight differences due to the different treatment of electron density updates.

This is not a problem in other codes because they have a system to retain the self-consistent fermi energy in subsequent non-self-consistent calculations.

Logan

@recohen
Copy link
Author

recohen commented Jun 3, 2024 via email

@lllangWV
Copy link
Member

lllangWV commented Jun 3, 2024 •
edited
Loading

Hey Ron,

I am sorry it slipped my mind. I'm taking a look at it now. Could you also send me the POSCAR file too, I can't plot without it.

I am having some problems with pyprocar and VASP for a spin-orbit
spin-polarized where only one spin is plotted. I seem to see two spin
projections in the PROCAR file but cannot get them to plot.

So for a spin-orbit calculation in vasp, it will automatically turn the LNONCOLINEAR flag on, so you should only see one spin. This is because there is there is no definition of spin-up or spin-down in noncolinear calculations. What you see in the PROCAR is the projected magnetizations. You can find the exact definition here PROCAR at the bottom of the page.

The blocks represent the following:

  1. The first set is the total (absolute magnetization)
  2. The second is the x-projection of the spin
  3. The third is the y-projection
  4. The third is the z-projection

When you are dealing with a non-colinear calculation in pyprocar you can specify which projection you would like to see with the following.

In this plot, the color scale represents the contribution of the d-orbitals of the first atom to the total magnetization

atoms=[0]
orbitals=[4,5,6,7,8]
spins=[0]
pyprocar.dosplot(
code='vasp',
mode='parametric',
fermi=5.5962,
atoms=atoms,
orbitals=orbitals,
spins=spins,
dirname=data_dir)

Changing spins=[1] would represents the contribution of the d-orbitals of the first atom to the x-projection magnetization.
Changing spins=[2] would represents the contribution of the d-orbitals of the first atom to the y-projection magnetization.
Changing spins=[3] would represents the contribution of the d-orbitals of the first atom to the z-projection magnetization.

# of k-points:   90         # of bands:  128         # of ions:   14

 k-point     1 :    0.00000000 0.00000000 0.00000000     weight = 0.00195312

band     1 # energy  -27.58781017 # occ.  1.00000000
 
ion      s     py     pz     px    dxy    dyz    dz2    dxz  x2-y2  fy3x2   fxyz   fyz2    fz3   fxz2   fzx2    fx3    tot
    1  0.469  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.469
    2  0.469  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.469
    3  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    4  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    5  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    6  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    7  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    8  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    9  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   10  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   11  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   12  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   13  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   14  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
tot    0.941  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.941

    1 -0.000 -0.000 -0.000  0.000  0.000  0.000 -0.000  0.000 -0.000 -0.000  0.000  0.000 -0.000 -0.000  0.000  0.000 -0.000
    2  0.000 -0.000  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000 -0.000  0.000  0.000  0.000
    3 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
    4 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
    5  0.000 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    6  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    7  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    8 -0.000  0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
    9  0.000  0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   10  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   11 -0.000 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
   12 -0.000  0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
   13  0.000 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   14 -0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
tot    0.000 -0.000 -0.000  0.000 -0.000  0.000  0.000  0.000  0.000 -0.000  0.000  0.000 -0.000 -0.000  0.000  0.000  0.000

    1 -0.000  0.000 -0.000  0.000  0.000 -0.000  0.000  0.000  0.000  0.000 -0.000  0.000 -0.000 -0.000  0.000  0.000 -0.000
    2  0.000 -0.000 -0.000 -0.000 -0.000  0.000 -0.000 -0.000 -0.000 -0.000 -0.000 -0.000 -0.000 -0.000  0.000 -0.000  0.000
    3 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
    4 -0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
    5  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    6  0.000 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    7  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    8 -0.000  0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
    9  0.000  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   10  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   11 -0.000  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
   12 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
   13 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000 -0.000
   14  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
tot   -0.000 -0.000  0.000  0.000  0.000  0.000 -0.000  0.000 -0.000 -0.000 -0.000  0.000 -0.000 -0.000  0.000 -0.000 -0.000

    1  0.469  0.000 -0.000  0.000  0.000 -0.000  0.000 -0.000  0.000  0.000 -0.000 -0.000 -0.000  0.000 -0.000 -0.000  0.469
    2  0.469  0.000 -0.000  0.000  0.000 -0.000  0.000 -0.000  0.000 -0.000 -0.000  0.000 -0.000 -0.000 -0.000  0.000  0.469
    3  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    4  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    5  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    6  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    7  0.000 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    8  0.000 -0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
    9  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   10  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   11  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   12  0.000  0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   13  0.000 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
   14  0.000 -0.000 -0.000 -0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000  0.000
tot    0.941  0.000 -0.000  0.000  0.000 -0.000  0.000 -0.000  0.000  0.000 -0.000 -0.000 -0.000 -0.000 -0.000  0.000  0.941

Logan Lang

@recohen
Copy link
Author

recohen commented Jun 21, 2024 via email

@ahromero
Copy link
Collaborator

ahromero commented Jun 21, 2024 via email

@recohen
Copy link
Author

recohen commented Jun 21, 2024 via email

@recohen
Copy link
Author

recohen commented Jun 21, 2024 via email

@recohen
Copy link
Author

recohen commented Jun 21, 2024 via email

@lllangWV
Copy link
Member

Hey Ron!

Thank you so much for this. It has been a while, but I was stuck doing other things. So now, if something is ferromagnetic, how would one see the DOS for up and down total or along z with spin-orbit? I seem to be seeing only the majority spins. Maybe I am not understanding something major. Thank you so much.

If your calculation is a collinear spin-polarized one (without spin-orbit coupling), you can use the spins keyword argument. spins=[0] corresponds to spin up, and spins=[1] corresponds to spin down.

For calculations that include spin-orbit coupling (which implies non-collinear spins), you would still use the spins keyword argument. In non-collinear spin calculations, spins=[0] plots the spin density magnitude, while spins=[1,2,3] corresponds to spins oriented along the $S_x$, $S_y$, and $S_z$ directions, respectively.

Regarding the error:

AttributeError: np.complex_ was removed in the NumPy 2.0 release. Use np.complex128 instead.

It appears that NumPy updated their methods. This is an easy fix. In our code, we use np.complex to handle the phase factor of the projections, which occurs when LORBIT > 11 is set. Currently, we only use these phase factors for band unfoldings, so you can set LORBIT = 11 and still plot the spin projections.

I apologize I can't fix this immediately as I am away from my main computer this weekend, but I will get to it on Monday!

Logan Lang

@recohen
Copy link
Author

recohen commented Jun 23, 2024 via email

@recohen
Copy link
Author

recohen commented Jun 24, 2024 via email

@lllangWV
Copy link
Member

Hey Ron,

I am back to my my main computer and looking into the issue now! I just checked, the new version of numpy was literally released last week, so that explains why I have not seen this error before. A temporary fix would be to install pyprocar, then uninstall and reinstall numpy with an older version.

I am showing you what I normally do when I install pyprocar. I usually like to create anaconda virtual environment to make sure the dependencies are right.

conda create -n pyprocar_6.1.10 python==3.8
conda activate pyprocar_6.1.10

pip install pyprocar
pip uninstall numpy
pip install numpy==1.26.4

I am going to update, the way we handle these dependencies. Currently we just grab the most updated version, but this method is obviously not going to work. I'll push the updated version later today.

Logan Lang

@recohen
Copy link
Author

recohen commented Jun 24, 2024 via email

@lllangWV
Copy link
Member

I am just curious, I have a few questions.

How do you install pyprocar? Is it by pip install pyprocar or do you clone the repository

git clone [email protected]:romerogroup/pyprocar.git
cd pyprocar 
pip install .

When you say you are editing the file, are you editing the version in located in your site-packages inside your virtual environment or the file in the main pyprocar directory pyprocar/pyprocar/io/vasp.py?

@recohen
Copy link
Author

recohen commented Jun 24, 2024 via email

@lllangWV
Copy link
Member

I now understand why the editing did not work.

When you install a package with pip install . while using a virtual environment (e.g., venv), the pyprocar module is copied to venv/Lib/site-packages/pyprocar. Consequently, the code execution uses the version located there. Any changes made in the main repository will not be reflected in the venv/Lib/site-packages/pyprocar version. This means you would need to run pip install . every time you make changes in the repository, which is quite inconvenient. I used to follow this approach for a long time!

A better solution is to use pip install -e . (editable/development mode). This tells the virtual environment to reference the code in the main repository instead of venv/Lib/site-packages/. Now, any changes made in the repository will be immediately reflected when you run the code.

Hope this helps!

Logan Lang

@recohen
Copy link
Author

recohen commented Jun 24, 2024 via email

@recohen
Copy link
Author

recohen commented Jun 24, 2024 via email

@recohen
Copy link
Author

recohen commented Jun 24, 2024 via email

@lllangWV
Copy link
Member

went back to the older numpy and the core runs now. But I am still having problems. I have a spin-polarized (w SO) system, but when I plot the dos using spins=[3] I still get only positive dos—not a spin density.
Also, it seems I get the same thing whether I use spins=[0], spins=[2], or spins=[3], yet the moment is along z.

In spin-orbit (SO) calculations, it is expected to see only positive densities of states (DOS) because noncollinear calculations do not differentiate between spin-up or spin-down. When plotting with mode='plain', you should see identical plots for different spins settings ([0] or [1]), since they all represent the same DOS. For a clearer differentiation, use mode='parametric'. Here, differences between the various spins settings ([0], [1], [2], or [3]) can be observed, particularly in how the magnitude and the x, y, z projections of spin density are displayed using the color scale.

OK—it seems one needs to set dos_limit to be a range like [-10,10]. I didn't find this in the manual or website examples. Ron

You're correct, and I apologize for the oversight. The need to set dos_limit manually was not documented when it was introduced in dosplot. I'll make sure to add this information. Thank you for pointing it out!

Logan Lang

@recohen
Copy link
Author

recohen commented Jul 9, 2024 via email

@lllangWV
Copy link
Member

lllangWV commented Jul 9, 2024

Hi Ron,

No worries at all—I'm happy to answer any questions you have!

Regarding your question on what to expect for a ferromagnetic material with spin-orbit coupling and magnetic moment along the z-axis:

You should observe the density of states (DOS), which will consistently be positive. This outcome is due to the nature of spin-orbit calculations, where there isn't a distinction between spin-up or spin-down. Consequently, the DOS remains positive as it represents the only spin channel.

Concerning your second question on whether you should see both positive and negative DOS for spins=3 and spins=0 or only positive values:
You should only see positive numbers on the y-axis for both. Here’s why:

  • spins=3 corresponds to the z projection of the magnetization.
  • spins=0 represents the total magnetization projection.

The distinction between spins=[0] and spins=[3] appears in parametric mode. With spins=[3], the z projection can exhibit both positive and negative values, which should be reflected on the colorbar. Conversely, for spins=[0], since the total magnetization can only take positive values, the colorbar should only display positive values.

It's essential to differentiate between spin channels and spin projections:

  • A spin channels refer to the ways electron spins contribute to the overall electronic properties of a material. They will unique density of states (i.e. their own energies and DOS values)
  • Spin projections are the measurements of the components of the spins along a specific axis.

Here are the different cases.

  • In non-spin-polarized calculations, there is one spin channel and consequently one spin projection.
  • In spin-polarized calculations, two spin channels exist, leading to two corresponding spin projections.
  • In calculations involving spin-orbit or noncollinear magnetic arrangements, there is one spin channel, but it can be represented by four spin projections corresponding to that channel.

In our package we use spins keyword to handle both the spin_channel and spin_projection determination since we can determine which of the above case based on the calculation. Honestly, maybe it would be more beneficial explicitly differentiate between these two in the package. I would have check with other developers if they would be alright with this.

I hope this clears up any confusion!

Best regards,
Logan Lang

@recohen
Copy link
Author

recohen commented Jul 9, 2024 via email

@recohen
Copy link
Author

recohen commented Jul 9, 2024 via email

@lllangWV
Copy link
Member

lllangWV commented Jul 9, 2024 via email

@recohen
Copy link
Author

recohen commented Jul 9, 2024 via email

@lllangWV
Copy link
Member

lllangWV commented Jul 9, 2024

I apologize for any confusion. It looks like there's a misunderstanding on how stack_species and the spins=3 setting interact in our code.

The stack_species feature is designed to visually represent the contribution of atomic orbitals to the total density of states (DOS). We achieve this by normalizing the atomic projections based on the total projection, and then scaling these to match the total DOS. Here's how we implement this in our code (see plotter/dos_plot.py lines 495-501):

dos_projected = self.dos.dos_sum(atoms=atoms,
                                        principal_q_numbers=principal_q_numbers,
                                        orbitals=orbitals,
                                        spins=spin_projections)
x = self.dos.energies
y = (dos_projected[ispin]  / dos_projected_total[ispin] ) * dos_total[ispin]

This portion of the code correctly handles the scaling for non-spin-polarized and spin-polarized cases. However, when dealing with component projections in spin-orbit scenarios (like with spins=3), this situation can't really map on since the projections values can take negative values.

At the moment I can not think of a way to quickly fix this. I need to talk to other developers about this.

Also here is a discussion on the meaning of the projection value that I thought is good. It might be useful

Logan Lang

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@recohen @ahromero @lllangWV