Re: [QE-users] Question about restarting relaxation jobs

[Yeon, Jejoon]

Thank you so much!!


no don't create it in the submission script, there is no sensible reason to 
create it with the submission script, maybe I have not been clear, the program 
stops as soon as it finds the exit file, if you created it with the submission 
file, the program would stop just after starting without doing nothing. what 
for ?


Hmm I was thinking of use mpirun pw.x ==> sleep command ==> touch or cat 
prefix.EXIT, maybe this wouldn't be a good idea. Thanks to let me know. Now I'm 
very confident about whole restart of QE!


From: users  on behalf of Pietro 
Delugas 
Sent: Monday, July 8, 2019 5:26:52 PM
To: users@lists.quantum-espresso.org
Subject: Re: [QE-users] Question about restarting relaxation jobs


  *   yes you can create the exit file just with a touch command

  *   no don't create it in the submission script, there is no sensible reason 
to create it with the submission script, maybe I have not been clear, the 
program stops as soon as it finds the exit file, if you created it with the 
submission file, the program would stop just after starting without doing 
nothing. what for ?

  *   if you have doubts about the reliability of your saved data it is 
probably better to copy the last positions obtained by you previous run in the 
input and restart from scratch from those coordinates.
  *   if you really want to change prefix (this is another thing which is not 
very frequently needed actually)  just copy the whole prefix.save directory 
into new_prefix.save directory





On 08/07/19 21:22, Yeon, Jejoon wrote:
1) no it's not correct. prefix.EXIT is a file that the user creates to make the 
program stop before completion. When the program finds this file in the outdir 
or in the working directory the program stops writes the restart files and 
deletes prefix.EXIT, so the file is practically never present after the program 
has stopped unless something has gone wrong. To restart a relaxation you just 
need the files contained in the prefix.save directory and possibly the restart 
files.
>> Thanks to let me know. May I ask how to create prefix.EXIT file? Is this an 
>> empty file just with that name, that I can make from shell command in 
>> submission script?

Also, I think my previous jobs were not "cleanly stopped", because I didn't 
used "max_seconds" neither I created any prefix.EXIT file at any moment.  So 
that is why I think my stopped jobs cannot be continued.

But let me try to continue this one.  Inside the prefix.save folder of 
corresponding job, I can only find 3 files: charge-density.dat, 
data-file-schema.xml, and paw.txt. So, I need to copy those files to outdir 
location, and submit restart job with different name of .in and .out file in 
the same folder, and set restart_mode to restart. Right?



2) max_seconds uses the same time as printed in the WALL_TIME which is the time 
elapsed since the job has started CPU_TIME is the time actually used by the CPU 
they differ because a CPU usage is not always 100%, may be less but if you use 
multithreading may also be much larger than 100%. Consider only WALL time to 
keep things simple.
Just look at the seconds the program takes to make an scf loop and set 
smax_seconds to one week minus that time. This already very conservative, no 
need to use a longer time.

3) do not change the prefix name ...
To restart  the program will look for a directory called prefix.save  if you 
change the prefix the program will not be able to read anything...


>> Thank you so much for the answers. Are there any links which explained of 
>> how to restart QE jobs in detail? I searched in user manual and  input file 
>> description webpage but I couldn't find any useful info...

Thank you again!!





From: users 

 on behalf of SISSA 
Sent: Monday, July 8, 2019 2:38:00 PM
To: Quantum ESPRESSO users Forum
Subject: Re: [QE-users] Question about restarting relaxation jobs

1) no it's not correct. prefix.EXIT is a file that the user creates to make the 
program stop before completion. When the program finds this file in the outdir 
or in the working directory the program stops writes the restart files and 
deletes prefix.EXIT, so the file is practically never present after the program 
has stopped unless something has gone wrong. To restart a relaxation you just 
need the files contained in the prefix.save directory and possibly the restart 
files.

2) max_seconds uses the same time as printed in the WALL_TIME which is the time 
elapsed since the job has started CPU_TIME is the time actually used by the CPU 
they differ because a CPU usage is not always 100%, may be less but if you use 
multithreading may also be much larger than 100%. Consider only WALL time to 
keep things simple.
Just look at the seconds the program takes to make an scf loop and set 
smax_seconds to one week minus that time. This already 

Re: [QE-users] Question about restarting relaxation jobs

[Pietro Delugas]

 * yes you can create the exit file just with a touch command

 * no don't create it in the submission script, there is no sensible
   reason to create it with the submission script, maybe I have not
   been clear, the program stops as soon as it finds the exit file, if
   you created it with the submission file, the program would stop just
   after starting without doing nothing. what for ?

 * if you have doubts about the reliability of your saved data it is
   probably better to copy the last positions obtained by you previous
   run in the input and restart from scratch from those coordinates.
 * if you really want to change prefix (this is another thing which is
   not very frequently needed actually) just copy the whole prefix.save
   directory into new_prefix.save directory





On 08/07/19 21:22, Yeon, Jejoon wrote:
1) no it's not correct. prefix.EXIT is a file that the user creates to 
make the program stop before completion. When the program finds this 
file in the outdir or in the working directory the program stops 
writes the restart files and deletes prefix.EXIT, so the file is 
practically never present after the program has stopped unless 
something has gone wrong. To restart a relaxation you just need the 
files contained in the prefix.save directory and possibly the restart 
files.
>> Thanks to let me know. May I ask how to createprefix.EXIT file? Is this an empty file 
just with that name, that I can make from shell command in submission 
script?


Also, I think my previous jobswerenot "cleanly stopped", because I 
didn't used "max_seconds" neither I created any prefix.EXIT file at 
any moment.  So that is why I think my stopped jobs cannot be continued.


But let me try to continue this one. Inside the prefix.save folder of 
corresponding job, I can only find 3 
files: charge-density.dat, data-file-schema.xml, and paw.txt. So, I 
need to copy those files to outdir location, and submit restart job 
with different name of .in and .out file in the same folder, and set 
restart_mode to restart. Right?




2) max_seconds uses the same time as printed in the WALL_TIME which is 
the time elapsed since the job has started CPU_TIME is the time 
actually used by the CPU they differ because a CPU usage is not always 
100%, may be less but if you use multithreading may also be much 
larger than 100%. Consider only WALL time to keep things simple.
Just look at the seconds the program takes to make an scf loop and set 
smax_seconds to one week minus that time. This already very 
conservative, no need to use a longer time.


3) do not change the prefix name ...
To restart  the program will look for a directory called prefix.save  
if you change the prefix the program will not be able to read anything...


>> Thank you so much for the answers. Are there any links which explained of how to restart QE 
jobs in detail? I searched in user manual and input file description 
webpage but I couldn't find any useful info...



Thank you again!!




*From:* users  on behalf of 
SISSA 

