[Q-e-developers] Problems with IO
Thorsten Kurth
tkurth at lbl.gov
Wed May 17 17:49:02 CEST 2017
hello developers,
I have fixed the issue by adding a dummy dual because it is not used for branching or whatever, just user info. But then I get:
ifort: remark #10397: optimization reports are generated in *.optrpt files in the output location
velocity.f90(49): error #6404: This name does not have a type, and must have an explicit type. [G]
gk = xk(ipol,ik) + g(ipol,igk_k(ig,ik)) + q(ipol)
-------------------------^
velocity.f90(50): error #6404: This name does not have a type, and must have an explicit type. [TPIBA]
p_psi(ig,ibnd) = p_psi(ig,ibnd) + gk * tpiba * psi(ig,ibnd)
looking into the file I find:
SUBROUTINE apply_p(psi, p_psi, ik, ipol, q)
!-----------------------------------------------------------------------
!
! ... Apply the kinetic part of the velocity operator
! ... |p_psi> = (G+k+q/2)_{ipol} |psi>
!
USE kinds, ONLY : DP
USE klist, ONLY : xk, igk_k
USE wvfct, ONLY : nbnd, npwx, npw
USE pwcom
USE gipaw_module, ONLY : nbnd_occ
#ifdef __BANDS
USE mp_bands, ONLY : inter_bgrp_comm
USE mp, ONLY : mp_sum
USE gipaw_module, ONLY : ibnd_start, ibnd_end
#endif
!-- parameters ---------------------------------------------------------
IMPLICIT none
INTEGER, INTENT(IN) :: ik ! k-point
INTEGER, INTENT(IN) :: ipol ! cartesian direction (1..3)
REAL(DP), INTENT(IN) :: q(3)
COMPLEX(DP), INTENT(IN) :: psi(npwx,nbnd)
COMPLEX(DP), INTENT(OUT) :: p_psi(npwx,nbnd)
!-- local variables ----------------------------------------------------
REAL(DP) :: gk
INTEGER :: ig, ibnd
do ibnd = 1, nbnd_occ(ik)
do ig = 1, npw
gk = xk(ipol,ik) + g(ipol,igk_k(ig,ik)) + q(ipol)
p_psi(ig,ibnd) = p_psi(ig,ibnd) + gk * tpiba * psi(ig,ibnd)
enddo
enddo
END SUBROUTINE apply_p
My question is: is gip really supposed to compile at this point in time? I am wondering that I get that many compile errors but nobody noticed it.
If that is something special to the github repo not in sync with svn or something in my merge (which should not be the case as I pulled a clean copy from the github and merged my changed manually into pw.x only, but here gipaw is not compiling for relatively trivial syntactic reasons).
I would really encourage to set up a thorough unit testing and CI system to catch these problems before they appear. However, can someone help me out with this issue?
Best Regards
Thorsten Kurth
On 17. Mai 2017, 08:22 -0700, Thorsten Kurth <tkurth at lbl.gov>, wrote:
> Hello developers,
>
> I think I know what the issue is: in my automated build script, gipaw does not build and the user who complained used an incompatible version. So what happens is, that the compiler complains about:
>
> ifort: remark #10397: optimization reports are generated in *.optrpt files in the output location
> write_tensor_field.f90(180): error #6404: This name does not have a type, and must have an explicit type. [DUAL]
> celldm, at, gcutm, dual, ecutwfc, 100, atm, ityp, zv, &
>
>
> Apparently, dual is not declared anywhere:
>
> SUBROUTINE write_nics(filename, field)
> !-----------------------------------------------------------------------
> !
> ! ... write the NICS in PP postproc format
> !
> USE kinds, ONLY : dp
> USE io_global, ONLY : stdout, ionode
> USE fft_base, ONLY : dfftp
> USE scatter_mod, ONLY : gather_grid
> USE gvect, ONLY : gcutm
> USE cell_base, ONLY : at, ibrav, celldm
> USE ions_base, ONLY : zv, ntyp => nsp, nat, ityp, atm, tau
> USE gvecw, ONLY : ecutwfc
> USE pwcom
> USE gipaw_module
> !--------------------------------------------------------------------
> implicit none
> character*(*) filename
> real(dp) :: field(dfftp%nnr,3,3,nspin)
> !-- local variables ----------------------------------------------------
> character(75), parameter :: title = 'NICS'
> real(dp), allocatable :: nics(:), aux(:)
> integer :: ispin
>
> allocate(nics(dfftp%nnr))
> nics = 0.d0
> do ispin = 1,nspin
> nics(:) = nics(:) + (field(:,1,1,ispin) + field(:,2,2,ispin) + &
> field(:,3,3,ispin))/3.d0
> enddo
> nics = nics * 1d6
>
> ! gather the data
> allocate(aux(dfftp%nr1x*dfftp%nr2x*dfftp%nr3x))
> #ifdef __MPI
> call gather_grid (dfftp, nics, aux)
> #else
> aux = nics
> #endif
>
> if (ionode) then
> write(stdout, '(5X,''writings NICS to: '',A40)') trim(filename)
> call plot_io(filename, title, dfftp%nr1x, dfftp%nr2x, dfftp%nr3x, &
> dfftp%nr1, dfftp%nr2, dfftp%nr3, nat, ntyp, ibrav, &
> celldm, at, gcutm, dual, ecutwfc, 100, atm, ityp, zv, &
> tau, aux, 1)
> endif
>
> deallocate(aux, nics)
>
> end subroutine write_nics
>
>
> Best Regards
> Thorsten
>
>
> On 16. Mai 2017, 08:37 -0700, Thorsten Kurth <tkurth at lbl.gov>, wrote:
> > Thanks for all the feedback.
> >
> > I will have a closer look at what is going wrong with gipaw, maybe I did not pull the latest updates to master from the source. I am using the official github mirror but I am not sure if it is 100% in sync with the svn or if it lags behind. In any case, I will have a look tomorrow as today our machine is in maintenance. So please stay tuned till I can give you updates.
> >
> > Best Regards
> > Thorsten
> >
> > On 16. Mai 2017, 08:24 -0700, Paolo Giannozzi <p.giannozzi at gmail.com>, wrote:
> > > Hi Thorsten
> > >
> > > thank you for the info. Please report specific cases of failure with
> > > details. We are in the middle of some extensive changes to I/O and
> > > there might be corner (or not-so-corner) cases that don't work as
> > > hoped.
> > >
> > > Paolo
> > >
> > > On Mon, May 15, 2017 at 7:27 PM, Pietro Delugas <pdelugas at sissa.it> wrote:
> > > > Hello Thorsten
> > > >
> > > > Thanks for signaling us these issues. We will try to fix them soon.
> > > >
> > > > If the version you have deployed is the tagged 6.1 version the new format
> > > > is activated only if you set the "--enable-xml=yes" option while running
> > > > the configure script (the default value for this option in 6.1 is no).
> > > > This option in 6.1 version defines the preprocessor flag -D__XSD inside
> > > > the make.inc file. When this flag is not defined the program is compiled
> > > > using the old XML format and discards all code related to new XML output. If
> > > > you are using 6.1 check that the -D__XSD option is not there, and you
> > > > will be using the old xml format.
> > > >
> > > > The situation has been reversed in SVN revisions following the 6.1 release;
> > > > the default value for the --enable-xml option has been set to "yes" and
> > > > you must specify it as "no" for reverting to the old XML format.
> > > >
> > > > In the development version you can check inside the make.inc file that the
> > > > -D__OLDXML preprocessor flag is appended to the DFLAGS. If it is, you are
> > > > using old xml format. In case it is not it is sufficient to append it and
> > > > recompile from scratch.
> > > >
> > > > thanks again, greetings Pietro
> > > >
> > > >
> > > > On 15/05/2017 18:01, Stefano Baroni wrote:
> > > >
> > > > Thank you for your note, Kurth. Please, note that the appropriate address to
> > > > report this kind of problems is q-e-developers at qe-forge.org, to I which I am
> > > > forwarding this email. I am forwarding to Pietro Delugas as well, who may
> > > > give you direct advice on the reported issue. best regards - Stefano B
> > > >
> > > > On 15 May 2017, at 17:42, Thorsten Kurth <tkurth at lbl.gov> wrote:
> > > >
> > > > Dear developers, QE maintainers,
> > > >
> > > > we deployed QE 6.1 on Cori at NERSC and get a lot of error reports which are
> > > > IO related. Most of them might be attributed to migrating to a new file
> > > > form. The main errors include:
> > > >
> > > > 1) files written by pw.x cannot be read by pw2bgw.x, it complains about a
> > > > missing XML.
> > > >
> > > > 2) files written by pw.x cannot be processed by gipaw either.
> > > >
> > > > Do I need to specify a certain flag to switch to the old formats as long as
> > > > the new one is not fully implemented? Or are these two cases supposed to
> > > > work?
> > > >
> > > > Best Regards
> > > > Thorsten Kurth
> > > >
> > > >
> > > >
> > > >
> > > > —
> > > > Stefano Baroni - SISSA, Trieste - http://stefano.baroni.me, stefanobaroni
> > > > (skype)
> > > >
> > > > There are two ways of doing a theoretical calculation: you should have
> > > > either a clear physical model in mind, or a rigorous mathematical basis. You
> > > > have neither. [E. Fermi to F.J. Dyson, as humbly reported by the latter]
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
> > > Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> > > Phone +39-0432-558216, fax +39-0432-558222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20170517/2a62384b/attachment.html>
More information about the developers
mailing list