[Q-e-developers] Problems with IO

Wed May 17 17:20:34 CEST 2017

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/9e1a126d/attachment.html>