*Sent:* Monday, July 8, 2019 2:38:00 PM
*To:* Quantum ESPRESSO users Forum
*Subject:* Re: [QE-users] Question about restarting relaxation jobs
1) no it's not correct. prefix.EXIT is a file that the user creates to 
make the program stop before completion. When the program finds this 
file in the outdir or in the working directory the program stops 
writes the restart files and deletes prefix.EXIT, so the file is 
practically never present after the program has stopped unless 
something has gone wrong. To restart a relaxation you just need the 
files contained in the prefix.save directory and possibly the restart 
files.


2) max_seconds uses the same time as printed in the WALL_TIME which is 
the time elapsed since the job has started CPU_TIME is the time 
actually used by the CPU they differ because a CPU usage is not always 
100%, may be less but if you use multithreading may also be much 
larger than 100%. Consider only WALL time to keep things simple.
Just look at the seconds the program takes to make an scf loop and set 
smax_seconds to one week minus that time. This already very 
conservative, no need to use a longer time.


3) do not change the prefix name ...
To restart  the program will look for a directory called prefix.save  
if you change the prefix the program will not be able to read anything...


Il 8 lug 2019 6:43 PM, "Yeon, Jejoon"  ha scritto:

Thank you so much Pietro


May I ask one more question?


1) This is just double checking question. I checked the folder
where the relaxation was stopped by cluster due to wall time limit
(I didn't set max seconds). In the output folder, I can see
prefix.save/ folder and pwscf.save/ folder, and prefix.update and
prefix.bfgs file. But because I have no prefix.EXIT folder neither
prefix.EXIT file, I cannot restart this simulation. Is this correct?


2) Now I'm setting

Re: [QE-users] Bad scaling on GPU version QE

[Michal Krompiec]

Dear Pietro,
What is the typical speed up vs a cpu-only system? Is this
https://www.dcs.warwick.ac.uk/pmbs/pmbs17/PMBS17/pres/paper3.pdf still
valid? Can you share any benchmarks on V100?
Best,
Michal Krompiec
Merck KGaA, Darmstadt, Germany

On Mon, 8 Jul 2019 at 20:29, Pietro BONFA'  wrote:

> Dear Jing,
>
> good point, I'll add the list of accelerated features in the wiki. In
> the mean time you can check page 21 of the first presentation that you
> can find here: https://gitlab.com/QEF/q-e-gpu/wikis/home#performance
>
> Exact exchange will come with the next release but you can already try
> it by compiling this develop branch:
> https://gitlab.com/QEF/q-e-gpu/tree/gpu-exx
>
> Kind regards,
> Pietro Bonfa'
>
> On 7/8/19 8:33 PM, JING YANG wrote:
> > I am working on the latest version 6.4-a1. I have followed the
> > instructions on the link you provided during the installation. I would
> > like to know which part of the calculation in pw being accelerated by
> > GPU. For example, is it boosting the matrix diagonalization during scf
> > cycles, or boosting the hybrid functional calculations? I am hoping to
> > GPU acceleration can boost up the calculation on the exact exchange in
> > hybrid functional calculations. Is this the case?
> >
> > Thanks,
> > Jing
> >
> > On Mon, Jul 8, 2019 at 1:57 PM Pietro BONFA'  > > wrote:
> >
> > Dear Jing,
> >
> > which GPU-enabled version are you using?
> > GPU support starting from v6.1 is only available when using PGI
> > compilers (well, in principle, any compiler implementing CUDA
> Fortran).
> >
> > You can find additional information here:
> >
> > https://gitlab.com/QEF/q-e-gpu/wikis/home
> >
> > Kinds regards,
> > Pietro Bonfa'
> >
> > On 7/8/19 5:01 PM, JING YANG wrote:
> >  > Hi,
> >  >  I am trying to test the scaling of GPU version of QE
> recently. I
> >  > found out the computational time scaling of the GPU version is
> > very bad.
> >  > Is there any unique flags or keywords I don't know about the GPU
> >  > version? I am using gcc-6.2.0, openmpi-1/8/4,
> > craype-accel-nvidia35. I
> >  > know it is not the recommended set up, but I guess if I can
> > compile it
> >  > successfully, then it should work normally.
> >  >
> >  > Thanks,
> >  > Jing
> >  >
> >  > ___
> >  > Quantum ESPRESSO is supported by MaX
> > (www.max-centre.eu/quantum-espresso
> > )
> >  > users mailing list users@lists.quantum-espresso.org
> > 
> >  > https://lists.quantum-espresso.org/mailman/listinfo/users
> >  >
> >
> >
> > --
> > Pietro Bonfà
> > Department of Mathematical, Physical and Computer Sciences,
> > University of Parma,
> > Italy
> >
> > Firma il tuo 5 per mille all’Università di Parma e aiuta così i
> > nostri studenti che vogliono realizzare un’esperienza di studio
> > all’estero - Indica 00308780345 nella tua denuncia dei redditi.
> > ___
> > Quantum ESPRESSO is supported by MaX
> > (www.max-centre.eu/quantum-espresso
> > )
> > users mailing list users@lists.quantum-espresso.org
> > 
> > https://lists.quantum-espresso.org/mailman/listinfo/users
> >
> >
> > ___
> > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso
> )
> > users mailing list users@lists.quantum-espresso.org
> > https://lists.quantum-espresso.org/mailman/listinfo/users
> >
>
>
> --
> Pietro Bonfà
> Department of Mathematical, Physical and Computer Sciences,
> University of Parma,
> Italy
>
> Firma il tuo 5 per mille all’Università di Parma e aiuta così i nostri
> studenti che vogliono realizzare un’esperienza di studio all’estero -
> Indica 00308780345 nella tua denuncia dei redditi.
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Bad scaling on GPU version QE

