3
$\begingroup$

I encountered an error while executing the PROJWFC script. I have successfully run PROJWFC calculations on my computer for smaller systems without any issues. However, this error occurs only when executing it on a remote server. Could someone please help with this?

Program PROJWFC v.7.2 starts on 11Jul2024 at 22:32:47

    This program is part of the open-source Quantum ESPRESSO suite
    for quantum simulation of materials; please cite
        "P. Giannozzi et al., J. Phys.:Condens. Matter 21 395502 (2009);
        "P. Giannozzi et al., J. Phys.:Condens. Matter 29 465901 (2017);
        "P. Giannozzi et al., J. Chem. Phys. 152 154105 (2020);
         URL http://www.quantum-espresso.org",
    in publications or presentations arising from this work. More details at
    http://www.quantum-espresso.org/quote

    Parallel version (MPI & OpenMP), running on     768 processor cores
    Number of MPI processes:               768
    Threads/MPI process:                     1

    MPI processes distributed on     6 nodes
    R & G space division:  proc/nbgrp/npool/nimage =     768
    470092 MiB available memory on the printing compute node when the environment starts


    Reading xml data from directory:

    ./Vacancy(1)_SCF.save/
    file C.pbe-rrkjus.UPF: wavefunction(s)  2S 2P renormalized

    IMPORTANT: XC functional enforced from input :
    Exchange-correlation= PBE
                          (   1   4   3   4   0   0   0)
    Any further DFT definition will be discarded
    Please, verify this is what you really want
$\endgroup$
6
  • 1
    $\begingroup$ C.pbe-rrkjus is ultrasoft, correct? What other pseudopotentials are you using in your calculation? It could be that either there different types of pseudopotentials are being mixed or PROJWFC does not support ultrasoft potentials? Maybe the manual has more infos on this $\endgroup$
    – manju9
    Commented Jul 12 at 8:17
  • $\begingroup$ @manju9 yes, it is an ultrasoft pp. This calculation uses this one only. $\endgroup$ Commented Jul 12 at 8:42
  • 1
    $\begingroup$ It's not an "error" if your calculation CRASH at that stage, it's probably due to something else? $\endgroup$
    – Okano
    Commented Jul 12 at 11:11
  • 2
    $\begingroup$ @ThejanHasaranga This is perfectly fine. This is not an error. The calculation is running, and is not finished yet. Maybe you have allocated more than 1 node (Always use single node for this type of post-processing. From my experience, they only takes a few minutes even as little as 10 CPUs for 216 atoms). $\endgroup$ Commented Jul 12 at 16:24
  • 1
    $\begingroup$ @AbdulMuhaymin-FreePalestine why not write an answer? $\endgroup$ Commented Jul 17 at 10:46

1 Answer 1

5
$\begingroup$

This is not an error.

    Any further DFT definition will be discarded
    Please, verify this is what you really want

The above message is a part of the regular output. The projwfc.x should show some parallelization info after that like the following.

Parallelization info
     --------------------
     sticks:   dense  smooth     PW     G-vecs:    dense   smooth      PW
     Min         180     180     46                19282    19282    2562
     Max         181     181     47                19291    19291    2573
     Sum       20217   20217   5249              2160009  2160009  287777
 
     Using Slab Decomposition
 

     Gaussian broadening (read from file): ngauss,degauss=   0    0.001000


     Calling projwave .... 
     Subspace diagonalization in iterative solution of the eigenvalue problem:
     one sub-group per band group will be used
     scalapack distributed-memory algorithm (size of sub-group: 10* 10 procs)

     linear algebra parallelized on 100 procs
 
  Problem Sizes 
  natomwfc =          413
  nx       =           42
  nbnd     =          347
  nkstot   =           26
  npwx     =         2409
  nkb      =         1134

In your case, if the output stuck here, then it is a problem with the HPC, and not with QE. Also, these are post-processing tools, not actual DFT calculations. So they shouldn't take much time. I am not sure how you are submitting the job, but 768 processor with 6 nodes are too much. I noticed that using more than a single node often create problems in post-processing executables of QE. So, I would suggest to use a single node and then allocate all the CPU you have in 1 node. So, something like the following:

...
#SBATCH -N 1
#SBATCH --ntasks=128
...
mpirun path/to/projwfc.x -in input.in > output.out

If you are submitting the post-processing job along with actual DFT calculations, then you can still do this like below:

...
#SBATCH -N 6
#SBATCH --ntasks=768
...
mpirun path/to/pw.x -in scf.in > scf.out
mpirun -np 128 path/to/projwfc.x -in input.in > output.out

So using the maximum number of allowed CPU (128) with the -np switch allows you to submit a job that allocates multiple nodes for other calculation but uses a single node when performing the post-processign stuff.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .