- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
I have trouble with quantum espresso code compiled with Intel Fortran (version 11.1.073 specifically). It attempted to read the following text input:
&CONTROL
calculation = 'scf' ,
wf_collect=.true.,
verbosity = 'high' ,
outdir = '/tmp/lustre/wirawan0/BIGFILES.runtime/PWQMC-77/MnO/afm2/rh.1x1x1/qe/Opium-GFRG/vol21.96' ,
wfcdir = '/tmp/lscr/wirawan0/qe/MnO/afm2/Opium-GFRG/vol21.96' ,
pseudo_dir = '/home/wirawan/Work/PWQMC-77/psp' ,
restart_mode = 'from_scratch',
prefix = 'k+5000+5000+5000' ,
tstress = .true. ,
tprnfor = .true. ,
/
This input text was read using a NAMELIST facility of Fortran95. I found that apparently Intel's READ statement would truncate the reading of "outdir" text line above at character #80, then read the rest at a second iteration.
So, instead of reading in the string "/tmp/lustre/wirawan0/BIGFILES.runtime/PWQMC-77/MnO/afm2/rh.1x1x1/qe/Opium-GFRG/vol21.96", for the "outdir" variable, I got instead "/tmp/lustre/wirawan0/BIGFILES.runtime/PWQMC-77/ MnO/afm2/rh.1x1x1/qe/Opium-GFRG/vol21.96" -- that is, there is a whitespace just before word "MnO". This is very annoying! GNU Fortran does not do this.
Is there an easy way to fix this problem? IS this an implicit behavior of Intel Fortran, maybe because of its default limit of line length per text line when opening a text file?
Wirawan
&CONTROL
calculation = 'scf' ,
wf_collect=.true.,
verbosity = 'high' ,
outdir = '/tmp/lustre/wirawan0/BIGFILES.runtime/PWQMC-77/MnO/afm2/rh.1x1x1/qe/Opium-GFRG/vol21.96' ,
wfcdir = '/tmp/lscr/wirawan0/qe/MnO/afm2/Opium-GFRG/vol21.96' ,
pseudo_dir = '/home/wirawan/Work/PWQMC-77/psp' ,
restart_mode = 'from_scratch',
prefix = 'k+5000+5000+5000' ,
tstress = .true. ,
tprnfor = .true. ,
/
This input text was read using a NAMELIST facility of Fortran95. I found that apparently Intel's READ statement would truncate the reading of "outdir" text line above at character #80, then read the rest at a second iteration.
So, instead of reading in the string "/tmp/lustre/wirawan0/BIGFILES.runtime/PWQMC-77/MnO/afm2/rh.1x1x1/qe/Opium-GFRG/vol21.96", for the "outdir" variable, I got instead "/tmp/lustre/wirawan0/BIGFILES.runtime/PWQMC-77/ MnO/afm2/rh.1x1x1/qe/Opium-GFRG/vol21.96" -- that is, there is a whitespace just before word "MnO". This is very annoying! GNU Fortran does not do this.
Is there an easy way to fix this problem? IS this an implicit behavior of Intel Fortran, maybe because of its default limit of line length per text line when opening a text file?
Wirawan
- Balises:
- Intel® Fortran Compiler
Lien copié
6 Réponses
- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
I can't reproduce this behavior with 11.1.070. Any such behavior would be a bug. My test program is:
[fortran] program U103025 implicit none ! Variables character(100) calculation, verbosity, outdir, wfcdir,pseudo_dir, restart_mode, prefix logical wf_collect, tstress, tprnfor namelist /CONTROL/ calculation, wf_collect, verbosity, outdir, wfcdir, pseudo_dir,restart_mode,prefix, tstress, tprnfor open (unit=1,file='text1.txt',status='old') read (1,CONTROL) write (6,CONTROL) end program U103025[/fortran]
- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
> I found that apparently Intel's READ statement would truncate the
reading of "outdir" text line above at character #80, then read the rest
at a second iteration.
That is unfounded speculation. Showing the declarations of the variables in the NAMELIST and attaching the input record as a file would help to pinpoint the problem.
If the character variables are not of sufficient length, the input lines are truncated, but I do not find any lines reread with Version 12.1 of the compiler. For example, changing the character type variables in Dr. Fortran's program to CHARACTER(len=20), I get the output
&CONTROL
CALCULATION = scf ,
WF_COLLECT = T,
VERBOSITY = high ,
OUTDIR = /tmp/lustre/wirawan0,
WFCDIR = /tmp/lscr/wirawan0/q,
PSEUDO_DIR = /home/wirawan/Work/P,
RESTART_MODE = from_scratch ,
PREFIX = k+5000+5000+5000 ,
TSTRESS = T,
TPRNFOR = T
/
That is unfounded speculation. Showing the declarations of the variables in the NAMELIST and attaching the input record as a file would help to pinpoint the problem.
If the character variables are not of sufficient length, the input lines are truncated, but I do not find any lines reread with Version 12.1 of the compiler. For example, changing the character type variables in Dr. Fortran's program to CHARACTER(len=20), I get the output
&CONTROL
CALCULATION = scf ,
WF_COLLECT = T,
VERBOSITY = high ,
OUTDIR = /tmp/lustre/wirawan0,
WFCDIR = /tmp/lscr/wirawan0/q,
PSEUDO_DIR = /home/wirawan/Work/P,
RESTART_MODE = from_scratch ,
PREFIX = k+5000+5000+5000 ,
TSTRESS = T,
TPRNFOR = T
/
- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
This is bizzare! I tested your test code and it also did not exhibit that sickly behavior. I tried a number of things here:
1) tried different BLAS/LAPACK library: MKL (10.x), ATLAS (3.8.4), internal BLAS/LAPACK provided by quantum espresso
2) tried to compile serial and parallel code
3) tried to compile without any optimization
--- all yield the same kind of error. I added print statement right after the "read" statement (SUBROUTINE read_namelists in file: read_namelists.f90) -- it still had that sickly behavior!
PS: Just to be correct, quantum espresso defines the string length to 256 chars.
Wirawan
- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
Please reduce your test program to the minimum necessary to reproduce the problem, and then attach it to a reply here. My guess is that in the process you will find that the error is not what you think it is.
- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
OK... I found the cause of the error. It is *not* Intel Fortran per se (though related). It is the way the input was implemented in quantum espresso. I've fed back the developer, hopefully they will listen.
Wirawan
- Marquer comme nouveau
- Marquer
- S'abonner
- Sourdine
- S'abonner au fil RSS
- Surligner
- Imprimer
- Signaler un contenu inapproprié
Glad to hear it.

Répondre
Options du sujet
- S'abonner au fil RSS
- Marquer le sujet comme nouveau
- Marquer le sujet comme lu
- Placer ce Sujet en tête de liste pour l'utilisateur actuel
- Marquer
- S'abonner
- Page imprimable