Re: [QE-users] R: R: QE 7.2 compilation with new Intel compilers

[Paolo Giannozzi]

On 8/24/23 23:44, Kliavinek, Sergei wrote

./configure F90=ifx CC=mpiicx CFLAGS=-O3 FFLAGS=-O3 MPIF90=mpiifx  
--with-hdf5="/opt/hdf5" --enable-wannier90


I don't think the "-enable-wannier90" option exists


checking version of mpiifx... unknown, assuming gfortran


"configure" tries to figure out which serial compiler is wrapped the 
parallel compiler: see install/m4/x_ac_qe_mpif90.m4. It is needed 
because the typical "mpif90" compiler can wrap many different compilers. 
This mechanism is not implemented for the newest Intel compiler, though. 
It's not difficult, but it requires

1. having access to the newest Intel compiler, and
2. having an idea on how to modify "configure".
(I may fulfill requirement 2 but not 1)

Paolo



setting F90... gfortran
setting MPIF90... mpiifx

So it seems like the code cannot find the version of mpiifx/ifx and 
can't use them even if I declare that I want to use MPIF90=mpiifx

Do you have any idea why I obtain  this behavior?
For the context, I build QE inside the Docker Image based on 
the intel/oneapi-hpckit:2023.2.1-devel-ubuntu22.04:


# Use Intel OneAPI HPC Toolkit as base image
FROM intel/oneapi-hpckit:2023.2.1-devel-ubuntu22.04

# Install of utilities and libraries
RUN apt-get update && apt-get install -y \
     build-essential \
     wget \
     unzip \
     libfftw3-dev \
     libblas-dev \
     liblapack-dev \
     vim

# Install of Git, OpenSSH, python, pip and make
RUN apt-get update && apt-get install -y git openssh-client make 
  python3-pip

RUN apt-get update && apt-get install -y libtool-bin


# Source the OneAPI setvars script to make ifort available
RUN echo 'source /opt/intel/oneapi/setvars.sh' >> ~/.bashrc

# Install of Quantum Espresso
WORKDIR /opt
RUN wget https://github.com/QEF/q-e/archive/refs/tags/qe-7.2.zip && \
     unzip qe-7.2.zip && \
     cd q-e-qe-7.2 && \
     ./configure F90=ifx CC=mpiicx CFLAGS=-O3 FFLAGS=-O3 MPIF90=mpiifx 
  --with-hdf5="/opt/hdf5" --enable-wannier90 && \

     make all && \
     rm ../qe-7.2.zip

Also, I tried to fix it manually. What I've done:
made new config:

./configure F90=ifx CC=mpiicx CFLAGS=-O3 FFLAGS=-O3 MPIF90="$(which 
mpiifort) -fc=$(which ifx)"  --with-hdf5="/opt/hdf5" --enable-wannier90



And after it change everywhere manually the mpiifort to the mpiifx. And 
it's work.


I've add the resulting make.inc file



Best,
Sergei

24 авг. 2023 г., в 2:31 AM, Pietro Davide Delugas  
написал(а):


Dear Sergei

The configure script determines the compiler by checking the output of 
the MPIF90 command, which must be set  as

MPIF90=mpiifx.
In this way, in my case, the configure script detects correctly that I 
want to use an intel compiler but sets it wrongly toifortinstead ofifx.
This is a minor issue that may need to be fixed, but if the future 
ifort and ifx are the same compiler, it may be unnecessary, and fixing 
it now can cause problems in the future.


In your case, instead, MPIF90 was pointing to a  wrapper for 
thegfortrancompiler, so all the settings, including the preprocessing 
options passed to the compiler with the F90FLAGS variable, are those 
forgfortranand the bad preprocessing causes all those syntax errors in 
that file.
You may add -fpp -allow nofpp_comments to the F90FLAGS variable in 
make.inc


Or, much better, you can set the environment variable MPIF90=mpiifx. 
Then, rerun the configure script and fix the F90 variable inside the 
make.inc

and everything should work.
Best regards
Pietro

*Da:*users  per conto di 
Kliavinek, Sergei 

*Inviato:*mercoledì 23 agosto 2023 21:06
*A:*Quantum ESPRESSO users Forum 
*Oggetto:*[QE-users] R: QE 7.2 compilation with new Intel compilers
Dear Pietro,
Thanks a lot for your suggestion!
Indeed, I checked make.inc, and even though I explicitly wrote the 
`F90=ifx` option during configuration, it was ignored, and make.inc 
ended up writing `F90=gfortran`.  (perhaps this configuration behavior 
is already worth a separate analysis in light of the fact that Intel 
will soon abandon old compilers).
The previous error was indeed resolved by this, but a new one has 
appeared:



