While plotting a band structure along the high-symmetry k-path K->Gamma-> Kp, I noticed that the k-path distances are not symmetrical around Gamma, which should not happen due to a hexagonal brillouin zone. Can you please suggest any solution for this issue?

Hi, I have been trying to plot 3D fermi surface using my PROCAR and OUTCAR from a VASP hybrid band structure calculation. Pyprocar.repair works fine. However, when I try pyrocar.fermi3D, it gives me the error shown below:

Plotting band 0
Traceback (most recent call last):
  File "/home/zccappr/.local/bin/procar", line 815, in <module>
    args.func(args)
  File "/home/zccappr/.local/bin/procar", line 120, in call_fermi3D
    kwargs = args.kwargs)
  File "/home/zccappr/.local/lib/python3.6/site-packages/pyprocar/scriptFermi3D.py", line 463, in fermi3D
    mapped_func,kpoint_matrix = mapping_func(kvector,eigen)
  File "/home/zccappr/.local/lib/python3.6/site-packages/pyprocar/scriptFermi3D.py", line 54, in mapping_func
    if len(bands[tot_cond]) != 0 :
IndexError: boolean index did not match indexed array along dimension 0; dimension is 304 but corresponding boolean dimension is 311

I tried it with different structures and for each I got the same error with a difference of 7 between the numbers in IndexError: boolean index did not match indexed array along dimension 0; dimension is 304 but corresponding boolean dimension is 311.

I am using pyprocar.fermi3D(PROCAR, OUTCAR, bands=-1, scale=1, mode='plain', st=False) Secondly, for some reason it is also finding the wrong number of ions. I have 24 ions in my POSCAR but it finds 25. I am attaching my PROCAR, OUTCAR, POSCAR and KPOINTS files.

PROCAR.zip OUTCAR.zip POSCAR.zip KPOINTS.zip

Thank you.

Hi Uthpala, The band unfolding is added. List of changes:

• procarunfold module added.
• scriptUnfold.py added.
• documentation (docx file, is it the right place?)
• I found the parser a bit slow so I put my simple version in as readFile2. From your comment, I see that there could be some problem with 1 atom case but I don't know why. I think the extensive use of re.findall() is guilty for the slowness, for large files it can cost minutes, or even hours to parse. Cheers, HeXu

I have run the "pyprocar.fermi2D('PROCAR-repaired', outcar='OUTCAR', st=True, energy=0.01, noarrow=False, spin=3, code='vasp')" The procar is repaired before fermi2D.

then after several mins error happens: Traceback (most recent call last): File "/beegfs/home/b00004/calculation-hcq/soc/2Dslice/soc/slice/py", line 4, in pyprocar.fermi2D('PROCAR-repaired', outcar='OUTCAR', st=True, energy=0.01, noarrow=False, spin=3, code='vasp') File "/beegfs/home/b00004/anaconda3/lib/python3.9/site-packages/pyprocar/scriptFermi2D.py", line 92, in fermi2D rec_basis = outcarparser.RecLatOutcar(outcar) File "/beegfs/home/b00004/anaconda3/lib/python3.9/site-packages/pyprocar/utilsprocar/utilsprocar.py", line 271, in RecLatOutcar recLat = np.array(recLat, dtype=float) ValueError: could not convert string to float: '0.000000000171.062194824'

PS. my vasp running is successful but PROCAR is large due to 200 atoms.

Can anyone help me?

Hi, as shown in the following full dependency graph of pyprocar, pyprocar requires numpy ==1.17.2, pyprocar requires matplotlib * (matplotlib 3.2.1 will be installed, i.e., the newest version satisfying the version constraint), and directed dependency matplotlib 3.2.1 transitively introduces numpy >=1.11.

Obviously, there are multiple version constraints set for numpy in this project. However, according to pip's “first found wins” installation strategy, numpy 1.17.2 (i.e., the newest version satisfying constraint ==1.17.2) is the actually installed version.

Although the first found package version numpy 1.17.2 just satisfies the later dependency constraint （numpy ==1.17.2), such installed version is very close to the upper bound of the version constraint of numpy specified by matplotlib 3.2.1.

Once matplotlib upgrades，its newest version will be installed, as pyprocar does not specify the upper bound of version constraint for matplotlib. Therefore, it will easily cause a dependency conflict (build failure), if the upgraded matplotlib version introduces a higher version of numpy, violating its another version constraint ==1.17.2.

According to the release history of matplotlib, it habitually upgrates Numpy in its recent releases. For instance, matplotlib #15645 upgrated Numpy’s constraint from >=1.11 to >=1.12, and matplotlib #15698 upgrated Numpy’s constraint from >=1.12 to >=1.15.