[Pietro BONFA']

Dear Jing,

good point, I'll add the list of accelerated features in the wiki. In
the mean time you can check page 21 of the first presentation that you
can find here: https://gitlab.com/QEF/q-e-gpu/wikis/home#performance

Exact exchange will come with the next release but you can already try
it by compiling this develop branch:
https://gitlab.com/QEF/q-e-gpu/tree/gpu-exx

Kind regards,
Pietro Bonfa'

On 7/8/19 8:33 PM, JING YANG wrote:
> I am working on the latest version 6.4-a1. I have followed the
> instructions on the link you provided during the installation. I would
> like to know which part of the calculation in pw being accelerated by
> GPU. For example, is it boosting the matrix diagonalization during scf
> cycles, or boosting the hybrid functional calculations? I am hoping to
> GPU acceleration can boost up the calculation on the exact exchange in
> hybrid functional calculations. Is this the case?
>
> Thanks,
> Jing
>
> On Mon, Jul 8, 2019 at 1:57 PM Pietro BONFA'  > wrote:
>
> Dear Jing,
>
> which GPU-enabled version are you using?
> GPU support starting from v6.1 is only available when using PGI
> compilers (well, in principle, any compiler implementing CUDA Fortran).
>
> You can find additional information here:
>
> https://gitlab.com/QEF/q-e-gpu/wikis/home
>
> Kinds regards,
> Pietro Bonfa'
>
> On 7/8/19 5:01 PM, JING YANG wrote:
>  > Hi,
>  >  I am trying to test the scaling of GPU version of QE recently. I
>  > found out the computational time scaling of the GPU version is
> very bad.
>  > Is there any unique flags or keywords I don't know about the GPU
>  > version? I am using gcc-6.2.0, openmpi-1/8/4,
> craype-accel-nvidia35. I
>  > know it is not the recommended set up, but I guess if I can
> compile it
>  > successfully, then it should work normally.
>  >
>  > Thanks,
>  > Jing
>  >
>  > ___
>  > Quantum ESPRESSO is supported by MaX
> (www.max-centre.eu/quantum-espresso
> )
>  > users mailing list users@lists.quantum-espresso.org
> 
>  > https://lists.quantum-espresso.org/mailman/listinfo/users
>  >
>
>
> --
> Pietro Bonfà
> Department of Mathematical, Physical and Computer Sciences,
> University of Parma,
> Italy
>
> Firma il tuo 5 per mille all’Università di Parma e aiuta così i
> nostri studenti che vogliono realizzare un’esperienza di studio
> all’estero - Indica 00308780345 nella tua denuncia dei redditi.
> ___
> Quantum ESPRESSO is supported by MaX
> (www.max-centre.eu/quantum-espresso
> )
> users mailing list users@lists.quantum-espresso.org
> 
> https://lists.quantum-espresso.org/mailman/listinfo/users
>
>
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
>


--
Pietro Bonfà
Department of Mathematical, Physical and Computer Sciences,
University of Parma,
Italy

Firma il tuo 5 per mille all’Università di Parma e aiuta così i nostri studenti 
che vogliono realizzare un’esperienza di studio all’estero - Indica 00308780345 
nella tua denuncia dei redditi.
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Question about restarting relaxation jobs

[Yeon, Jejoon]

1) no it's not correct. prefix.EXIT is a file that the user creates to make the 
program stop before completion. When the program finds this file in the outdir 
or in the working directory the program stops writes the restart files and 
deletes prefix.EXIT, so the file is practically never present after the program 
has stopped unless something has gone wrong. To restart a relaxation you just 
need the files contained in the prefix.save directory and possibly the restart 
files.
>> Thanks to let me know. May I ask how to create prefix.EXIT file? Is this an 
>> empty file just with that name, that I can make from shell command in 
>> submission script?

Also, I think my previous jobs were not "cleanly stopped", because I didn't 
used "max_seconds" neither I created any prefix.EXIT file at any moment.  So 
that is why I think my stopped jobs cannot be continued.

But let me try to continue this one.  Inside the prefix.save folder of 
corresponding job, I can only find 3 files: charge-density.dat, 
data-file-schema.xml, and paw.txt. So, I need to copy those files to outdir 
location, and submit restart job with different name of .in and .out file in 
the same folder, and set restart_mode to restart. Right?



2) max_seconds uses the same time as printed in the WALL_TIME which is the time 
elapsed since the job has started CPU_TIME is the time actually used by the CPU 
they differ because a CPU usage is not always 100%, may be less but if you use 
multithreading may also be much larger than 100%. Consider only WALL time to 
keep things simple.
Just look at the seconds the program takes to make an scf loop and set 
smax_seconds to one week minus that time. This already very conservative, no 
need to use a longer time.

3) do not change the prefix name ...
To restart  the program will look for a directory called prefix.save  if you 
change the prefix the program will not be able to read anything...


>> Thank you so much for the answers. Are there any links which explained of 
>> how to restart QE jobs in detail? I searched in user manual and  input file 
>> description webpage but I couldn't find any useful info...

Thank you again!!





From: users  on behalf of SISSA 

Sent: Monday, July 8, 2019 2:38:00 PM
To: Quantum ESPRESSO users Forum
Subject: Re: [QE-users] Question about restarting relaxation jobs

1) no it's not correct. prefix.EXIT is a file that the user creates to make the 
program stop before completion. When the program finds this file in the outdir 
or in the working directory the program stops writes the restart files and 
deletes prefix.EXIT, so the file is practically never present after the program 
has stopped unless something has gone wrong. To restart a relaxation you just 
need the files contained in the prefix.save directory and possibly the restart 
files.

2) max_seconds uses the same time as printed in the WALL_TIME which is the time 
elapsed since the job has started CPU_TIME is the time actually used by the CPU 
they differ because a CPU usage is not always 100%, may be less but if you use 
multithreading may also be much larger than 100%. Consider only WALL time to 
keep things simple.
Just look at the seconds the program takes to make an scf loop and set 
smax_seconds to one week minus that time. This already very conservative, no 
need to use a longer time.

3) do not change the prefix name ...
To restart  the program will look for a directory called prefix.save  if you 
change the prefix the program will not be able to read anything...

Il 8 lug 2019 6:43 PM, "Yeon, Jejoon"  ha scritto:

Thank you so much Pietro


May I ask one more question?


1) This is just double checking question. I checked the folder where the 
relaxation was stopped by cluster due to wall time limit (I didn't set max 
seconds). In the output folder, I can see prefix.save/ folder and pwscf.save/ 
folder, and prefix.update and prefix.bfgs file. But because I have no 
prefix.EXIT folder neither prefix.EXIT file, I cannot restart this simulation. 
Is this correct?


2) Now I'm setting "max_seconds" to all my QE DFT works. But I found that CPU 
time and wall time is slightly different. From my recent finished calculation, 
it is written at the end of the  output file:

PWSCF:   4d21h44m CPU   4d22h12m WALL
   This run was terminated on:  21:27:26   1Jul2019

I used 30 cores, and set 7 days of wall time. Simulation finished before wall 
time, but I'm not sure why this slight difference of CPU time and wall time 
occur.
In this case, what would be the good time of max seconds CPU time when compared 
to wall time? If I request 7 days of wall time to cluster, then would it be 
more "safe" to set 6 days or 6.5 days of CPU time for max seconds?


3) This is also double checking question. If I wish to start the restart in 
same folder, I would better to change prefix from "SimulatinoA" to 
"SimulationA_restart1", would it be OK?  Also, if I wish to use different 
folder, I nee

Re: [QE-users] Question about restarting relaxation jobs

[SISSA]

