My Community

Yes I understand there should be 3 spin channels x y and z. x and y are zero in this case. When I try x or y <> 0 I get a BUG error which I posted separatly. Maybe that is related?

The other strange thing is that AFM runs seem OK, so it does seem that the problems are related to spin.
Ron

Hello!

I have some exciting updates regarding your issue: we found that the at least part of the origin lies not inside VASP but rather in the post-processing of py4vasp. Depending on the py4vasp version the behavior of calc.dos.plot("Nd") differs:

1. In py4vasp 0.10.0 and 0.10.2 (the two latest release versions of py4vasp) the DOS of noncollinear calculations is not yet fully supported. In these versions py4vasp is not yet aware that the individual contributions in the HDF5 file are total, m_x, m_y and m_z. Hence, there is also no default choice if you use the selection Nd (as in calc.dos.plot("Nd")). If there is no default choice py4vasp used to sum over all contributions (which makes sense in the "up/down"-case), therefore what we will get in our plots is total + m_x + m_y + m_z (which of course is nonsense). Therefore, a workaround is to explicitly select the total dimension like this

   Code: Select all

   calc.dos.plot("total(Nd)")
   # or
   calc.dos.plot("total(Nd(f))")
   

   As you already noticed the other components cannot be selected manually because they are unknown to this py4vasp versions and hence are not assigned a label.

2. In the current master version of py4vasp on Github (use "pip install ." as explained here) this issue has already been fixed and you can use Nd as selection without the additional total() around it because total is the default selection, for example:

   Code: Select all

   calc.dos.plot("Nd")
   # or
   calc.dos.plot("Nd(f)")
   

   will give you the desired plots. In addition you can access the m_x, m_y and m_z components with these selection aliases:

   Code: Select all

   m_x  ...  sigma_x, x, sigma_1
   m_y  ...  sigma_y, y, sigma_2
   m_z  ...  sigma_z, z, sigma_3
   

   For example like this:

   Code: Select all

   calc.dos.plot("sigma_x(Nd(f))")
   

Now, this seems to resolve the issue on our side, there are no more partial DOS curves above the total DOS when using py4vasp. However, I wonder if this is also the solution in your case... how did you create the original figures you sent us? Were you also using py4vasp to get the data and then used a different plotting tool? Could you please test whether the proposed workaround works for you as well? Thank you!

One extra remark concerning the DOSCAR file: I noticed that in the partial DOS parts the f-states are not written as additional columns after the d-states as expected. Instead there seems to be an incorrect newline character after the last d-state dz2(mz), see here (I added the column labels and numbers):

This is a bug and will be fixed in the next VASP release.

All the best,
Andreas Singraber

Thank you very much! py4vasp works now! I was using pyprocar to get the pretty plots, and it was reading the total dos from the xml file, so maybe there is still a problem there?

Ron

Hello Ron!

Great that it works now for py4vasp! I had a look at the vasprun.xml file and also tried pyprocar. I could not load your vasprun.xml for some reason, so I took a similar one from my tests (is attached to this post).

I manually extracted the fx3 component (last column) of the two Nd atoms from the vasprun.xml file. Then, I plotted the sum over both atoms of the fx3 contribution together with the total DOS, this is what I get when I zoom in to a certain region (the energy given here is around 3-4 eV above the Fermi energy):

Then, I produced the same plot with py4vasp which reads vaspout.h5 instead of the XML output and the result is similar:

Finally, if I try to get the same plot from pyprocar (v6.5.0) I get this result:

Here, I used this line to create the figure:

efermi=10.168568
pyprocar.dosplot(dirname="./", mode="stack", elimit=[13-efermi,14.5-efermi], fermi=efermi, spins=[0], items=dict(Nd=[15]), colors=['royalblue'])

I am not sure if this is entirely correct but as far as I can see the spins=[0] should get me the total component and items=dict(Nd=[15]) should correspond to the fx3 specific f-state contribution (see here, fx3 is an abbreviation for fx(x2-3y2)).

I played around a bit with settings and found that

• The blue curve does not seem to correspond to the actual data. It rather looks like some curve smoothing went wrong.

• This is also visible when I switch to mode="stack_orbitals", see here:

  stack_orbitals.png

  Sometimes I actually get the overflow warning you can see in the screenshot which is another hint at some post-processing issue.

• Not setting spins=[0] seems to correspond to spins=[0,1,2,3] and gives a different plot (with similar artefacts). So I guess also in pyprocar the default is to sum over all spin components?

• The spikes for my data seem to be similar to the ones you had in your initial figures:

  dos_spikes.png

Ultimately, I believe that there are some post-processing steps in pyprocar (maybe smoothing, rescaling) which seem to lead to these spiking issues. This could be due to a bug in the post-processing or due to unexpected (maybe faulty) data in the XML file. I could not find anything suspicious in the data itself but I have not checked all partial DOS data, just the one I was plotting (maybe the different components are mixed in the post-processing and there is an issue with another component). It may be worth contacting the pyprocar developers and making them aware of this issue.

All the best,
Andreas Singraber