Closed hongyi-zhao closed 2 years ago
It's of course possible to interface SpaceGroupIrep to other TB/DFT codes.
In fact, we have given the interface to VASP, i.e. the function getBandRep
, to obtain the little group irreducible representations (LGIR) of bands via the tool vasp2trace. If fact, interface to other DFT codes is also possible as long as the trace.txt file is obtained, as mentioned in the paper
irvsp
does the same thing with getBandRep
. The differences lie in 3 points:
irvsp
integrates the function of vasp2trace
because they are both developed by ZJ Wangirvsp
gives the LGIR labels of BCS (Bilbao Crystallographic Server) convention, while getBandRep
gives the ones in BC convention.irvsp
works only with standard BCS cell, while SpaceGroupIrep
can convert non-BC cell to BC cell via 'convTraceToBC
or autoConvTraceToBC
and then uses getBandRep
to determine LGIR.In fact, we have given the interface to VASP, i.e. the function
getBandRep
, to obtain the little group irreducible representations (LGIR) of bands via the tool vasp2trace.
If so, I think it's better to name it getBandRepVASP
for disambiguation, or add a function parameter to distinguish different interface code names.
If fact, interface to other DFT codes is also possible as long as the trace.txt file is obtained, as mentioned in the paper
Do you mean: as long as the trace.txt
file corresponding to specific DFT codes are obtained, the function getBandRep
can be used directly without any code modification in the existing implementation mechanism?
As you pointed out in the above paper, currently, the SpaceGroupIrep
works through the trace.txt
file generated by a slightly modified version of the original vas2trace
. OTOH, though ZJ Wang group also supplied codes to compute the irreducible representations of states in PW-based ab-initio packages and the (electronic or phononic) tight-binding Hamiltonian; the trace package to compute the traces of electronic states, is a dedicated post-processing program for VASP, and I think, it must be modified accordingly before it can be used by other DFT/TB codes.
Some additional remarks and questions:
So, I'm still no sure if SpaceGroupIrep
has also implemented all the features as described above, for example, pos2aBR (* converting PPOSCAR to POSCAR_std *)
and solve eBR/aBR (* using tqc.data *)
.
qeirreps
, which is an open-source program for Quantum ESPRESSO to compute irreducible representations of Bloch wavefunctions. Furthermore, I also noticed the following description here:
To get the list of high-symmetry k-points for each space group, one should access the CheckTopologialMat
and download the program named vasp2trace.
As described in README.pdf of vasp2trace, the k-points are listed in the file max_KPOINTS_VASP.
For the nscf calculation, one should specify the k-points as listed in max_KPOINTS_VASP.
It formed an impression on me that the vasp2trace
tool can be used by different DFT codes without much modification, presumably as you described two-lines modification in your paper. Frankly speaking, I am not sure whether my above understanding is correct.
In fact, we have given the interface to VASP, i.e. the function
getBandRep
, to obtain the little group irreducible representations (LGIR) of bands via the tool vasp2trace.If so, I think it's better to name it
getBandRepVASP
for disambiguation, or add a function parameter to distinguish different interface code names.
In principle, getBandRep
interfaces directly with the trace.txt file, not VASP.
If fact, interface to other DFT codes is also possible as long as the trace.txt file is obtained, as mentioned in the paper
Do you mean: as long as the
trace.txt
file corresponding to specific DFT codes are obtained, the functiongetBandRep
can be used directly without any code modification in the existing implementation mechanism?
Yes, you are right.
As you pointed out in the above paper, currently, the
SpaceGroupIrep
works through thetrace.txt
file generated by a slightly modified version of the originalvas2trace
. OTOH, though ZJ Wang group also supplied codes to compute the irreducible representations of states in PW-based ab-initio packages and the (electronic or phononic) tight-binding Hamiltonian; the trace package to compute the traces of electronic states, is a dedicated post-processing program for VASP, and I think, it must be modified accordingly before it can be used by other DFT/TB codes.
Yes, vasp2trace have to be modified accordingly before it can be used by orther DFT/TB codes. However, I think maybe it's more direct to write a XXX2trace ab initio for other DFT/TB codes, because different DFT codes use different format to store their Bloch wavefunctions and symmetry operations. What vasp2trace does includes mainly three things: (1) Read the Bloch wavefunctions from DFT results. (2) Transform the Bloch wavefunctions (rotation and translation given by a SG symmetry {R|v} ) (3) For degenerate energy bands, calculate the trace of {R|v}: \sum_i=1^d < psi_i | {R|v} psi_i >
Some additional remarks and questions:
- All ZJ Wang group's current work is using crystallography database provided by the Bilbao Crystallographic Server (BCS) as a reference standard.
Yes, they have partnership with the BCS developers and can obtain the original data of BCS.
- ZJ Wang Group also developed the library for irreducible representation computation, which is also based on BCS, and can be linked by various DFT packages, such as VASP, Quantum espresso, Siesta, Abinit, ELK, Wien2k.
For compiled language such as fortran, it's easy to make a .a static lib file. However it seems impossible to do this for mathematica, at least I don't know how to do. However, OTOH, SpaceGroupIrep originally is a database and toolset and can be considered as a lib in mathematica language.
- A general workflow for using irvsp is as follows:
- prepare your POSCAR file ...
- phonopy --symmetry --tolerance 0.01 -c POSCAR
- pos2aBR ( converting PPOSCAR to POSCAR_std )
- cp POSCAR_std POSCAR
- do vasp calculations ...
- irvsp -sg ...
- solve eBR/aBR ( using tqc.data )
So, I'm still no sure if
SpaceGroupIrep
has also implemented all the features as described above, for example,pos2aBR (* converting PPOSCAR to POSCAR_std *)
andsolve eBR/aBR (* using tqc.data *)
.
There is no fixed workflow to use SpaceGroupIrep because it is a database and toolset and different people may have different purposes to use it. For example, one can use it to assit studing the representation theory of space group, especially using the BC book. One can use the multiplication of SG elements to analyze SG symmetries. One can easily obtain little group or k-star at any k for any SG. One can check the LGIR table of any k in any SG. One can calculate the direct product of full SGIR's. One can get the correspondence between BCS and BC conventions. And one can determine the LGIR viagetBandRep
function.
As for determining the LGIR, the general workflow is:
getBCsymmetry.py -f POSCAR -p 0.001 -o
to generate a BC-standard POSCAR_6.vasp filevasp2trace
to calculate the trace.txt filereadVasp2trace
to get the trace datagetBandRep
to obtain the LGIRs from the trace dataOr
vasp2trace
to calculate the trace.txt filereadVasp2trace
to get the trace dataconvTraceToBC
for autoConvTraceToBC
convert the trace data to those conforming to the BC conventiongetBandRep
to obtain the LGIRs from the converted trace dataAs for solving eBR, this function is not yet realized at present. However, it's definitely possible to do this based on SpaceGroupIrep.
- ZJ Wang Group also developed a great web user interface with a style similar to BCS, which aggregates all topological band representation calculation tools they've developed so far, as shown below:
Yes, it's a great web user interface. This is also in our plan.
- There has been developed a package named as
qeirreps
, which is an open-source program for Quantum ESPRESSO to compute irreducible representations of Bloch wavefunctions.
Yes, I noticed this.
Furthermore, I also noticed the following description here:
To get the list of high-symmetry k-points for each space group, one should access the CheckTopologialMat and download the program named vasp2trace. As described in README.pdf of vasp2trace, the k-points are listed in the file max_KPOINTS_VASP. For the nscf calculation, one should specify the k-points as listed in max_KPOINTS_VASP.
It formed an impression on me that the
vasp2trace
tool can be used by different DFT codes without much modification, presumably as you described two-lines modification in your paper. Frankly speaking, I am not sure whether my above understanding is correct.
In my opinion, vasp2trace may be modified substantially to work for orther DFT codes. As mentioned above, different DFT codes use different formats to store their Bloch wavefunction and symmetry operations. If one is not clear about the underlying codes relating to wavefunctions of a DFT program, it's not easy to do the modification.
What vasp2trace does includes mainly three things: (1) Read the Bloch wavefunctions from DFT results. (2) Transform the Bloch wavefunctions (rotation and translation given by a SG symmetry {R|v} ) (3) For degenerate energy bands, calculate the trace of {R|v}: \sum_i=1^d < psi_i | {R|v} psi_i >
Thank you for pointing this out. There is already a Python package which provides a general calculation process to generate the trace.txt
file without restricting users to a specific DFT program. See my following comment for more detailed information.
One can easily obtain little group or k-star at any k for any SG.
In your paper, the concept of k-star is neither defined nor described in detail. This may not have any difficulty for those who are familiar with crystallographic group theory, but it should be a concept that needs to be understood first for beginners. So, I add the relevant stuff below for learners' reference based on the explanation in Group Theory Application to the Physics of Condensed Matter by Mildred S. Dresselhaus, Gene Dresselhaus, Ado Jorio:
OTOH, I also noticed the paper Wave vector substar group in reciprocal lattice space and its representation, which defined the wave vector substar group as follows:
I'm not sure if you've had proper research and consideration in this regard.
Another similar concept: Laue groups or Laue class correspond to some specific centrosymmetric crystallographic types of point groups and their subgroups.
- All ZJ Wang group's current work is using crystallography database provided by the Bilbao Crystallographic Server (BCS) as a reference standard.
Yes, they have partnership with the BCS developers and can obtain the original data of BCS.
We must admit that the level of scientists and technical teams behind BCS is world-class.
4. ZJ Wang Group also developed a great web user interface with a style similar to BCS, which aggregates all topological band representation calculation tools they've developed so far, as shown below:
Yes, it's a great web user interface. This is also in our plan.
While great, it's not necessarily the best choice for all scenarios at any time, which is why the famous ICSD supplies several access options to customers:
5. A general workflow for using irvsp is as follows:
- prepare your POSCAR file ...
- phonopy --symmetry --tolerance 0.01 -c POSCAR
- pos2aBR ( converting PPOSCAR to POSCAR_std )
- cp POSCAR_std POSCAR
- do vasp calculations ...
- irvsp -sg ...
- solve eBR/aBR ( using tqc.data )
So, I'm still no sure if
SpaceGroupIrep
has also implemented all the features as described above, for example,pos2aBR (* converting PPOSCAR to POSCAR_std *)
andsolve eBR/aBR (* using tqc.data *)
.There is no fixed workflow to use SpaceGroupIrep because it is a database and toolset and different people may have different purposes to use it. For example, one can use it to assit studing the representation theory of space group, especially using the BC book. One can use the multiplication of SG elements to analyze SG symmetries. One can easily obtain little group or k-star at any k for any SG. One can check the LGIR table of any k in any SG. One can calculate the direct product of full SGIR's. One can get the correspondence between BCS and BC conventions. And one can determine the LGIR via
getBandRep
function.As for determining the LGIR, the general workflow is:
* Use `getBCsymmetry.py -f POSCAR -p 0.001 -o` to generate a BC-standard POSCAR_6.vasp file * Use POSCAR_6.vasp to do vasp calculation
Basically, in the steps described above, what irvsp
does is equivalent to what you do based on SpaceGroupIrep
. So, the getBCsymmetry.py
script can do something similar to pos2aBR
, except that the former uses BC book as the standard and the latter uses BCS
as the reference.
In my opinion, vasp2trace may be modified substantially to work for orther DFT codes. As mentioned above, different DFT codes use different formats to store their Bloch wavefunction and symmetry operations. If one is not clear about the underlying codes relating to wavefunctions of a DFT program, it's not easy to do the modification.
In fact, there is another excellent job in this field, i.e, the Python based irrep
package, which also follows the notation specification used by Bilbao Crystallographic Server (BCS), as the authors state in their paper:
Moreover, our code follows the same notation as the popular Bilbao Crystallographic Server (BCS) [44]
to identify the IRs, which avoids confusion coming from the lack of an official
standard notation, especially for spin-orbit coupled systems.
Unlike vasp2trace
and qeirreps
, this package is the only code that does not restrict the user to a single DFT program, as described in the article below:
Currently, it has interfaced with vasp
, abinit
, espresso
, and wannier90
, as shown below:
$ git clone https://github.com/stepan-tsirkin/irrep.git stepan-tsirkin/irrep.git
$ cd stepan-tsirkin/irrep.git
$ pyenv shell datasci
$ pip install .
$ irrep --help | egrep -i -- '-code '
-code [vasp|abinit|espresso|wannier90]
As for determining the LGIR, the general workflow is:
* Use `getBCsymmetry.py -f POSCAR -p 0.001 -o` to generate a BC-standard POSCAR_6.vasp file * Use POSCAR_6.vasp to do vasp calculation * Use `vasp2trace` to calculate the trace.txt file * Use `readVasp2trace` to get the trace data * Use `getBandRep` to obtain the LGIRs from the trace data
Or
* Use any primitive cell to do vasp calculation * Use `vasp2trace` to calculate the trace.txt file * Use `readVasp2trace` to get the trace data * Use `convTraceToBC` for `autoConvTraceToBC` convert the trace data to those conforming to the BC convention * Use `getBandRep` to obtain the LGIRs from the **converted** trace data
Let's consider the following case: Use any primitive cell to do a non-VASP, for example, quantum espresso calculation.
In this case, can I use SpaceGrouplrep
to determine the LGIR using the following workflow?
irrep
package to calculate the trace.txt file;readVasp2trace
to get the trace data;convTraceToBC
to convert the trace data into those conforming to the BC convention;
Or as an alternative method, we can first generate the POSCAR file using the quantum espresso/pwscf output, say, by the following tools:
ase
's convert
sub-command, and see the following lists for its supported formats related to question discussed here:
$ ase info --formats |egrep -i 'vasp|espresso'
espresso-in [rw/single, ext=pwi]: Quantum espresso in file
espresso-out [r/multi, ext=out|pwo]: Quantum espresso out file
vasp [rw/single, ext=poscar, glob=*POSCAR*|*CONTCAR*]: VASP POSCAR/CONTCAR
vasp-out [r/multi, glob=*OUTCAR*]: VASP OUTCAR file
vasp-xdatcar [rw/multi, glob=*XDATCAR*]: VASP XDATCAR file
vasp-xml [r/multi, glob=*vasp*.xml]: VASP vasprun.xml file
Then use autoConvTraceToBC
to do the trick.
getBandRep
to obtain the LGIRs from the converted trace data.Regards, HZ
2. Use
irrep
package to calculate the trace.txt file;
In principle you are right.
But the key step is 2, i.e. generating trace.txt using irrep
correctly. irrep
has to do, for QE, the same things that vasp2trace
does for VASP.
But the key step is 2, i.e. generating trace.txt using
irrep
correctly.irrep
has to do, for QE, the same things thatvasp2trace
does for VASP.
This is exactly the aim of the irrep
package, as described here:
OTOH, Check Topological Mat. routine of Bilbao Crystallographic Server works based on vasp2trace or irvsp:
So, we can conclude that the generated trace.txt by irrep
is completely compliant with the specification implemented in vasp2trace or irvsp.
Note: The source code of vasp2trace, described on Check Topological Mat., corresponds to src_trace_v1.tar.gz
, which is designed for the VASP calculations with ISPIN=1, as stated here:
See here for a related discussion.
So, we can conclude that the generated trace.txt by
irrep
is completely compliant with the specification implemented in vasp2trace or irvsp.
I don't think it can be concluded arbitrarily that the trace.txt
by irrep
is the same with that by vasp2trace
without sysmatic test.
Especiall, the trace.txt
files generated by vasp2trace
and irvsp
may be different. And the one used by getBandRep
should be that generated by vasp2trace
, not by irvsp
. This has been emphasized in my paper:
I checked the (self-explanatory) trace.txt
file which includes the corresponding specification, and the Python functions defined in irrep
to write trace.txt
. There are two functions with the same name write_trace
defined in irrep
, which are combined to generate trace.txt
.
One is defined in bandstructure.py as follows:
def write_trace(
self,
degen_thresh=1e-8,
kpnames=None,
symmetries=None,
):
"""
Generate `trace.txt` file to upload to the program `CheckTopologicalMat`
in `BCS <https://www.cryst.ehu.es/cgi-bin/cryst/programs/topological.pl>`_ .
Parameters
----------
degen_thresh : float, default=1e-8
Threshold energy used to decide whether wave-functions are
degenerate in energy.
kpnames : list, default=None
Labels of maximal k-points at which irreps of bands must be computed.
If it is not specified, only traces will be printed, not irreps.
symmetries : list, default=None
Index of symmetry operations whose description will be printed.
"""
f = open("trace.txt", "w")
f.write(
(
" {0} \n"
+ " {1} \n" # Number of bands below the Fermi level # Spin-orbit coupling. No: 0, Yes: 1
).format(self.getNbands(), 1 if self.spinor else 0)
)
f.write(
self.spacegroup.write_trace()
)
# Number of maximal k-vectors in the space group. In the next files
# introduce the components of the maximal k-vectors))
f.write(" {0} \n".format(len(self.kpoints)))
for KP in self.kpoints:
f.write(
" ".join(
"{0:10.6f}".format(x)
for x in self.spacegroup.refUC.dot(KP.K)
)
+ "\n"
)
for KP in self.kpoints:
f.write(
KP.write_trace(degen_thresh, symmetries=symmetries, efermi=self.efermi)
)
The other is defined in kpoint.py as follows:
def write_trace(self, degen_thresh=1e-8, symmetries=None, efermi=0.0):
"""
Write in `trace.txt` the block corresponding to a single k-point.
Parameters
----------
degen_thresh : float, default=1e-8
Threshold energy used to decide whether wave-functions are
degenerate in energy.
symmetries : list, default=None
Index of symmetry operations whose traces will be printed.
efermi : float, default=0.0
Fermi-energy. Used as origin for energy-levels.
Returns
-------
res : str
Block to write in `trace.txt` with description of traces in a
single k-point.
"""
if symmetries is None:
sym = {s.ind: s for s in self.symmetries}
else:
sym = {s.ind: s for s in self.symmetries if s.ind in symmetries}
res = (
"{0} \n"
+ " {1} \n" # Number of symmetry operations of the little co-group of the 1st maximal k-vec. In the next line the position of each element of the point group in the list above.
# For each band introduce a row with the followind data: (1) 1+number of bands below, (2) dimension (degeneracy) of the band,
# (3) energy and eigenvalues (real part, imaginary part) for each symmetry operation of the little group (listed above).
).format(len(sym.keys()), " ".join(str(x) for x in sym))
char = np.vstack([self.symmetries[sym[i]] for i in sorted(sym)])
borders = np.hstack(
[
[0],
np.where(self.Energy[1:] - self.Energy[:-1] > degen_thresh)[0] + 1,
[self.Nband],
]
)
char = np.array(
[char[:, start:end].sum(axis=1) for start, end in zip(borders, borders[1:])]
)
E = np.array(
[self.Energy[start:end].mean() for start, end in zip(borders, borders[1:])]
)
dim = np.array([end - start for start, end in zip(borders, borders[1:])])
IB = np.cumsum(np.hstack(([0], dim[:-1]))) + 1
res += (
"\n".join(
(" {ib:8d} {d:8d} {E:8.4f} ").format(E=e - efermi, d=d, ib=ib)
+ " ".join("{0:10.6f} {1:10.6f} ".format(c.real, c.imag) for c in ch)
for e, d, ib, ch in zip(E, dim, IB, char)
)
+ "\n"
)
return res
The second function is called by the first to write in trace.txt
the block corresponding to a single k-point Parameters, and the rest of the content in trace.txt
is written by the first function before calling the second function.
As you can see, the above two functions are defined exactly according to the (self-explanatory) trace.txt
file format.
Regards, HZ
The format of trace.txt
file is only a necessary condition to be used by getBandRep
.
Another issue is that the rotation matrices used, especially the SU(2) spin rotation matrix, have to be the same with vasp and vasp2trace.
Even if both the above two points are fulfilled, there is another requirement that the code can not do additional process other than calculate the trace. An example is irvsp
. irvsp
uses the same vasp data with vasp2trace
and outputs the same format of 'trace.txt' file. However, in some cases, irvsp
does some additional things compared to vasp2trace
, which lead to different trace.txt
files generated by them. And only the one generated by vasp2trace
can be used by getBandRep
and gives reasonable results.
An example: the P point of SG 48. The POSCAR file is
SG48
1.0
4.4793300000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 8.0665800000000001 0.0000000000000000
0.0000000000000000 0.0000000000000000 9.3330800000000007
Si O
8 16
Direct
0.9596400000000003 0.9143200000000000 0.6502900000000000
0.5403599999999997 0.9143200000000000 0.8497100000000000
0.9596400000000003 0.5856800000000000 0.8497100000000000
0.5403599999999997 0.5856800000000000 0.6502900000000000
1.0403599999999997 1.0856800000000000 0.3497100000000000
0.4596400000000002 1.0856800000000000 1.1502900000000000
1.0403599999999997 0.4143200000000000 1.1502900000000000
0.4596400000000002 0.4143200000000000 0.3497100000000000
0.7500000000000000 1.0324300000000000 0.7500000000000000
0.7500000000000000 0.4675700000000000 0.7500000000000000
0.2500000000000000 0.9675700000000000 0.2500000000000000
0.2500000000000000 0.5324300000000000 0.2500000000000000
0.7500000000000000 0.7500000000000000 0.6213700000000000
0.7500000000000000 0.7500000000000000 0.8786300000000000
0.2500000000000000 0.2500000000000000 0.3786300000000000
0.2500000000000000 0.2500000000000000 1.1213700000000000
0.2500000000000000 0.8794700000000000 0.7500000000000000
0.2500000000000000 0.6205300000000000 0.7500000000000000
0.7500000000000000 1.1205300000000000 0.2500000000000000
0.7500000000000000 0.3794700000000000 0.2500000000000000
1.0000000000000000 1.0000000000000000 0.5000000000000000
0.5000000000000000 1.0000000000000000 1.0000000000000000
1.0000000000000000 0.5000000000000000 1.0000000000000000
0.5000000000000000 0.5000000000000000 0.5000000000000000
And the KPOINTS file for band calculation is
kpt
4
Rec
0.5 0.1 0.5 1
-0.5 0.1 0.5 1
0.5 0.1 -0.5 1
-0.5 0.1 -0.5 1
As can be seen, the four kpoints are acutally equivalent to each other and they should give the same LGIRs. However, the trace.txt
files generated by irvsp
and vasp2trace
are different. Only the one by vasp2trace
can give the same LGIRs for the four points via getBandRep
.
At present, I have no time to dig into the code of irrep
. Therefore, before systematic tests and checks are done, I can not conclude confidently that the trace.txt
file by irrep
can always work reasonably with getBandRep
.
Thank you for your detailed explanations. It seems really a tricky thing.
It seems really a tricky thing.
You get it!
I don't know what extra things irvsp
does compared to vasp2trace
. The fact is that irvsp
gives different results for the four equivalent k-points, as shown below.
knum = 1 kname=
k = 0.500000 0.100000 0.500000
...
bnd ndg eigval E 3 6 8
1 1-18.979313 1.00+0.00i -1.00+0.00i 1.00+0.00i 1.00+0.00i =P1
2 1-18.867776 1.00+0.00i -1.00+0.00i -1.00+0.00i -1.00+0.00i =P2
3 1-18.728280 1.00+0.00i 1.00+0.00i -1.00+0.00i 1.00+0.00i =P3
4 1-18.689457 1.00+0.00i 1.00+0.00i 1.00+0.00i -1.00+0.00i =P4
knum = 2 kname=
k =-0.500000 0.100000 0.500000
...
bnd ndg eigval E 3 6 8
1 1-18.979313 1.00+0.00i 1.00+0.00i -1.00+0.00i 1.00+0.00i =P3
2 1-18.867776 1.00+0.00i 1.00+0.00i 1.00+0.00i -1.00+0.00i =P4
3 1-18.728280 1.00+0.00i -1.00+0.00i 1.00+0.00i 1.00+0.00i =P1
4 1-18.689457 1.00+0.00i -1.00+0.00i -1.00+0.00i -1.00+0.00i =P2
knum = 3 kname=
k = 0.500000 0.100000-0.500000
...
bnd ndg eigval E 3 6 8
1 1-18.979313 1.00+0.00i 1.00+0.00i 1.00+0.00i -1.00+0.00i =P4
2 1-18.867776 1.00+0.00i 1.00+0.00i -1.00+0.00i 1.00+0.00i =P3
3 1-18.728280 1.00+0.00i -1.00+0.00i -1.00+0.00i -1.00+0.00i =P2
4 1-18.689457 1.00+0.00i -1.00+0.00i 1.00+0.00i 1.00+0.00i =P1
knum = 4 kname=
k =-0.500000 0.100000-0.500000
...
bnd ndg eigval E 3 6 8
1 1-18.979313 1.00+0.00i -1.00+0.00i -1.00+0.00i -1.00+0.00i =P2
2 1-18.867776 1.00+0.00i -1.00+0.00i 1.00+0.00i 1.00+0.00i =P1
3 1-18.728280 1.00+0.00i 1.00+0.00i 1.00+0.00i -1.00+0.00i =P4
4 1-18.689457 1.00+0.00i 1.00+0.00i -1.00+0.00i 1.00+0.00i =P3
Can you provide more details? Especially the following:
SpaceGroupIrep
to post-process VASP calculation result files.Can you provide more details? Especially the following:
1. VASP version.
5.4.1
But every version is ok.
2. All the input files information used by VASP calculation (except pot files, considering the license).
INCAR
ISTART = 1
PREC = Normal
ISMEAR = 0
SIGMA = 0.05
EDIFF = 1E-06
NPAR=4
LCHARG =T
KOPOINTS
K-Mesh
0
Gamma
4 2 2
0.0 0.0 0.0
INCAR for band
ICHARG=11
PREC = Normal
ISMEAR = 0
SIGMA = 0.05
EDIFF = 1E-06
NPAR=4
LWAVE = T
LCHARG =F
3. Detailed steps based on `SpaceGroupIrep` to post-process VASP calculation result files.
tr=readVasp2trace["trace.txt"]; trconv=convTraceToBC[48, tr, IdentityMatrix[3], -{1/4,1/4,1/4}]; rep=getBandRep[48,"",trconv]; rep["rep"][[1]]//TableForm[#,TableDepth->2]& rep["rep"][[2]]//TableForm[#,TableDepth->2]& rep["rep"][[3]]//TableForm[#,TableDepth->2]& rep["rep"][[4]]//TableForm[#,TableDepth->2]&
In https://github.com/goodluck1982/SpaceGroupIrep/issues/5#issuecomment-1034845238, you mentioned the following point:
Another issue is that the rotation matrices used, especially the SU(2) spin rotation matrix, have to be the same with vasp and vasp2trace.
In essence, this is also a basis choice problem. More precisely, the calculated results must be post-processed and analyzed based on the same basis choice. In principle, as long as we can determine these matrices used by different DFT codes, we can establish the corresponding relationship between their results. Nevertheless, all DFT codes have their own freedom and preferences in this regard, which undoubtedly makes this work more difficult.
This is very similar to the correspondence between the BCS and BC conventions represented in SpaceGroupIrep
.
Nevertheless, all DFT codes have their own freedom and preferences in this regard, which undoubtedly makes this work more difficult.
You are right. One have to understand clearly both sides, and then can the relationship between them be treated correctly.
It seems that irrep
defined at least three variables, namely, refUC
, shiftUC
, and spinor
to deal with the problem discussed here, as described in bandstructure.py
:
refUC : array, default=None
3x3 array describing the transformation of vectors defining the
unit cell to the standard setting.
shiftUC : array
Translation taking the origin of the unit cell used in the DFT
calculation to that of the standard setting.
spinor : bool
`True` if wave functions are spinors, `False` if they are scalars. It
will be read from DFT files.
See the following explanation in its paper for some additional clues:
More intriguingly, it can also calculate these parameters automatically, as shown in the last screenshot above.
More intriguingly, it can also calculate these parameters automatically, as shown in the last screenshot above.
It also use spglib
to do this. spglib
can convert any cell to its standard cell. Then all following processings use the spglib
-standardized cell as the start point.
This is also the technical pathway implemented in SpaceGroupIrep
. A lot of work has been done in irrep
to interface with different DFT codes. There should be some ideas worth borrowing and learning from.
In https://github.com/goodluck1982/SpaceGroupIrep/issues/5#issuecomment-1035938073, I commented the follows:
See the following explanation in its paper for some additional clues:
What's the relationship between the Eq. (6) in irrep's paper above and your Eq. (19) written as follows?
It looks like they're all doing a similar conversion with spglib
, but your version adopted a more complex form.
My Eq.(19) has the identical meanings with those defined in spglib, see here
Only a map should be made:
And the Eq(6) you mentioned only corresponds to the Eq(6) of spglib with a transpose.
Only a map should be made:
Here, in spglib
, a horizontal bar instead of the tilde described above, is used over a_s:
Yes, I got it wrong.
Nowadays, it's well known that tight-binding/density-functional theory (TB/DFT) are very import tools/methods in various research fields of Nano Materials Science. Till now, there are many mature TB/DFT codes and relevant tools, such as
kwant/VASP/CASTEP/QE/ABINIT/SIESTA/ELK/Wien2k/wannier90
and so on. OTOH, I've noticed that there are tools which also work based on group theory and interface with TB/DFT codes, such as irvsp and WannSymm. So, I'm not sure if it's possible to interface this package with tight-binding/density-functional theory (TB/DFT) codes to facilitate related research.Regards, HZ