1) no it's not correct. prefix.EXIT is a file that the user creates to make the program stop before completion. When the program finds this file in the outdir or in the working directory the program stops writes the restart files and deletes prefix.EXIT, so the file is practically never present after the program has stopped unless something has gone wrong. To restart a relaxation you just need the files contained in the prefix.save directory and possibly the restart files.2) max_seconds uses the same time as printed in the WALL_TIME which is the time elapsed since the job has started CPU_TIME is the time actually used by the CPU they differ because a CPU usage is not always 100%, may be less but if you use multithreading may also be much larger than 100%. Consider only WALL time to keep things simple. Just look at the seconds the program takes to make an scf loop and set smax_seconds to one week minus that time. This already very conservative, no need to use a longer time. 3) do not change the prefix name ...To restart  the program will look for a directory called prefix.save  if you change the prefix the program will not be able to read anything...Il 8 lug 2019 6:43 PM, "Yeon, Jejoon"  ha scritto:

Thank you so much Pietro 


May I ask one more question? 


1) This is just double checking question. I checked the folder where the relaxation was stopped by cluster due to wall time limit (I didn't set max seconds). In the output folder, I can
 see prefix.save/ folder and pwscf.save/ folder, and prefix.update and prefix.bfgs file. But because I have no prefix.EXIT folder neither prefix.EXIT file, I cannot restart this simulation. Is this correct? 


2) Now I'm setting "max_seconds" to all my QE DFT works. But I found that CPU time and wall time is slightly different. From my recent finished calculation,
 it is written at the end of the  output file: 


PWSCF        :   4d21h44m CPU   4d22h12m WALL

   This run was terminated on:  21:27:26   1Jul2019



I used 30 cores, and set 7 days of wall time. Simulation finished before wall time, but I'm not sure why this slight difference of CPU time and wall time occur.  
In this case, what would be the good time of max seconds CPU time when compared to wall time? If I request 7 days of wall time to cluster, then would
 it be more "safe" to set 6 days or 6.5 days of CPU time for max seconds?  



3) This is also double checking question. If I wish to start the restart in same folder, I would better to change prefix from "SimulatinoA" to "SimulationA_restart1", would it be OK?  Also, if I wish to use different
 folder, I need to copy entire files inside prefix.EXIT folder to
 the new restart folder, is this correct? 


Thank you so much for friendly
 answers to beginner question!! 




From: users  on behalf of Pietro Davide Delugas 
Sent: Monday, July 8, 2019 4:14:06 AM
To: users@lists.quantum-espresso.org
Subject: Re: [QE-users] Question about restarting relaxation jobs
 


Hello 



1)  and 2) PW writes the restart files only when it terminates before convergence is reached either because the max number of steps (and the  max number may be  either the number of  electronic steps during scf of  number of ionic
 steps during structural relaxation) or the the execution time exceed  max_seconds specified in input or because the user has stopped the calculation creating a file in the outdir called prefix.EXIT. 




If restart_mode in &control is set to "restart"  pw will try to restart the relaxation from the last POSITIONS  which have been saved in the prefix.save directory using the last saved charge density and wave functions. If it finds
 the restart files it will use them also. This mechanism works fine if positions, charge density and wave functions  data have been saved regularly,  but if the calculation is going to be stopped abruptly, for example by the job manager,  there is no way to
 prevent that the stop arrives when the program is writing these data. The safer way to go when you are using a job manager is to set the max_seconds variable to a number consistently lower than the time allocated by the job manager, the difference between
 these two times should be enough to allow to the program to pass through one of the check_points at which, during execution, it checks if the execution time has exceeded the max_seconds s or if the user has created a prefix.EXIT file. To estimate how long
 should be the difference between max_seconds and the scheduled execution time check how long it takes to the program to make an scf loop, this one will  a very safe estimate, you could reduce this time significantly and things should be working.








3) I don't understans what you want to do. You create the prefix.EXIT file when you want to stop your calculation and you want the calculation to finish smoothly saving all restart information so that it can resatart from more
 or less the same point when it was interrupted. It is completely senseless to rename  the output file

Re: [QE-users] Bad scaling on GPU version QE

[JING YANG]

I am working on the latest version 6.4-a1. I have followed the instructions
on the link you provided during the installation. I would like to know
which part of the calculation in pw being accelerated by GPU. For example,
is it boosting the matrix diagonalization during scf cycles, or boosting
the hybrid functional calculations? I am hoping to GPU acceleration can
boost up the calculation on the exact exchange in hybrid functional
calculations. Is this the case?

Thanks,
Jing

On Mon, Jul 8, 2019 at 1:57 PM Pietro BONFA'  wrote:

> Dear Jing,
>
> which GPU-enabled version are you using?
> GPU support starting from v6.1 is only available when using PGI
> compilers (well, in principle, any compiler implementing CUDA Fortran).
>
> You can find additional information here:
>
> https://gitlab.com/QEF/q-e-gpu/wikis/home
>
> Kinds regards,
> Pietro Bonfa'
>
> On 7/8/19 5:01 PM, JING YANG wrote:
> > Hi,
> >  I am trying to test the scaling of GPU version of QE recently. I
> > found out the computational time scaling of the GPU version is very bad.
> > Is there any unique flags or keywords I don't know about the GPU
> > version? I am using gcc-6.2.0, openmpi-1/8/4, craype-accel-nvidia35. I
> > know it is not the recommended set up, but I guess if I can compile it
> > successfully, then it should work normally.
> >
> > Thanks,
> > Jing
> >
> > ___
> > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso
> )
> > users mailing list users@lists.quantum-espresso.org
> > https://lists.quantum-espresso.org/mailman/listinfo/users
> >
>
>
> --
> Pietro Bonfà
> Department of Mathematical, Physical and Computer Sciences,
> University of Parma,
> Italy
>
> Firma il tuo 5 per mille all’Università di Parma e aiuta così i nostri
> studenti che vogliono realizzare un’esperienza di studio all’estero -
> Indica 00308780345 nella tua denuncia dei redditi.
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Bad scaling on GPU version QE

[Pietro BONFA']

Dear Jing,

which GPU-enabled version are you using?
GPU support starting from v6.1 is only available when using PGI
compilers (well, in principle, any compiler implementing CUDA Fortran).

You can find additional information here:

https://gitlab.com/QEF/q-e-gpu/wikis/home

Kinds regards,
Pietro Bonfa'

On 7/8/19 5:01 PM, JING YANG wrote:
> Hi,
>  I am trying to test the scaling of GPU version of QE recently. I
> found out the computational time scaling of the GPU version is very bad.
> Is there any unique flags or keywords I don't know about the GPU
> version? I am using gcc-6.2.0, openmpi-1/8/4, craype-accel-nvidia35. I
> know it is not the recommended set up, but I guess if I can compile it
> successfully, then it should work normally.
>
> Thanks,
> Jing
>
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
>


--
Pietro Bonfà
Department of Mathematical, Physical and Computer Sciences,
University of Parma,
Italy

Firma il tuo 5 per mille all’Università di Parma e aiuta così i nostri studenti 
che vogliono realizzare un’esperienza di studio all’estero - Indica 00308780345 
nella tua denuncia dei redditi.
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Question about restarting relaxation jobs

[Yeon, Jejoon]

Thank you so much Pietro


May I ask one more question?


1) This is just double checking question. I checked the folder where the 
relaxation was stopped by cluster due to wall time limit (I didn't set max 
seconds). In the output folder, I can see prefix.save/ folder and pwscf.save/ 
folder, and prefix.update and prefix.bfgs file. But because I have no 
prefix.EXIT folder neither prefix.EXIT file, I cannot restart this simulation. 
Is this correct?


