Dear all,
After generating GRED.dat and KRED.dat as explained in the manual for a 3D system, we need to supply the crysgen.dat file for conversion. Assuming that we want to calculate the primitive unit cell, then the crysgen.dat file should look like this:
QMC
1
1 1 1
END
However, the resulting gwfn.data (attached) file has only one k point in it, so it is not possible to perform twist averaging upon this conversion, because there is only gamma point in gwfn.data file. Similarly, when our simulation cell in CRYSTAL is already a non-primitive unit cell, for the conversion, how should the crysgen.dat file look like to have several k-points to perform twist averaging after CRYSTAL09 calculation?
Thanks a lot,
Kayahan
Twist averaging and wfn conversion in CRYSTAL09
Twist averaging and wfn conversion in CRYSTAL09
- Attachments
-
- gwfn.data.zip
- (125.8 KiB) Downloaded 774 times
Re: Twist averaging and wfn conversion in CRYSTAL09
Besides, on a side note, I would like to ask if there is a way to use crysgen09 converter without fort.8 files? What fort.* files are strictly required for crysgen09 conversion?
Thanks,
Kayahan
Thanks,
Kayahan
-
- Posts: 239
- Joined: Thu May 30, 2013 11:03 pm
- Location: Florence
- Contact:
Re: Twist averaging and wfn conversion in CRYSTAL09
It's a while since I've looked at this, but as far as I remember the problem here is twofold:Kayahan wrote: However, the resulting gwfn.data (attached) file has only one k point in it, so it is not possible to perform twist averaging upon this conversion, because there is only gamma point in gwfn.data file. Similarly, when our simulation cell in CRYSTAL is already a non-primitive unit cell, for the conversion, how should the crysgen.dat file look like to have several k-points to perform twist averaging after CRYSTAL09 calculation?
Kayahan
(1) Twist-averaging involves averaging over random offsets from k_s = zero. However CRYSTAL effectively insists the origin of the k-point grid is at (0,0,0) and this cannot be offset. The input file just defines the 'shrinking factors of the Monkhorst pack mesh..'
(2) CASINO is not capable of evaluating complex wave functions for periodic systems in a Gaussian basis (not least because of this restriction in CRYSTAL) and setting complex_wf=T will flag an error. This could be coded up relatively easily but nobody ever has.
If you want automated twist averaging best to use PWSCF or CASTEP (not CRYSTAL) for your DFT code and use the automated tools that we provide to regenerate the orbitals for different offsets (see the twist averaging chapter of the CASINO manual).
This isn't very helpful I know. Sorry!
Cheers
Mike
-
- Posts: 239
- Joined: Thu May 30, 2013 11:03 pm
- Location: Florence
- Contact:
Re: Twist averaging and wfn conversion in CRYSTAL09
In older versions of CRYSTAL we had to manually extract data from 4 or 5 temporary fort.x files (from memory: fort.8 or fort.10, fort.9, fort.12, fort.30). The fort.8 files contain a sorted list of eigenvectors i.e. the orbital coefficients.Kayahan wrote:Besides, on a side note, I would like to ask if there is a way to use crysgen09 converter without fort.8 files? What fort.* files are strictly required for crysgen09 conversion?
More recent versions of CRYSTAL including CRYSTAL09 define an API (with standard format files containing all necessary inormation written out in the GRED.DAT and KRED.DAT files when you include the CRYAPI_OUT keyword in the CRYSTAL input).
Ignoring the fact that the format of the API seems to change with each new version of CRYSTAL, this means that fort.x files should not be required in CRYSTAL09 (unless I'm forgetting something). It's possible that my runcrystal script still might accidentally need them - as it has evolved every time a new version of CRYSTAL is released and still supposedly supports versions as far back as CRYSTAL95. However I imagine you're not using this or you wouldn't even be aware of the existence of GRED.DAT and KRED.DAT - you just type 'runcrystal --qmc input_file' and the gwfn.data file just appears (crysgen09 is invoked automatically and its input defined on the fly..).
Could you tell me why you think you need fort.8 files, and I'll take a look what the problem is..
Best
Mike
Re: Twist averaging and wfn conversion in CRYSTAL09
Thanks a lot Mike for the clear explanation. I needed the fort.8 files because crysgen09 wave function converter gives an error if it is not present in the directory. They are rather large actually.
Rather than automated twist averaging, let us say I choose specific twists for twist averaging such as half multiples of the reciprocal lattice vectors to avoid complex math. In that case would it be possible to perform twist averaging with CRYSTAL again?
When the crysgen.dat file is written like the following:
QMC
1
2 2 2
END
Then I have 8 k-points in the converted gwfn.data file. Do you think those always correspond to the half multiple twists in the reciprocal cell? Then, I guess I can divide that file into eight and perform 8 separate dmc calculation to do twist averaging?
Best regards,
Kayahan
Rather than automated twist averaging, let us say I choose specific twists for twist averaging such as half multiples of the reciprocal lattice vectors to avoid complex math. In that case would it be possible to perform twist averaging with CRYSTAL again?
When the crysgen.dat file is written like the following:
QMC
1
2 2 2
END
Then I have 8 k-points in the converted gwfn.data file. Do you think those always correspond to the half multiple twists in the reciprocal cell? Then, I guess I can divide that file into eight and perform 8 separate dmc calculation to do twist averaging?
Best regards,
Kayahan
-
- Posts: 239
- Joined: Thu May 30, 2013 11:03 pm
- Location: Florence
- Contact:
Re: Twist averaging and wfn conversion in CRYSTAL09
At the point the vector of orbital coefficients is created for the QMC (which, remember, may be on a subset of the k points that were used in the CRYSTAL DFT calculation) it does seem to be the case that the converter reads in fort.8, rather than attempting to manipulate the vector of orbital coefficients it has already read in from KRED.DAT. I don't actually remember why it does that, but it may be:Kayahan wrote:Thanks a lot Mike for the clear explanation. I needed the fort.8 files because crysgen09 wave function converter gives an error if it is not present in the directory. They are rather large actually.
(1) Laziness on my part. That's what it always did before the API was introduced i.e. before KRED.DAT existed. Why bother changing it as the converter evolves through new CRYSTAL versions? Fort.8 is always created, reading it is very quick, who cares?
(2) Sometimes the eigenvectors are stored sorted in eigenvalue order (fort.8) sometimes not (fort.10). CASINO assumes they are so ordered, it may be that in KRED.DAT they are not. Again, I can't remember.
Whatever, fort.8 is always created, you won't save disk space if you just read KRED.DAT. If you use runcrystal, you don't need to worry about any of this, it just works. There does seem to be scope for rewriting the converter so that fort.8 is never touched; I don't think the end user would see any difference though..? Or am I missing something?
Yes, the k points for a 2x2x2 grid only have components of zero and half a reciprocal lattice vector, because the offset is always assumed to be zero.Kayahan wrote: Rather than automated twist averaging, let us say I choose specific twists for twist averaging such as half multiples of the reciprocal lattice vectors to avoid complex math. In that case would it be possible to perform twist averaging with CRYSTAL again?
When the crysgen.dat file is written like the following:
QMC
1
2 2 2
END
Then I have 8 k-points in the converted gwfn.data file. Do you think those always correspond to the half multiple twists in the reciprocal cell? Then, I guess I can divide that file into eight and perform 8 separate dmc calculation to do twist averaging?
You could do it the way you suggest, but then you wouldn't have enough orbitals for the electrons in your 2x2x2 real space cell DMC calculation. You'd just be looking at different 1x1x1 cells, no?
Perhaps you could do it by creating a 4x4x4 gwfn.data and pulling out different 2x2x2 subsets, but we don't provide any tools to do that and you would have to do some coding!
I guess it's better than nothing, but this isn't ideal; for proper twist averaging you would like to average over a reasonably large number of random offsets. You got something against CASTEP and PWSCF?
![Wink ;)](./images/smilies/icon_e_wink.gif)
Mike