As such, it is a warm warning of a potential dependency conflict issue for pyprocar.

Dependency tree

pyprocar - 5.2.1
| +- ase(install version:3.19.1 version range:*)
| | +- matplotlib(install version:3.2.1 version range:*)
| | | +- cycler(install version:0.10.0 version range:>=0.10)
| | | | +- six(install version:1.14.0 version range:*)
| | | +- kiwisolver(install version:1.2.0 version range:>=1.0.1)
| | | +- numpy(install version:1.17.2 version range:>=1.11)
| | | +- pyparsing(install version:3.0.0a1 version range:>=2.0.1)
| | | +- python-dateutil(install version:2.8.1 version range:>=2.1)
| | +- numpy(install version:1.17.2 version range:*)
| | +- scipy(install version:1.4.1 version range:*)
| +- matplotlib(install version:3.2.1 version range:*)
| | +- cycler(install version:0.10.0 version range:>=0.10)
| | | +- six(install version:1.14.0 version range:*)
| | +- kiwisolver(install version:1.2.0 version range:>=1.0.1)
| | +- numpy(install version:1.17.2 version range:>=1.11)
| | +- pyparsing(install version:3.0.0a1 version range:>=2.0.1)
| | +- python-dateutil(install version:2.8.1 version range:>=2.1)
| +- mayavi(install version:4.6.2 version range:==4.6.2)
| +- numpy(install version:1.17.2 version range:==1.17.2)
| +- pyfiglet(install version:0.8.post1 version range:*)
| +- scikit-image(install version:0.16.2 version range:*)
| +- scipy(install version:1.4.1 version range:==1.4.1)
| +- seekpath(install version:1.9.5 version range:>=1.0)
| | +- future(install version:0.18.2 version range:>=0.15)
| | +- numpy(install version:1.17.2 version range:>=1.0)
| | +- spglib(install version:1.14.1.post0 version range:>=1.14.1)
| | | +- numpy(install version:1.17.2 version range:*)

Thanks for your help. Best, Neolith

My POSCAR:

azo
1.00000000000000
9.5670000000000002 0.0000000000000000 0.0000000000000000 -4.7835000000000001 8.2852650380099995 0.0000000000000000 0.0000000000000000 0.0000000000000000 40.0000000000000000 Mo S H C N O 18 35 10 13 2 2 Direct ...

If I tried pyprocar.kpath('POSCAR',40,True,'hpkot',1e-07,1e-05,-1.0)

Traceback (most recent call last): File "", line 1, in File "/home/noki/anaconda3/envs/procar/lib/python3.7/site-packages/pyprocar/scriptKpath.py", line 21, in kpath atoms = np.array(POSCAR[5].split()).astype(np.int) ValueError: invalid literal for int() with base 10: 'Mo'

It should change from 5 to 6 or not compatible for my POSCAR.

Dear Uthpala: Hi! I am now learning your great tool PyProcar. When I want to plot the fermi2D spin-texture, there is an error: --- ImportError: cannot import name '_ccallback_c' from 'scipy.lib' (C:\Users\user\AppData\Roaming\Python\Python37\site-packages\scipy_lib_init.py)

I have installed and upgrade the SciPy, but the error remains.

So, please, how can I solve this problem?

Hi I am trying to check how the DOS plot looks for a DFT calculation I did that was ended early due to a walltime issue on the supercomputer I have access to. At first I got an issue due to unclosed tags in the vasprun.xml file which makes sense, but after manually closing the necessary tags so the file could be parsed, I am getting an error that the self.data variable in vaspxml.py does not contain the key 'dos'.

Looking into this file I see that the lines 662 to 675 in the function parse_vasprun in the file vaspxml.py are all commented out, and on quick inspection this looks to be the only place where 'dos' string gets set as a key within the variable self.data. Are these lines supposed to commented out? Is the 'dos' key being set in another function and I am missing it?

I have resubmitted the DFT job so it will run to completion, but in the meantime I would like to see the DOS plots to see how the current unconverged results are looking while I wait for the DFT calculation to finish.

Thank you in advance for your help, and for your reference I have added a screenshot of the exact error message I see when I try to call the function dosplot from pyprocar. Please let me know any additional information you require from me.

Try it online

I mainly added one example notebook

examples/MoS2_QEv6.5/pyprocar.ipynb

I guess it should be easy to add similar notebooks for the other examples.

Hi,

I recently create the pyprocar conda forge package, now it is possible to install PyProcar via:

conda install -c conda-forge pyprocar

I was wondering if one of the core developers is interested in joining me in maintaining the package.

Best,

Jan