2) Now I'm setting "max_seconds" to all my QE DFT works. But I found that CPU 
time and wall time is slightly different. From my recent finished calculation, 
it is written at the end of the  output file:

PWSCF:   4d21h44m CPU   4d22h12m WALL
   This run was terminated on:  21:27:26   1Jul2019

I used 30 cores, and set 7 days of wall time. Simulation finished before wall 
time, but I'm not sure why this slight difference of CPU time and wall time 
occur.
In this case, what would be the good time of max seconds CPU time when compared 
to wall time? If I request 7 days of wall time to cluster, then would it be 
more "safe" to set 6 days or 6.5 days of CPU time for max seconds?


3) This is also double checking question. If I wish to start the restart in 
same folder, I would better to change prefix from "SimulatinoA" to 
"SimulationA_restart1", would it be OK?  Also, if I wish to use different 
folder, I need to copy entire files inside prefix.EXIT folder to the new 
restart folder, is this correct?


Thank you so much for friendly answers to beginner question!!


From: users  on behalf of Pietro 
Davide Delugas 
Sent: Monday, July 8, 2019 4:14:06 AM
To: users@lists.quantum-espresso.org
Subject: Re: [QE-users] Question about restarting relaxation jobs

Hello

1)  and 2) PW writes the restart files only when it terminates before 
convergence is reached either because the max number of steps (and the  max 
number may be  either the number of  electronic steps during scf of  number of 
ionic steps during structural relaxation) or the the execution time exceed  
max_seconds specified in input or because the user has stopped the calculation 
creating a file in the outdir called prefix.EXIT.

If restart_mode in &control is set to "restart"  pw will try to restart the 
relaxation from the last POSITIONS  which have been saved in the prefix.save 
directory using the last saved charge density and wave functions. If it finds 
the restart files it will use them also. This mechanism works fine if 
positions, charge density and wave functions  data have been saved regularly,  
but if the calculation is going to be stopped abruptly, for example by the job 
manager,  there is no way to prevent that the stop arrives when the program is 
writing these data. The safer way to go when you are using a job manager is to 
set the max_seconds variable to a number consistently lower than the time 
allocated by the job manager, the difference between these two times should be 
enough to allow to the program to pass through one of the check_points at 
which, during execution, it checks if the execution time has exceeded the 
max_seconds s or if the user has created a prefix.EXIT file. To estimate how 
long should be the difference between max_seconds and the scheduled execution 
time check how long it takes to the program to make an scf loop, this one will  
a very safe estimate, you could reduce this time significantly and things 
should be working.



3) I don't understans what you want to do. You create the prefix.EXIT file when 
you want to stop your calculation and you want the calculation to finish 
smoothly saving all restart information so that it can resatart from more or 
less the same point when it was interrupted. It is completely senseless to 
rename  the output file as prefix.EXIT because it will make the program to stop 
as soon as a check_point detects the file and the file will be deleted. The 
only thing that you have to do when restarting a calculation is

  * Specify restart_mode = 'restart' in the input.in file

  * take care that the information saved in output.out is not rewritten by 
the new execution just use something as mpirun pw.x  < input.in >> 
output.out which appends the new output to the old one or redirect the output 
to files with different names

4)   outdir must be the same or if you want to use a different one you have to 
create the new outdir befor restarting and copy there all the data of the 
previous calculation i.e. the prefix.save directory.


5) don't complicate things too much



Pietro


On 7/6/19 3:59 PM, Yeon, Jejoon wrote:

Hello


I have very small amount of experience using QE, so please excuse my beginner 
question. I'm about to start relaxation of big crystal structure, and I wish to 
make my QE relaxation jobs ready for restart. Here are my questions:


1) According to "restarting" section from manual, 
(https://www.quantum-espresso.org/Doc/pw_user_guide/node20.html) it seems tha

Re: [QE-users] users Digest, Vol 144, Issue 3

[Anuja Chanana]

Dear Pietro,
Thanks for the reply.
Is there any special requirement of pseudopotential for running epsilon.x?
For e.g. can we use PAW or USPP pseudopotentials for epsilon.x calculations?

Thanks and Regards
Anuja




On Wed, Jul 3, 2019 at 3:30 PM 
wrote:

> Send users mailing list submissions to
> users@lists.quantum-espresso.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.quantum-espresso.org/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-requ...@lists.quantum-espresso.org
>
> You can reach the person managing the list at
> users-ow...@lists.quantum-espresso.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
> Re: Calculation of epsilon.x (Pietro Delugas)
>
> --
>
> Message: 1
> Date: Tue, 2 Jul 2019 15:05:01 +0200
> From: Pietro Delugas 
> To: users@lists.quantum-espresso.org
> Subject: Re: [QE-users] Calculation of epsilon.x
> Message-ID: <634b7dac-be64-90b9-b3a1-d2ca92dca...@sissa.it>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Dear Anuja
>
> the calculation with a very dense k-point mesh is most likely looping
> through the k points and taking a lot of time before printing out anything.
>
> It is not necessary though to run the scf calculation with the very fine
> mesh; it is sufficient to run the scf calculation with a feaisble k
> point mesh for which you are confident to be at convergens, once done
> the scf calculation with the feasible converged mesh? you may run? nscf
> calculation with the finer mesh that you? need for the epsilon.x
> calculation.
>
> To speed up the calculation you may try to use the k-point parallelism:
> in suppose that you are using 20 MPI processes and that 4 of them are
> sufficient to run the iterative diagonalization for one k point, you can
> divide your 20 MPI processes in 5 pools each diagonalizing and assigned
> subset of the total k points. To do this you just have to run your pw.x
> command as:
>
> mpirun -np 20 pw.x -nk 5 -i input_nscf > out_nscf
>
> I hope this helps.
>
> kind regards - Pietro
>
> On 01/07/19 17:44, Anuja Chanana wrote::
> > Dear all,
> > I am trying to run epsilon.x by reading the following tutorial
> >
> https://www.paradim.org/sites/default/files/2019-05/Band_Structure_and_UV-VIS_Spectra.pdf
> >
> >
> > The manual says that for the calculation of epsilon, a finer-k mesh is
> > required like 30x30x30.
> > I have a triclinic system where
> > a = 6.3 A? b = 6.5 A? c = 5.9 A
> > alpha 121.358? beta 88.3349? gamma 106.391
> >
> > If I increase the k-mesh to 30x30x30, the initial scf simulation
> > doesn't run at all.
> > Nothing gets written. Why does that happen?
> > Has anyone experienced it before?
> >
> > Thanks
> > Anuja
> >
> >
> > Mailtrack
> > <
> https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;>
>
> >   Sender notified by
> > Mailtrack
> > <
> https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;>
>
> > 07/01/19, 09:14:40 PM
> >
> >
> > ___
> > Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso
> )
> > users mailing list users@lists.quantum-espresso.org
> > https://lists.quantum-espresso.org/mailman/listinfo/users
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.quantum-espresso.org/pipermail/users/attachments/20190702/78ffe1e6/attachment-0001.html
> >
>
> --
>
>
>
> --
> This email was Anti Virus checked by  Security Gateway.
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.quantum-espresso.org/pipermail/users/attachments/20190702/4f38b1bb/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> users mailing list
> users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
>
> --
>
>
>
[image: Mailtrack]

