In case.in1(c), the lapw1 program expects to read a line similar to:
K-VECTORS FROM UNIT:4 -9.0 1.5 187 emin / de (emax=Ef+de) / nband
With regards to the "Invalid k-point file on unit 0" error below, the
important part is:
K-VECTORS FROM UNIT:4
The "K-VECTORS FROM UNIT:" must be there with no handmade changes to
it. For example, a space cannot be put in front of it:
(space)K-VECTORS FROM UNIT:
In the above where the "4" is, there must be a value greater than 1 but
less than 100. It must also read that line and not a blank line.
For example, if the ndiff value and number ENERGY PARAMETER lines does
not match, it can lead to that error as seen in the post at:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16452.html
If that doesn't help solve the problem, you probably need send the
entire case.in1(c) file as an attachment (or a link to the file if it is
too big for the mailing list, e.g., Google Drive).
On 3/7/2020 3:30 AM, pboulet wrote:
Dear all,
I am performing SCF calculations on rather big compounds and for two
of them, containing 27 and 52 inequivalent atoms, I have the following
error message in the lapw1.error files:
'INILPW' - Invalid k-point file on unit 0
I am using Wien2k 18.1.
I have set few k-points for these calculations: 25 (div: 10 10 1)
and 10 (div: 8 8 1), respectively. The cells are tetragonal, with
very large c compared with a and b (ratios of about 6 and 20).
I have set HDLOs, as suggested during the init_lapw process. Here are
my settings in case.in1c (last line):
0.30 6 0 (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
0 0.30 0.0000 CONT 1
0 -6.12 0.0001 STOP 1
1 0.30 0.0000 CONT 1
1 -3.79 0.0001 STOP 1
2 0.30 0.0005 CONT 1
2 -1.20 0.0005 STOP 2
I have also set a broadening of the electrons, as the compounds should
be semi-metals: TEMPS 0.010, in case.in2c.
Note that, I have set these features for other, similar compounds,
and got no problem, so I guess these are not the issue.
Of course, the jobs are running in parallel (MPI): 6 and 8 nodes for
the smallest and biggest compound, respectively. Each node is composed
of 24 CPUs.
The k-points are distributed this way:
- smallest compound: 5 k-pts on 1 node and 4 k-pts on 5 nodes
- biggest compound: 2k-pts on 2 nodes and 1 k-pts on 6 nodes
So clearly, there are CPUS with 0 k-pts.
Here is a piece of one of the log files I get from the queuing (SLURM)
system:
LAPW0 END
[1] Done srun -K1
/scratch/cnt0022/pmc6881/paboulet/wien2k/.18.1/lapw0_mpi lapw0.def >>
.time00
mv: impossible to evaluate « Mn7Si12.vector_1 »: No file or directory
of this type
mv: impossible to evaluate « Mn7Si12.vector_2 »: No file or directory
of this type
mv: impossible to evaluate « Mn7Si12.vector_3 »: No file or directory
of this type
mv: impossible to evaluate « Mn7Si12.vector_4 »: No file or directory
of this type
mv: impossible to evaluate « Mn7Si12.vector_5 »: No file or directory
of this type
mv: impossible to evaluate « Mn7Si12.vector_6 »:No file or directory
of this type
These files exist, but there are, as expected, empty.
What could be the problem?
Thank you for your help and time,
Best regards,
Pascal
Pascal Boulet
—
/Professor in computational materials - DEPARTMENT OF CHEMISTRY/
University of Aix-Marseille - Avenue Escadrille Normandie Niemen -
F-13013 Marseille - FRANCE
Tél: +33(0)4 13 55 18 10 - Fax : +33(0)4 13 55 18 50
Email : pascal.bou...@univ-amu.fr <mailto:pascal.bou...@univ-amu.fr>
_______________________________________________
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
