Dear All,
from readdvscf : error # 80
../phonon/save/prefix.dvscf_q1 too short, check ecut
======================================
I don’t think ecut is an input variable, so I don’t know what does check ecut mean in this case. Appreciate you help.
Dear jiachen,
This means that you have done the calculations of the phonon (the way you obtained the dvscf files) with an ecut and
then you are using a different ecut in the scf and nscf calculations before EPW.
Both ecut have to be the same.
Best,
Samuel
Dear Sponce,
Thank you very much! If ecut here means ecutwfc, I am positive that I kept the same ecutwfc in pwscf calculations, phonon calculation after and the nscf calculation for epw after that. I checked data-file.xml to make sure. I noticed some difference in maximum number of G vectors, but epw seems to be fine with that in examples. So, I still don’t know what is the issue here.
Hello,
Yes I mean ecutwfc indeed.
This warning just says that the size of the file is too small with respect to what the code expects. There could be multiple reasons
but the most current one is a different ecutwfc.
If that is not the issue, then it could be different byte record length. Did you compute the dvscf file on the same machine and same compilation flags (you need -bytrecl)?
Are you able to correctly do the EPW examples or test-suite?
Dear Sponce,
Yes, dvscf files were generated by the same machine, and other epw calculations on the same machine are fine. I used simply configure - make, how should I use -bytrecl? BTW, the system I am having issue with is large, more than 100 atoms. Is that going to be a problem?
Hello,
Yes it is very large …
What is the size of your dvscf files?
You should use the etf_mem = .false. option of EPW to reduce memory but it is still going to be very challenging I think.
Best,
Samuel
thank you for your adivce.
size of dvscf file is 9842MB, is that something just impossible?
Hello,
It should be in principle possible. The largest I ever done was ~50 atoms and dvscf of size 4.1 Gb.
It was doable but expansive and I had to use the high memory nodes on my cluster.
Best,
Samuel
Dear Sponce,
I still hope that I can figure out this problem. So, I did some more tests. For one system, I found if ecutwfc is small, then the code runs fine; however, if it is large, I had this dvscf reading error. Then, I looked into the code raising the error:
[code:a38xfvgz]#if ! defined(__NAG)
ios = fstat ( iudvscf, statb)
IF (recn * unf_recl .gt. statb(8)) call errore(‘readdvscf’, &
trim(tempfile)//’ too short, check ecut’, iudvscf)
#endif[/code:a38xfvgz]
To pin down the error, I let the code print statb(8), which is supposed to be the size of dvscf file. For the large file, I got a negative integer: -1906180096. The actual file size from ll is 2388787200. First of all, a negative statb(8) raises the error. Secondly, 2388787200-(-1906180096) = 2^32. So, I guess when a file size is larger than 2^31, for some systems, statb(8) is negative. I had this dvscf file error on three different machines, so, I guess this is not very rare.
I grep the code, and statb is only used in readdvscf. now my question is, can I assume this error is not important? Appreciate it.
Hello,
You are correct. This is due to the max size of integer kind 4. Since this is linked with QE, I cannot directly change it. However, you can introduce a temporary kind 8 variable like this:
[code:3ahltjhs] INTEGER(kind=8) :: mult_unit
CALL set_ndnmbr ( 0, iq, 1, nqc, filelab)
tempfile = trim(dvscf_dir) // trim(prefix) // ‘.dvscf_q’ // filelab
unf_recl = DIRECT_IO_FACTOR * lrdrho
mult_unit = unf_recl
mult_unit = recn * mult_unit
open (iudvscf, file = tempfile, form = ‘unformatted’, &
access = ‘direct’, iostat=ios,recl = unf_recl,status=‘old’)
IF (ios /= 0) call errore (‘readdvscf’,'error opening ’ // tempfile, iudvscf)
#if defined(__NAG)
CALL fstat( iudvscf, statb, errno=ios)
IF (mult_unit .gt. statb%st_size) call errore(‘readdvscf’, &
trim(tempfile)//’ too short, check ecut’, iudvscf)
#endif
#if ! defined(__NAG)
ios = fstat ( iudvscf, statb)
!IF (recn * unf_recl .gt. statb(8)) call errore(‘readdvscf’, &
IF (mult_unit .gt. statb(8)) call errore(‘readdvscf’, &
trim(tempfile)//’ too short, check ecut’, iudvscf)
#endif
!
read (iudvscf, rec = recn) dvscf
close (iudvscf, status = ‘keep’)
!
!
end subroutine readdvscf[/code:3ahltjhs]
Let me know if this works for you.
Best,
Samuel
Dear Sponce,
The issue with this change is that as long as statb(8) is negative, code always raise the error. So, how long mult_unit is doesn’t really matter…
Hello,
I see. Its the first time I see a negative fstab(8). This should be the size of the file https://gcc.gnu.org/onlinedocs/gfortran/STAT.html
Either there is a problem with the file or the file is larger than the integer kind of fstab(8). This cannot be changed since its an intrinsic Fortran function.
You can indeed try to remove the check and see if it works.
Best,
Samuel
Dear Sponce,
Yes, removing check works. Thank you very much for your attention.
Dear jiachen
I have similar error. which .f90 code I have to recompile? I could not see readdvscf.f90 in EPW/src/. Thank you.
Sincerely, Zegnet
Dear Prof. Samuel
I have similar error. which .f90 code I have to recompile? I could not see readdvscf.f90 in EPW/src/. Thank you.
Sincerely, Zegnet