Sender
notified by
Mailtrack

07/08/19,
09:40:07 PM
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] Bad scaling on GPU version QE

[JING YANG]

Hi,
I am trying to test the scaling of GPU version of QE recently. I found
out the computational time scaling of the GPU version is very bad. Is there
any unique flags or keywords I don't know about the GPU version? I am using
gcc-6.2.0, openmpi-1/8/4, craype-accel-nvidia35. I know it is not the
recommended set up, but I guess if I can compile it successfully, then it
should work normally.

Thanks,
Jing
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] cell_dofree = 'volume'

[Paolo Giannozzi]

On Sat, Jul 6, 2019 at 11:31 AM Carlo Nervi  wrote:

I'd like to perform vc-relax calculations, but keeping strictly fixed the
> symmetry of the crystal.
>

not sure I understand: if the starting structure has the desired crystal
symmetry, the final structure will - apart from unfortunate or pathological
cases - have the same symmetry

Paolo




> I supposed that the keyword
> cell_dofree='volume'
> should be the right option to use, but pw.x exit complaining that
> cell_dofree='volume' can be used only if ibrav=1.
> Is there any technical reasons for this?
> I was supposing that simply changing only celldm(1) should work.
>
> I tried, as alternative, cell_dynamics='damp-w', which apparently keep
> almost the symmetry (but not strictly), but it shows an extremely slow
> convergence (in my molecular crystal vc-relax converge in 17 bfgs steps,
> while the damp-w vc-relax calculation is currently running the 127th step).
>
> Thank you,
> Carlo
>
> P.S.: I suppose that simple deleting the below bold rows in cell_base.f90
> (subroutine init_dofree) would not work..
>
> CASE ( 'volume' )
>   !CALL errore(' init_dofree ', &
>   !   ' cell_dofree = '//TRIM(cell_dofree)//' not yet
> implemented ', 1 )
>  * IF ( ibrav /= 1 ) THEN*
> *CALL errore('cell_dofree', 'Isotropic expansion is only
> allowed for ibrav=1; i.e. for simple cubic', 1)*
> *  END IF*
>   iforceh  = 0
>   iforceh(1,1) = 1
>   iforceh(2,2) = 1
>   iforceh(3,3) = 1
>   isotropic= .TRUE.
>
> --
>
> 
> Prof. Carlo Nervi carlo.ne...@unito.it  Tel:+39 0116707507/8
> Fax: +39 0116707855  -  Dipartimento di Chimica, via
> P. Giuria 7, 10125 Torino, Italy.http://lem.ch.unito.it/
>
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users



-- 
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
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] segfault with HSE06

[Michal Krompiec]

Hello,
I'm getting a segmentation fault when trying to run a HSE06 SCF calculation
in QE 6.4rc (built with gcc and OpenMPI). I got the same result regardless
of number of OMP threads (1-2) or MPI processes, it is also not because I'm
running out of memory. Increasing OMP_STACK_SIZE didn't help.
I'm using SG15 norm-conserving pseudopotentials.
This is the error message:

Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.

Backtrace for this error:

Backtrace for this error:
#0  0x2ba41caf6607 in ???
#1  0x2ba41caf586d in ???
#2  0x2ba41d9d5fdf in ???
#1  0x2ba41caf586d in ???
#2  0x2ba41d9d5fdf in ???
#3  0x481031 in __exx_MOD_exxinit._omp_fn.41
at
/home/hpcadmin/Cluster-packages/Apps/QE/q-e-qe-6.4-rc/PW/src/exx.f90:471


And this is the input file:
&CONTROL
   nstep= 150
   prefix   = 'pz'
   calculation = 'scf'
/
&SYSTEM
   ecutwfc  = 60
   ecutrho  = 240
   occupations  = 'smearing'
   degauss  = 0.03
   smearing = 'marzari-vanderbilt'
   assume_isolated  = '2D'
   ntyp = 3
   nat  = 10
   ibrav= 0
   vdw_corr='dft-d3'
   nosym = .true.
   input_dft = 'hse'
   localization_thr = 0.005

/
&ELECTRONS
electron_maxstep = 1000
mixing_mode  = 'plain'
mixing_beta = 0.3
mixing_ndim = 10
/
&IONS
ion_dynamics = 'bfgs'
/

ATOMIC_SPECIES
H 1 H_ONCV_PBE-1.0.upf
C 12 C_ONCV_PBE-1.0.upf
N 14 N_ONCV_PBE-1.0.upf

K_POINTS automatic
3 3 1  0 0 0

CELL_PARAMETERS angstrom
9.45 0.00 0.0
0.00 8.90954544295050 0.0
0.00 0.00 40.0

ATOMIC_POSITIONS angstrom
N3.220157348   4.070243213   7.161850862
C2.057591707   4.250681378   7.817575738
C4.333273229   4.171146830   7.913403134
C2.009345068   4.525337360   9.193044239
C4.285082283   4.446195607   9.288766365
N3.122476937   4.626559339   9.944547282
H1.139008253   4.174089393   7.227702259
H5.290517910   4.028527369   7.402554504
H1.052120461   4.668162403   9.703968061
H5.203598139   4.523590493   9.878655120


I would be grateful for any suggestions. In the meantime, we are upgrading
to 6.4.1 to see if this helps.

Best regards,

Michal Krompiec

Merck KGaA, Darmstadt, Germany & University of Southampton
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Inconsistency of vc-relax output file

[Bharat Thapa]

Dear Paolo,

Sorry for the late reply, however, I am wondering in this case, how do I
calculate the vc-relaxed lattice parameter? If it were cubic I would have
multiplied the output CELL_PARAMETER with the lattice and divided by 0.5.
But, as it is hexagonal (input) how do I figure out the relaxed lattice
parameters? Also, I want to know if the symmetry (hexagonal) has been lost.
How do I know the output file retains the input symmetry? The way I do is
by looking the the CELL_PARAMETER. But in this case the output
CELL_PARAMETER is not exactly representing that of ibrav= 4 but is somewhat
closer.
Please enlighten me on this; I am struggling a lot.

Thank you!

*Bharat Thapa*


On Mon, Mar 25, 2019 at 7:27 AM Paolo Giannozzi 
wrote:

> Is the problem here the loss of the original symmetry of the lattice? if
> hexagonal symmetry was present in the starting structure, it isn't lost at
> the end (apart from pathological or unfortunate cases). If hexagonal
> symmetry was not present in the starting structure, the final lattice may
> no longer be hexagonal
>
> Paolo
>
>
> On Sat, Mar 23, 2019 at 7:05 AM Bharat Thapa  wrote:
>
>> Dear developer,
>>
>>
>>
>> I have vc-relaxed Hf7O8N4 (hafnium oxynitride) assuming the crystal to be
>> rhombohedra with a=b, alpha=beta=90 deg, and gamma=120 deg. So, I used
>> ibrav=4 and gave A,B,C, cosAB, cosAC and cosBC values. Part of the input
>> looks as follows:
>>
>>
>>
>> *&system*
>>
>> *ibrav=  4   *
>>
>> *A=9.4851, B=9.4851, C=8.7867, cosAB=-0.5, cosAC=0.0, cosBC=0.0*
>>
>> *nat=19  , ntyp= 3,*
>>
>> *ecutwfc =70, ecutrho= 840, *
>>
>> *occupations= 'fixed', *
>>
>> *nbnd= 100 *
>>
>>
>>
>> The vc-relax ran successfully and I got the following output:
>>
>>
>>
>> *Final enthalpy =   -5322.7186767755 Ry*
>>
>> *Begin final coordinates*
>>
>> * new unit-cell volume =   1536.19292 a.u.^3 (   227.64030 Ang^3 )*
>>
>>
>>
>> *CELL_PARAMETERS (alat= 17.92424134)*
>>
>> *   0.638651125   0.103631841  -0.047929083*
>>
>> *  -0.23587   0.630643088  -0.049740867*
>>
>> *  -0.043220738  -0.085864416   0.635634338*
>>
>>
>>
>> Here, the output cell_parameter values are not consistent with the input.
>> I assumed it as ibrav=4 (hex or rhombohedra), but if I use the output
>> cell_parameter and calculated the final value (using the vector formulas
>> for ibrav=4 from pw.x documentation) for lattice constant ‘a’, I will get
>> different values from different vectors. So, my question is how do we
>> analyse such a system in which we give certain crystal structure as an
>> input and the vc-relax runs successfully (*does not crash*) and give an
>> output which isn’t consistent with the input crystal system? Can I accept
>> the results and carry on further because the vc-relax did not crash meaning
>> that everything is fine?
>>
>>
>>
>> Please help me in this regard.
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> Bharat Thapa
>>
>> PhD student
>>
>> UNSW
>> ___
>> users mailing list
>> users@lists.quantum-espresso.org
>> https://lists.quantum-espresso.org/mailman/listinfo/users
>
>
>
> --
> 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
>
> ___
> users mailing list
> users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] Interpreting vc-relax output

