Dear Alberto, Thanks for the information. I will download and use the latest version.
I don't quite get your advice as not to perform a band structure calculation at the end of a cell relaxation. I did the band structure calculation in a separate run after cell relaxation has converged. Since there is only a small fraction of change in one cell dimension, I have used a fixed k-points sampling throughout these calculations. Do you mean that Siesta does a k-points re-sampling after every cell relaxation step? Best regards Aihua > -----Original Messages----- > From: "Alberto Garcia" <[email protected]> > Sent Time: Wednesday, May 18, 2016 > To: [email protected] > Cc: > Subject: Re: [SIESTA-L] discrepancy in kpoints generation for band structure > calculation > > Hi Aihua, > > This problem is corrected in the latest version (4.0-b2) in > http://launchpad.net/siesta > The structure read at the beginning of the calculation is used to generate > the k-points. > > Note that it would indeed not be advisable to perform a band-structure > calculation at the end of > a cell-relaxation run, as the k-points would be appropriate for the original > cell. > > Regards, > > Alberto > > On 18 May 2016, at 12:18, Zhang Aihua <[email protected]> wrote: > > > Dear All, > > > > I have noticed that if I do a single-point band structure calculation with > > > > UseStructFile true > > > > and simultaneously with an old LatticeVectors block in the input > > SystemLabel.fdf file, > > > > then it seems the kpoints are generated using old LatticeVectors, but the > > scf calculation > > > > is performed using the structure information taken from > > SystemLabel.STRUCT_IN. > > > > I encountered this problem when doing a BS calculation after a relaxation > > of both atomic > > > > positions and cell dimensions. I had expected the structure in > > SystemLabel.STRUCT_IN > > > > should take the priority over the LatticeVectors data block. > > > > Best regards > > > > Aihua > > > > > > > > >