gram.f90(60): error #5082: Syntax error, found IDENTIFIER 'CREATE' 
when expecting one of: ) ( , :  ; % [ . = / =>

 data copy(cp_bgrp, bec_bgrp) create(ctmp, cp_tmp,bec_tmp,csc,csc2) &
--^
gram.f90(61): error #5082: Syntax error, found IDENTIFIER 'COPYIN' 
when expecting one of: :: ) ( , : *  ; . % (/ + - [ 
] /) . = ' ** / ...

 & copyin(betae, qq_nt, ofsbeta,ityp, ibgrp_g2l, nh, tvanp )
---^
gram.f90(61): error #5082: Syntax error, found END-OF-STATEMENT when 
expecting one of: :: ) , :

 & copyin(betae, qq_nt, ofsbeta,ityp, ibgrp_g2l, nh, tvanp )
-^
gram.f90(72): error #5082: Syntax error, found IDENTIFIER 'PRESENT' 
when expecting one of: ( : % [ . = =>

 kernels present(ctmp, cp_bgrp)
-^
gram.f90(74): error #5082

Re: [QE-users] Random seed for MD calculations

[Paolo Giannozzi]

Thank you for noticing again a problem. It will be fixed in next release:
  https://gitlab.com/QEF/q-e/-/merge_requests/2137
Paolo

On 8/14/23 19:24, Han Hsu (徐翰) wrote:


You don't often get email from han...@ncu.edu.tw. Learn why this is 
important 



Dear Professor Giannozzi, QE developers, and QE users:

Previously, I reported that while the patch file provided by Prof. 
Giannozzi works (namely, not all restart MD calculations got the same 
sequence of the random numbers), a particular sequence of random numbers 
is generated much more frequently than the others: Nearly half of my 
restart calculations got that sequence of random numbers. Now I think I 
have found out the reason why. By modifying Modules/random_numbers.f90, 
in particular, its subroutine "set_random_seed" (lines 74–87), this 
problem can be resolved, as described below.


In the subroutine "set_random_seed" , the parameter "iseed" is generated 
based on the system time (lines 81–84), as shown below. By calling 
"date_and_time", the system time is extracted in terms of eight numbers 
(year, month, ..., milliseonds). Four of these numbers are adopted to 
generate "iseed", including the time difference with respect to UTC (in 
minutes) [itime(4)], and minutes, seconds, and milliseconds 
[itime(6–8)]. Among them, I find the inclusion of itime(4) 
incomprehensible, as this term is a constant based on the location of 
the computer. Remarkably, in the UK, itime(4)= 0, meaning this term has 
ZERO effects on "iseed", so why should it be included anyway? By 
contrast, in my country Taiwan (GMT+8), itime(4)= 480, which results in 
a much larger "iseed" than in the UK, by up to hundreds of times...


CALL date_and_time ( values = itime )
! itime contains: year, month, day, time difference in minutes, hours,
!                 minutes, seconds and milliseconds.
iseed = ( itime(8) + itime(6) ) * ( itime(7) + itime(4) )
irand = randy ( iseed )

Given the above analysis, I modified this subroutine by replacing 
itime(4) with itime(5) (namely, hours), making "iseed" fully 
time-dependent. With this modification, all my test calculations 
(from_scratch and all the restart rounds) got different sequences of 
random numbers. If this modification is correct, perhaps it can be 
included in the next release of Quantum Espresso (7.3)?


Thank you for your suggestions and advice.

Best regards,

Han Hsu

On Sat, Aug 12, 2023 at 1:25 AM Han Hsu (徐翰) > wrote:


Dear Professor Giannozzi

Thank you very much for the patch file. It works!! Now, the random
numbers generated in all rounds of calculations (including
from_scratch and all the restart calculations) are not always
repetitive.

After more tests, however, I noticed that some "random numbers" are
generated much much more frequently than the others. Not
surprisingly, this occurs in both 'andersen' and 'svr' thermostats.
What surprises me is that this occurs on different machines at
different institutes as well. I therefore believe this should be
reported, as further described below.

Again, all the test runs were performed using a 8-atom cell of fcc
Si, with dt = 20, tempw = 600. Each run lasts for 12000 steps,
divided into a from_scratch (steps 1–1000) and 11 restart
calculations (steps 1001–2000, 2001–3000, ..., 11001–12000). Both
'andersen' and 'svr' are tested (nraise = 100). A few representative
results obtained on two different machines are shown below (JobID on
these two machines are very different). In order to print out the
random numbers, additional WRITE statements are added to the patched
dynamics_module.f90 file.


(1) svr (random numbers R1, R2, ..., R_Nf are generated in each step)

In run_4323, same sequence of random numbers were generated in
rounds 2, 4, 6, 8, 10, and 12. In run_6632321 (on a different
machine), same sequence of random numbers were generated in rounds
3, 5, 6, 7, 8, and 12. Furthermore, all these 12 rounds on two
different machines got the same sequence of random numbers...

===
run_4323
===
In pwscf.md.1.out, ...
      Entering Dynamics:    iteration =     1
      rr**2 = R1**2 =  0.5153
      sum_of_gaussians2 = R2**2+...+R_Nf**2 =     26.0457
      Entering Dynamics:    iteration =     2
      rr**2 = R1**2 =  0.0411
      sum_of_gaussians2 = R2**2+...+R_Nf**2 =     14.9090
      Entering Dynamics:    iteration =     3
      rr**2 = R1**2 =  0.2940
      sum_of_gaussians2 = R2**2+...+R_Nf**2 =     20.9707
      Entering Dynamics:    iteration =     4
      rr**2 = R1**2 =  1.0311
      sum_of_gaussians2 = R2**2+...+R_Nf**2 =     23.6863
      Entering Dynamics:    iteration =     5
      rr**2 = R1**2 =  0.0971
      sum_of_gaussians2 = R2**2+...+R_Nf**2 =      8.4677
      Entering Dyna