[Bharat Thapa]

Dear Developer,

I was running vc-relax of Hf3N4. The input parameters are for body centered
cubic crystal: space group I-43d (group 220 of the international table of
crystallography). I used this space group for the positions of Hf and N
atoms. The main thing I want to ask is: after vc-relax the CELL_PARAMETERS
values which are for ibrav= -3 changed such that all diagonal elements are
same but different to all non-diagonal elements ,however, the non-diagonal
elements are same to each other. I think, if they all were same then that
would mean the unit cell is either shrink or expanded which would make it
easy to calculated the final (relaxed) lattice constant. But, in this case
where it has different numbers for diagonal and non-diagonal, how do I
interpret it? Is it still a cubic lattice? or it is trigonal now? I think I
can not change the atomic positions otherwise I would lose the symmetry.
What do I do now? Is it true that vc-relax may change the atomic positions
but it will not change the crystal symmetry or the space group?

Input:





























































*&controlcalculation = 'vc-relax',restart_mode = 'from_scratch',
forc_conv_thr = 1.0D-5,tstress = .true.,tprnfor = .true.,prefix
= 'Hf3N4_vr3' ,pseudo_dir =
'/home/z5126106/QEspresso_bin/Pseudopotentials',outdir =
'/share/scratch/z5126106/TempFiles',verbosity = 'high'!disk_io =
"none"  /  &systemibrav = 0, celldm(1) = 12.69, !materialsproject
  nat = 14,ntyp = 2,ecutwfc = 60,ecutrho = 720 nbnd = 80
occupations = 'fixed'  /  &electronsconv_thr = 1.0d-11,mixing_mode
= 'plain',mixing_ndim = 10,mixing_beta = 0.3  /  &ions
ion_dynamics =  "bfgs",bfgs_ndim= 3  /  &cellcell_dynamics =
"bfgs",press_conv_thr = 0.1D0,cell_dofree = "all"cell_factor =
5  /CELL_PARAMETERS alat ! ibrav = -3 -0.5000 0.5000 0.5000 0.5000 -0.5000
0.5000 0.5000 0.5000 -0.5000ATOMIC_SPECIES Hf 178.49
Hf.pbe-spn-kjpaw_psl.1.0.0.UPF N 14.0067 N.pbe-n-kjpaw_psl.1.0.0.UPF
ATOMIC_POSITIONS alat !crystal Hf   0.37500   0.0
0.25000 0 0 0   Hf   0.12500   0.0   0.75000 0 0
0Hf   0.25000   0.37500   0.0 0 0 0 Hf
0.75000   0.12500   0.0 0 0 0Hf   0.0
0.25000   0.37500 0 0 0Hf   0.0   0.75000
0.12500 0 0 0N0.09980   0.09980   0.09980 N
 0.40020   -0.0998   0.59980 N-0.0998   0.59980
  0.40020 N0.59980   0.40020  -0.09980 N
 0.34980   0.34980   0.34980 N0.15020   0.65020
  0.84980 N0.84980   0.15020   0.65020 N
 0.65020   0.84980   0.15020 K_POINTS automatic 6 6 6 1 1 1*

Output:































*Begin final coordinates new unit-cell volume =   1718.69533 a.u.^3 (
254.68437 Ang^3 )CELL_PARAMETERS (alat= 12.6900)  -0.426131582
0.607025249   0.607025249   0.607025249  -0.426131582   0.607025249
 0.607025249   0.607025249  -0.426131582ATOMIC_POSITIONS (crystal)Hf