I am trying using the package to unfold a 9x9x1 supercell band, and I encountered the following error: self.procar.readFile2(self.fname, phase=True, ispin=ispin) File "/u/fs1/.local/lib/python3.6/site-packages/pyprocar/procarparser/procarparser.py", line 688, in readFile2 iband = int(ss[1]) - 1 ValueError: invalid literal for int() with base 10: '***'

I think this is due to the fact that the code does not realise that VASP does not write down the band index beyond 999. For example, my PROCAR looks like:

band 998 # energy -0.2155885 # occ. 0.00000000

ion s py pz px dxy dyz dz2 dxz dx2 tot 1 0.000 0.001 0.001 0.001 0.000 0.000 0.000 0.000 0.000 0.003 2 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.002 3 0.000 0.001 0.001 0.001 0.000 0.000 0.000 0.000 0.000 0.004 ....

band 999 # energy -0.19090405 # occ. 0.00000000

ion s py pz px dxy dyz dz2 dxz dx2 tot 1 0.000 0.000 0.002 0.000 0.000 0.000 0.000 0.000 0.000 0.003 2 0.000 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.000 0.002 3 0.000 0.001 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.002 ....

band *** # energy -0.18754690 # occ. 0.00000000

ion s py pz px dxy dyz dz2 dxz dx2 tot 1 0.000 0.000 0.001 0.001 0.000 0.000 0.000 0.000 0.000 0.003 2 0.000 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.000 0.002 3 0.000 0.000 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.002 ....

band *** # energy -0.17669861 # occ. 0.00000000

ion s py pz px dxy dyz dz2 dxz dx2 tot 1 0.000 0.003 0.001 0.001 0.000 0.000 0.000 0.000 0.000 0.006 2 0.000 0.001 0.001 0.000 0.000 0.000 0.000 0.000 0.000 0.002 3 0.000 0.002 0.001 0.000 0.000 0.000 0.000 0.000 0.000 0.004 ....

Could you please fix this bug? Thanks.

I have tried to install pyprocar using pip and conda both and in both the cases it is not showing the pyprocar.

At the end of the installation, I am getting this.

Installing collected packages: pyparsing Successfully installed pyparsing-3.0.9

Could you please have a look at it?

Hello developers, firstly many thanks for the amazing post processing scheme. I was trying to follow the tutorials to filter weighted KPOINTS from hybrid calculation. But I'm getting the following error- //File "hello.py", line 2 pyprocar.filter('PROCAR’,'PROCAR-filtered_kpoints’, kpoints=[2,3]) ^ SyntaxError: invalid syntax// What I'm doing wrong here/ how can I fix this ?

Hey, I am following the posted tutorial for plotting the orbitals of Np atom in my crystal structure.

the plots made by stack_orbitals mode does not show any F orbitals (only show s p d). can you please let me know how to correct this issue?

Thank you, Harindu

In plotting projected DOS contributions without showing the total DOS, I see that the vertical scale is not readjusted to be suitable for the projections. It is still referring to the total DOS.

So if my total DOS is at 100 units, while my projections is at 5-10 units, the projected DOS plots becomes hard to analyze (because too small compared to the graph size). What could we do in this case?

I use pyprocar version 5.6.5.

Dear PyProCar developers,

I encounter in my calculations that the amount of projected DOS, or DOS contribution from specific atom/orbitals is shown differently in magnitude when plotted with 'stack' and 'parametric_line' mode, respectively. I use version 5.6.5

In general, the overall shape and energy locations are similar, but the DOS amplitude contribution appear higher in 'stack' than in the parametric_line plots.

I check the tutorial page, and it seems that it is already seen here:

https://romerogroup.github.io/pyprocar/dos.html#mode-parametric-line https://romerogroup.github.io/pyprocar/dos.html#mode-stack

If we look at the oxygen p orbital contribution between -2.7 to -1.5 eV, for example, it is clearly shown that these contributions are higher in 'stack' mode as they almost cover the area under total DOS curve, while there is some uncovered space in the parametric_line mode.

I note that all O atoms are included in both plots, and. the other element contributions from Sr or V in the stack plot is negligible in this energy range, so they cannot explain this 0.8 - 1 a.u. DOS difference at -2.7 eV.

Because of this phenomena, I am seeing that if one uses the parametric line to plot separately all contributions from each element in a compound, say ABC, the individual contributions A+B+C won't sum up to match the total density of states curve. On the other hand, we can expect the individual contributions to sum up to the total DOS if we use the 'stack' modes.

May I know if this is expected? If so, what causes the parametric_line mode to show this different behavior? due to this finding, I do have doubts in the parametric_line mode. I hope you can help enlighten this problem for me.

Thank you. Alpin N. Tatan University of Tokyo