0.37500  -0.0   0.250000   0   0Hf   0.12500
0.0   0.750000   0   0Hf   0.25000   0.37500
0.00   0   0Hf   0.75000   0.12500  -0.0
 0   0   0Hf  -0.0   0.25000   0.375000   0   0Hf
0.0   0.75000   0.125000   0   0N
 0.048570739   0.048570739   0.048570739N0.146441100  -0.104982446
  0.427330131N   -0.104982446   0.427330131   0.146441100N
 0.427330131   0.146441100  -0.104982446N0.309957583   0.309957583
  0.309957583N0.262463403   0.707381916   1.020329856N
 1.020329856   0.262463403   0.707381916N0.707381916   1.020329856
  0.262463403End final coordinates A final scf calculation at the
relaxed structure. The G-vectors are recalculated for the final unit
cell Results may differ from those at the preceding step. *
Regards,


*Bharat Thapa*
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Projected Bands

[Soumyadeep]

Dear Anuja,

  Yes it is implemented in Quantum Espresso. Try with projwfc.x 
executable.


with regards
Soumyadeep
---
Soumyadeep Ghosh,
Senior Research Fellow,
Homi Bhabha National Institute (HBNI),
Raja Ramanna Centre for Advanced Technology, Indore, India-452013
Mob: (+91)9424664553
User Lab: 0731244-2580
Email: soumyadeepghos...@gmail.com, soumyad...@rrcat.gov.in
---


On 08-07-2019 12:48, Anuja Chanana wrote:

Dear all,
Do we have the feature of projected bands in Quantum Espresso?

Thanks and Regards,
Anuja Chanana

 [1]
 Sender notified by
Mailtrack [1] 07/08/19, 12:47:59 PM 



Links:
--
[1]
https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;
___
Quantum ESPRESSO is supported by MaX 
(www.max-centre.eu/quantum-espresso)

users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Question about restarting relaxation jobs

[Pietro Davide Delugas]

Hello

1)  and 2) PW writes the restart files only when it terminates before 
convergence is reached either because the max number of steps (and the  
max number may be either the number of  electronic steps during scf of  
number of ionic steps during structural relaxation) or the the execution 
time exceed  max_seconds specified in input or because the user has 
stopped the calculation creating a file in the outdir called prefix.EXIT.


If restart_mode in &control is set to "restart"  pw will try to restart 
the relaxation from the last POSITIONS  which have been saved in the 
prefix.save directory using the last saved charge density and wave 
functions. If it finds the restart files it will use them also. This 
mechanism works fine if positions, charge density and wave functions  
data have been saved regularly,  but if the calculation is going to be 
stopped abruptly, for example by the job manager,  there is no way to 
prevent that the stop arrives when the program is writing these data. 
The safer way to go when you are using a job manager is to set the 
max_seconds variable to a number consistently lower than the time 
allocated by the job manager, the difference between these two times 
should be enough to allow to the program to pass through one of the 
check_points at which, during execution, it checks if the execution time 
has exceeded the max_seconds s or if the user has created a prefix.EXIT 
file. To estimate how long should be the difference between max_seconds 
and the scheduled execution time check how long it takes to the program 
to make an scf loop, this one will  a very safe estimate, you could 
reduce this time significantly and things should be working.




3) I don't understans what you want to do. You create the prefix.EXIT 
file when you want to stop your calculation and you want the calculation 
to finish smoothly saving all restart information so that it can 
resatart from more or less the same point when it was interrupted. It is 
completely senseless to rename  the output file as prefix.EXIT because 
it will make the program to stop as soon as a check_point detects the 
file and the file will be deleted. The only thing that you have to do 
when restarting a calculation is


 *    Specify restart_mode = 'restart' in the input.in file

 *    take care that the information saved in output.out is not
   rewritten by the new execution just use something as mpirun pw.x 
   < input.in >> output.out which appends the new output to the old one
   or redirect the output to files with different names

4)   outdir must be the same or if you want to use a different one you 
have to create the new outdir befor restarting and copy there all the 
data of the previous calculation i.e. the prefix.save directory.



5) don't complicate things too much



Pietro



On 7/6/19 3:59 PM, Yeon, Jejoon wrote:


Hello


I have very small amount of experience using QE, so please excuse my 
beginner question. I'm about to start relaxation of big crystal 
structure, and I wish to make my QE relaxation jobs ready for restart. 
Here are my questions:



1) According to "restarting" section from manual, 
(https://www.quantum-espresso.org/Doc/pw_user_guide/node20.html) it 
seems that QE does not creates the dedicated restart file, is this 
correct?



2) If I set up "max_seconds" option as 604800 seconds (1 week), and 
request wall time to server 1 week, do my calculation jobs are ready 
to restart after 1 week? (1 week is just example but our server 
cluster have maximum some walltime limitation, and I don't think any 
of my relaxation works will be finished within that time. ) Also, does 
this "max_seconds" option must be required to restart?


3) When I execute QE in the submit script, I use something similar as:
mpirun pw.x  < input.in > output.out
In this case, if the relaxation job is killed due to wall time limit 
(without setting max_seconds), can I just change the name of the 
output.out to prefix.EXIT, (of course I set up prefix in the input 
file) and then include restart_mode = "restart" in the input file, 
then submit a job for restart?
I have old files which are finished after reaching wall time limit 
without "max_seconds" option, and I'm curious if I can use those files 
to restart.


4) I also use outdir option in the input file, does the outdir option 
should be the same when restart?


5) Are there any other things or useful hints that I need to consider 
when restart?


Thank you


___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users



___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Projected Bands

[Soumyadeep]

Dear Anuja,

  Yes it is implemented in Quantum Espresso. Try with projwfc.x 
executable.


with regards
Soumyadeep
---
Soumyadeep Ghosh,
Senior Research Fellow,
Homi Bhabha National Institute (HBNI),
Raja Ramanna Centre for Advanced Technology, Indore, India-452013
Mob: (+91)9424664553
User Lab: 0731244-2580
Email: soumyadeepghos...@gmail.com, soumyad...@rrcat.gov.in
---

On 08-07-2019 12:48, Anuja Chanana wrote:

Dear all,
Do we have the feature of projected bands in Quantum Espresso?

Thanks and Regards,
Anuja Chanana

 [1]
 Sender notified by
Mailtrack [1] 07/08/19, 12:47:59 PM 



Links:
--
[1]
https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;
___
Quantum ESPRESSO is supported by MaX 
(www.max-centre.eu/quantum-espresso)

users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] Projected Bands

[Anuja Chanana]

Dear all,
Do we have the feature of projected bands in Quantum Espresso?

Thanks and Regards,
Anuja Chanana


[image: Mailtrack]

Sender
notified by
Mailtrack

07/08/19,
12:47:59 PM
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users