Re: [QE-users] SCAN pseudopotential files are highly required

[Holzwarth, Natalie]

Dear Dr. Li,
   I am not sure what are the current and future plans for metaGGA
implementation of the quantum espresso package.   However, as have others,
our group has shown https://doi.org/10.1103/PhysRevB.105.125144 that the
SCAN exchange-correlation functional has serious numerical issues.
Fortunately,   the r2SCAN functional
http://dx.doi.org/10.1021/acs.jpclett.0c02405 has fixed some of those
issues.Our group plans to work over the summer to develop some PAW
datasets based on the r2SCAN functional for possible use with quantum
espresso and abinit.   Please note that there are many literature results
reporting using the SCAN and r2SCAN functionals generated mostly with the
VASP software.  Since I personally do not have a VASP license,  I do
not know for sure, but believe that all of these results were generated
using non-metaGGA datasets  (perhaps using GGA datasets for example).   It
will be very interesting to find out whether or not the tradition of
running calculations with pseudopotential generated with the "correct"
exchange-correlation functional is numerically important or whether that
rule can be relaxed as apparently has been done in VASP.   Sorry that
this does not answer your question, but thanks for "listening".
Sincerely,Natalie Holzwarth

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Wed, May 10, 2023 at 9:52 AM Jibiao Li via users <
users@lists.quantum-espresso.org> wrote:

> Dear ALL,
>
> One the QE website (Yi Yao's homepage), the SCAN pseudopotential files are
> only limited to  some elements. I want to use SCAN pseudopotential files for
> metals such as Pt. Where can I find them? Would anyone generously provide a
> copy of SCAN pseudopotential files for transition metals such as Pt?
>
> Thank you very much!
>
> Regards
>
> Jibiao Li
>
> Department of Materials Science and Engineering
>
> Yangtze Normal University
>
> Juxian Avenue 16, Fuling, Chongqing, China 408100
>
> Scopus Research ID: 54944118000
> 
>
> Web of Science Research ID: http://www.webofscience.com/wos/author/record/
> GLS-7259-2022
>
> 
>
> ___
> The Quantum ESPRESSO community stands by the Ukrainian
> people and expresses its concerns about the devastating
> effects that the Russian military offensive has on their
> country and on the free and peaceful scientific, cultural,
> and economic cooperation amongst peoples
> ___
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
> users mailing list users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

[QE-users] Strange error for one q-point in ph.x in subroutine set_irr_sym.f90

[Holzwarth, Natalie]

I have been using ph.x very happily for a variety of rhombohedral crystals
with R3c symmetry  In only one case, one q point (q=[0.25 0.25  0.25] in
crystal coordinates) ends with an error" Error in routine
set_irr_sym_new (722):   wrong representation. "The error occurs
when I use ibrav=5 and give celldm(1) and celldm(4)   or when I use ibrav 0
and enter the cell parameters explicitly and the pw.x step correctly
recognizes the 6 symmetry elements.  The error occurs in the compound
Li4Al3B4O12Cl but does not occur for Li4B7O12Cl and Li6Al3B4O13Cl which
have the same symmetry.   The error also does not seem to occur when I ask
abinit to evaluate the phonons for Li4Al3B4O12Cl at the same q point.   I
expect that this issue may be hard to trace, but in case it is something of
interest to other users or developers,   the input file of the offending
case is pasted below and I will be happy to provide additional information
if useful.   Thanks kindly,  Natalie

slurm run file for Li4Al3B4O12Cl at  (q=[0.25 0.25  0.25] in crystal
coordinates)

#!/bin/tcsh
#
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=32
#SBATCH --cpus-per-task=1
#SBATCH --account="natalieGrp"
#SBATCH --output="JOB-%j.o"
#SBATCH --error="JOB-%j.e"
#SBATCH --mail-user=nata...@wfu.edu
#SBATCH --mail-type=BEGIN,END,FAIL
#SBATCH --time=0-300:00:00
#SBATCH --mem=180gb
#SBATCH --partition=large
umask 002
# Note: SLURM has no batch input for cputime, excluding.
#
#
echo 'hostname' `/bin/hostname`
echo 'job directory' `pwd`
#
setenv TMPDIR /scratch/$SLURM_JOBID
echo 'Reset TMPDIR for this job to ' $TMPDIR

module load apps/quantum-espresso/7.1
set PW=pw.x
set PH=ph.x


#NOTE:SLURM defaults to running jobs in the directory where submitted;
#NOTE:Consider --workdir directive instead; and check functionality!
cd ${SLURM_SUBMIT_DIR}

cat > PSI.in << EOF

  calculation = "scf",
  pseudo_dir  =
'/deac/natalieGrp/natalie/wfurc9/EL6/rc9/PAWatoms/poscorenhatPBESOL'
  verbosity   = "high",
  outdir  = "$TMPDIR/",
  prefix  = 'PSI',
  restart_mode = 'from_scratch',
  nstep = 300,
  dt = 20,
  forc_conv_thr = 1.0D-4,
  etot_conv_thr = 1.0D-5,
  tstress = .true.,
  tprnfor = .true.,
/

  ibrav   =  5,
celldm(1)   = 17.2280506783752d0,
celldm(4) =  0.480660396853808d0,
  nat = 48,
  ntyp= 5,
  nosym   =.FALSE.,
  use_all_frac = .TRUE.,
  ecutwfc = 81.d0,
/

  conv_thr= 1.D-8,
  electron_maxstep = 200,
/

/

  cell_dynamics='bfgs',
  wmass = 1.00,
  press = 0.0,
/
ATOMIC_SPECIES
Li  6.941   Li.GGA-PBESOL-paw.UPF
Al  26.982  Al.GGA-PBESOL-paw.UPF
B   10.811  B.GGA-PBESOL-paw.UPF
O   15.9994 O.GGA-PBESOL-paw.UPF
Cl  35.453  Cl.GGA-PBESOL-paw.UPF

ATOMIC_POSITIONS (crystal)
Li0.9625200.9626400.483090
Li0.4830900.9625200.962640
Li0.9626400.4830900.962520
Li0.9830900.4626400.462520
Li0.4625200.9830900.462640
Li0.4626400.4625200.983090
Li0.3536800.3536800.353680
Li0.8536800.8536800.853680
Al0.2232900.2258800.734610
Al0.7346100.2232900.225880
Al0.2258800.7346100.223290
Al0.2346100.7258800.723290
Al0.7232900.2346100.725880
Al0.7258800.7232900.234610
B 0.5858100.5858100.585810
B 0.0858100.0858100.085810
B 0.5807900.5802300.161810
B 0.1618100.5807900.580230
B 0.5802300.1618100.580790
B 0.6618100.0802300.080790
B 0.0807900.6618100.080230
B 0.0802300.0807900.661810
O 0.4432400.5719300.738770
O 0.7387700.4432400.571930
O 0.5719300.7387700.443240
O 0.2387700.0719300.943240
O 0.9432400.2387700.071930
O 0.0719300.9432400.238770
O 0.4419000.7351200.158240
O 0.1582400.4419000.735120
O 0.7351200.1582400.441900
O 0.6582400.2351200.941900
O 0.9419000.6582400.235120
O 0.2351200.941900

[QE-users] Possible resolution of previous post on mysterious ph.x error

[Holzwarth, Natalie]

Dear Quantum Espresso forum,
  Yesterday I noted a mysterious error in ph.x (Version 7.1) observed
for NaCl using the primitive cell.The error was quite strange, usually
mentioning an error in  cdiaghg which is a routine in the
LAXlib directory.   I now think that it has to do with requesting too many
cores for my calculation because my error can be removed by requesting
fewer cores. As noted in the original post,   the error did not appear
in the QE versus 6.3, so presumably LAXlib files have been changed in the
7.1 version.I very much appreciate the fact that QE seems to adapt to
the number of nodes and cpus per node available in each run, but perhaps I
need to increase my understanding of how this works for the various
programs.   There was no problem running pw.x or ph.x for the gamma point
with 32 cores,   but ph.x failed for q /=0.Both pw.x and ph.x  with
all q vectors seem to have run correctly with 8 cores. Are there some
guidelines for choosing how many nodes/cores to request  ?   In any case,
  thanks for listening.   Sincerely,Natalie Holzwarth

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


-- Forwarded message -
From: Holzwarth, Natalie 
Date: Tue, Oct 25, 2022 at 4:50 PM
Subject: Very strange issue with ph.x in QE 7.1 which appeared OK in QE 6.3
To: Quantum Espresso users Forum 


Dear Quantum Espresso Forum,

I have been using ph.x from QE 7.1 for quite a few low-symmetry materials
but for several simple fcc crystals, the program
fails to diagonalize the first non-gamma point phonon matrix (see 7.1G.out)
file.   However I ran the same program with QE 6.3
which diagonalizes all of the phonon modes of NaCl.  In this test,   I am
using pseudos from SSSP.The input file is pasted below
and the two output files from ph.x are hopefully attached. Has anyone
else seen this issue?.
Thanks very much for any advice about this, Natalie

input file for vc-relax and phonon calculation:

cat runQE.slurm
#!/bin/tcsh
#
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=32
#SBATCH --cpus-per-task=1
#SBATCH --account="natalieGrp"
#SBATCH --output="JOB-%j.o"
#SBATCH --error="JOB-%j.e"
#SBATCH --mail-user=nata...@wfu.edu
#SBATCH --mail-type=BEGIN,END,FAIL
#SBATCH --time=0-300:00:00
#SBATCH --mem=96gb
#SBATCH --partition=large
umask 002
# Note: SLURM has no batch input for cputime, excluding.
#
#
echo 'hostname' `/bin/hostname`
echo 'job directory' `pwd`
#
setenv TMPDIR /scratch/$SLURM_JOBID
echo 'Reset TMPDIR for this job to ' $TMPDIR

module load apps/quantum-espresso/7.1
set PW=pw.x
set PH=ph.x


#NOTE:SLURM defaults to running jobs in the directory where submitted;
#NOTE:Consider --workdir directive instead; and check functionality!
cd ${SLURM_SUBMIT_DIR}

cat > PSI.in << EOF

  calculation = "vc-relax",
  pseudo_dir  =
'/deac/phy/natalieGrp/natalie/wfurc9/EL7/QE/Downloadedpseudos'
  verbosity   = "high",
  outdir  = "$TMPDIR/",
  prefix  = 'PSI',
  restart_mode = 'from_scratch',
  nstep = 300,
  dt = 20,
  forc_conv_thr = 1.0D-5,
  etot_conv_thr = 1.0D-6,
  tstress = .true.,
  tprnfor = .true.,
/

ibrav   =  2,
celldm(1)   = 10.6,
nat = 2,
ntyp= 2,
nosym   =.FALSE.,
use_all_frac = .TRUE.,
ecutwfc = 81.d0,
/

  conv_thr= 1.D-7,
  electron_maxstep = 200,
/

/

  cell_dynamics='bfgs',
  wmass = 1.00,
  press = 0.0,
/
ATOMIC_SPECIES
 Na  22.989769   Na_ONCV_PBEsol-1.0.upf
 Cl  35.45   Cl.pbesol-n-rrkjus_psl.1.0.0.UPF

ATOMIC_POSITIONS {crystal}
 Na  0.0   0.00.0
 Cl  0.5   0.500.50

K_POINTS AUTOMATIC
 8 8 8 0 0 0
EOF

mpirun $PW  -in   PSI.in  > PSI.out

cat > PSI.phG.in << EOF
phonons


outdir = '$TMPDIR',
prefix = 'PSI',
epsil = .true.,
ldisp = .true.,
fildyn = 'dyn.G',
tr2_ph = 1.0d-14,
start_q=1,
last_q=8,
nq1 = 4,
nq2 =4,
nq3 = 4,
/

EOF
mpirun $PH -in PSI.phG.in > PSI.phG.out





ls -Flag $TMPDIR

'rm' -r $TMPDIR

/usr/local/bin/slurm_mem_report -v

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


6.3phG.out
Description: Binary data


7.1phG.out
Description: Binary data
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Rus

[QE-users] Very strange issue with ph.x in QE 7.1 which appeared OK in QE 6.3

[Holzwarth, Natalie]

Dear Quantum Espresso Forum,

I have been using ph.x from QE 7.1 for quite a few low-symmetry materials
but for several simple fcc crystals, the program
fails to diagonalize the first non-gamma point phonon matrix (see 7.1G.out)
file.   However I ran the same program with QE 6.3
which diagonalizes all of the phonon modes of NaCl.  In this test,   I am
using pseudos from SSSP.The input file is pasted below
and the two output files from ph.x are hopefully attached. Has anyone
else seen this issue?.
Thanks very much for any advice about this, Natalie

input file for vc-relax and phonon calculation:

cat runQE.slurm
#!/bin/tcsh
#
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=32
#SBATCH --cpus-per-task=1
#SBATCH --account="natalieGrp"
#SBATCH --output="JOB-%j.o"
#SBATCH --error="JOB-%j.e"
#SBATCH --mail-user=nata...@wfu.edu
#SBATCH --mail-type=BEGIN,END,FAIL
#SBATCH --time=0-300:00:00
#SBATCH --mem=96gb
#SBATCH --partition=large
umask 002
# Note: SLURM has no batch input for cputime, excluding.
#
#
echo 'hostname' `/bin/hostname`
echo 'job directory' `pwd`
#
setenv TMPDIR /scratch/$SLURM_JOBID
echo 'Reset TMPDIR for this job to ' $TMPDIR

module load apps/quantum-espresso/7.1
set PW=pw.x
set PH=ph.x


#NOTE:SLURM defaults to running jobs in the directory where submitted;
#NOTE:Consider --workdir directive instead; and check functionality!
cd ${SLURM_SUBMIT_DIR}

cat > PSI.in << EOF

  calculation = "vc-relax",
  pseudo_dir  =
'/deac/phy/natalieGrp/natalie/wfurc9/EL7/QE/Downloadedpseudos'
  verbosity   = "high",
  outdir  = "$TMPDIR/",
  prefix  = 'PSI',
  restart_mode = 'from_scratch',
  nstep = 300,
  dt = 20,
  forc_conv_thr = 1.0D-5,
  etot_conv_thr = 1.0D-6,
  tstress = .true.,
  tprnfor = .true.,
/

ibrav   =  2,
celldm(1)   = 10.6,
nat = 2,
ntyp= 2,
nosym   =.FALSE.,
use_all_frac = .TRUE.,
ecutwfc = 81.d0,
/

  conv_thr= 1.D-7,
  electron_maxstep = 200,
/

/

  cell_dynamics='bfgs',
  wmass = 1.00,
  press = 0.0,
/
ATOMIC_SPECIES
 Na  22.989769   Na_ONCV_PBEsol-1.0.upf
 Cl  35.45   Cl.pbesol-n-rrkjus_psl.1.0.0.UPF

ATOMIC_POSITIONS {crystal}
 Na  0.0   0.00.0
 Cl  0.5   0.500.50

K_POINTS AUTOMATIC
 8 8 8 0 0 0
EOF

mpirun $PW  -in   PSI.in  > PSI.out

cat > PSI.phG.in << EOF
phonons


outdir = '$TMPDIR',
prefix = 'PSI',
epsil = .true.,
ldisp = .true.,
fildyn = 'dyn.G',
tr2_ph = 1.0d-14,
start_q=1,
last_q=8,
nq1 = 4,
nq2 =4,
nq3 = 4,
/

EOF
mpirun $PH -in PSI.phG.in > PSI.phG.out





ls -Flag $TMPDIR

'rm' -r $TMPDIR

/usr/local/bin/slurm_mem_report -v

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


6.3phG.out
Description: Binary data


7.1phG.out
Description: Binary data
___
The Quantum ESPRESSO community stands by the Ukrainian
people and expresses its concerns about the devastating
effects that the Russian military offensive has on their
country and on the free and peaceful scientific, cultural,
and economic cooperation amongst peoples
___
Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] mesh mismatch

[Holzwarth, Natalie]

>From the ATOMPAW side,I will be very happy to adjust the output for
Quantum Espresso as necessary to accommodate any new UPF formatting.
   Thanks, Natalie
N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Thu, Oct 22, 2020 at 11:29 AM Paolo Giannozzi 
wrote:

> On Thu, Oct 22, 2020 at 5:16 PM Sergey Lisenkov 
> wrote:
>
> I encountered a problem with my PAW pseudopotentials from ATOMPAW:
>>
>> mismatch mesh
>>
>> that comes from upflib/read_upf_new.f90
>>
>> I checked my UPF file and I see that meshes are different in some places
>> of the file, however v.6.6 is OK with that.
>>
>> Was something changed in the code as well?
>>
>
> yes, the code reading the pseudopotentials has changed a lot, but it
> should read files exactly as before. Please provide the pseudopotential
> file.
>
> Paolo
>
>
>>
>> Thanks,
>>  Sergey
>>
>> USF
>> ___
>> Quantum ESPRESSO is supported by MaX (www.max-centre.eu)
>> 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)
> 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)
users mailing list users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Monitoring the ion velocities in pw.x

[Holzwarth, Natalie]

Dear Paolo,
   Thanks for the information. The input velocities seem to be OK
when we use the units of bohr/Rytime when Ry=hbar/Ry.   Hopefully this is
correct.After I sent the email I finally read the  code more carefully
and realized that the velocity is calculated  internally as
vel(t)=(tau(t+dt)-tau(t-dt)/(2dt).Since the tau values are in the
output, we could then find the velocity values in postprocessing.   Thanks
again.   Natalie

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Sat, Jun 6, 2020 at 4:31 PM Paolo Giannozzi 
wrote:

> Hi Natalie
>
> I am not aware of any way to monitor the velocities during a MD run with
> the PWscf code. It uses plain Verlet (not velocity Verlet) and this is
> likely the reason why velocities are a little bit neglected. Thank you for
> the info about the existence of "ion_velocities='from_input'". I just added
> it to the documentation. Does anybody know about the units for velocities?
> Should be Ry a.u., can anybody confirm?
>
> Paolo
>
> On Thu, May 21, 2020 at 3:29 AM Holzwarth, Natalie 
> wrote:
>
>> Dear quantum espresso community,
>>We would like to monitor the ion velocities during an MD run  of
>> pw.x and cannot find appropriate key words for that in the documentation.
>> Would we need to modify the code in order to output the  velocities at each
>> time step or is there another way?  Similarly,  we think that we
>> figured out how to set initial velocities in the input file  by adding "
>> ion_velocities = 'from_input'", in the  section and adding "
>> ATOMIC_VELOCITIES" followed by a list for each ion. We could not find this
>>  in the documentation, so hopefully it is correct.It is a very nice
>> feature (just in case you are tracking subroutine popularities).   Thanks
>> kindly for advice on this. Sincerely, Natalie
>>
>> N. A. W. Holzwarth   email:
>> nata...@wfu.edu
>> Department of Physics  web:
>> http://www.wfu.edu/~natalie
>> Wake Forest University phone:
>> 1-336-758-5510
>> Winston-Salem, NC 27109 USA office: Rm. 300 Olin
>> Physical Lab
>> ___
>> 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] Monitoring the ion velocities in pw.x

[Holzwarth, Natalie]

Dear quantum espresso community,
   We would like to monitor the ion velocities during an MD run  of
pw.x and cannot find appropriate key words for that in the documentation.
Would we need to modify the code in order to output the  velocities at each
time step or is there another way?  Similarly,  we think that we
figured out how to set initial velocities in the input file  by adding "
ion_velocities = 'from_input'", in the  section and adding "
ATOMIC_VELOCITIES" followed by a list for each ion. We could not find this
 in the documentation, so hopefully it is correct.It is a very nice
feature (just in case you are tracking subroutine popularities).   Thanks
kindly for advice on this. Sincerely, Natalie

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab
___
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 regarding mixing of PBE and PBESOL PP

[Holzwarth, Natalie]

We are slowly updating our ATOMPAW webpage http://pwpaw.wfu.edu to include
LDA and PBESOL PAW datasets that are more reliable when used with Quantum
Espresso.I just added Ca and could add more as needed.   Of course,
although similar datasets have been used in the past,   the new ones always
need to be tested.

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Sat, May 4, 2019 at 12:27 AM Yeon, Jejoon  wrote:

> Hello
>
>
> I ran several DFTs few times before, but I only have limited amount of
> knowledge and experience in DFTs.
>
>
> I have Pyrope (Mg3Al2Si3O12) and Grossular (Ca3Al2Si3O12) unit cell, and
> wish to preform relax and vc-relax. After I get the relaxed atomic
> structure and cell size, I wish to make an energy curve of Pyrope /
> Grossular structure w.r.t. compression and expansion of volume, using
> expanded / compressed unit cells. Purpose of this DFT is to get the
> database for the parametrization of empirical force field, especially for
> mechanical properties like stress-strain curve and elastic constants.
>
>
> Now, I have PBE-PAW(kjpaw) and PBESOL-PAW(kjpaw) PPs for all atom types. I
> have no problem about Pyrope, I can run it with PBESOL. But Grossular is an
> issue. For Ca, PBE is only available option from QE PP webpage, there is
> no PBESOL for Ca yet. Accordingly, if I want to calculate energies of
> Grossular structure, I have three options as far as I know:
>
> 1) input_dft = 'PBE', while mix the PBE (Ca) and PBESOL (Al, Si, O)
>
> 2) inout_dft = 'PBESOL', while mix the PBE (Ca) and PBESOL (Al, Si, O)
>
> 3) just use PBE PPs for all 4 atom types.
>
>
>
> At this point, I'm not sure what would be the good choice for my purpose. I
> wish to use PBESOL because it is known to have better prediction for solid
> properties. But I'm not sure if I can mix them with PBE, and if I mix,
> which input_dft option should I need to choose.
>
>
> I ran test relaxations for 3 cases, and I found that the final atom
> coordinates of all 3 cases are very similar, they are mostly the same up
> to second decimal point numbers. Their final optimized energies are
> different, but as far as I know I can't compare them, isn't it? I'm not
> sure on which criteria should I need compare and select the best one
> from those three options.
>
>
> Or, if anyone had a similar experience, I welcome any advises or
> suggestions.
>
>
> Just in case, following is my example in file.
>
>
> 
>   prefix="03_Relax_Grossular_80_800_PBESOL",
>   calculation='relax',
>
> outdir="/scratch/jj/20190501_QEDFT_Grossular_EoS/03_Relax_Grossular_80_800_PBESOL/tmp",
>   pseudo_dir="/home/QE_pseudo/",
>   restart_mode= 'from_scratch',
>   nstep = 1000
> /
>
> 
>   ibrav=0,
>   nat=20,
>   ntyp=4,
>   ecutwfc=80,
>   ecutrho=800,
>   occupations='smearing',
>   smearing='methfessel-paxton',
>   degauss=0.005000,
>   input_dft='PBESOL'
> /
>
> 
>   diagonalization='cg',
>   conv_thr=1d-07,
>   mixing_mode='plain',
>   mixing_beta=0.100,
> /
>
> 
>   ion_dynamics = 'bfgs',
> /
>
> ATOMIC_SPECIES
>   Ca 40.078000 Ca.pbe-spn-kjpaw_psl.1.0.0.UPF
>   Al 26.981539 Al.pbesol-n-kjpaw_psl.1.0.0.UPF
>   Si 28.085500 Si.pbesol-n-kjpaw_psl.1.0.0.UPF
>   O 15.999400 O.pbesol-n-kjpaw_psl.1.0.0.UPF
>
> ATOMIC_POSITIONS {angstrom}
> Ca1.4807500.002.961500
> Ca2.9615001.4807500.00
> Ca0.002.9615001.480750
> Al0.000.000.00
> Al2.9615002.9615002.961500
> Si0.002.9615004.442250
> Si4.4422500.002.961500
> Si2.9615004.4422500.00
> O 0.4501485.3934841.791116
> O 1.7911160.4501485.393484
> O 5.3934841.7911160.450148
> O 3.4910162.5113524.752616
> O 2.5113524.7526163.491016
> O 4.7526163.4910162.511352
> O 5.4728520.5295164.131885
> O 4.1318855.4728520.529516
> O 0.5295164.1318855.472852
> O 2.4319843.4116481.170385
> O 3.4116481.1703852.431984
> O 1.1703852.4319843.411648
>
> K_POINTS {automatic}
>   4 4 4 0 0 0
>
> CELL_PARAMETERS {angstrom}
>5.92300   0.0   0.0
>0.0   5.92300   0.0
>0.0   0.0   5.92300
>
> 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 

Re: [QE-users] Change in temperature control for md simulation in QE 6.4.1 compared with 6.3 -- perhaps instead an issue with detecting symmetry??

[Holzwarth, Natalie]

Dear Paolo and Lorrenzo,
Thanks so much for your analysis of this issue. The patch to setup.f90
in the 6.4.1 release does seem to fix this problem at least for the simple
NaCl supercell. Thanks again.Natalie

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Thu, Apr 18, 2019 at 5:59 AM Paolo Giannozzi 
wrote:

> Oh well. I see: it's an unintended side effect of a bug fix to 6.3,
> present in 6.3-backports.
> There is a simple solution, not guarantee to be
> unintended-side-effect-free, though:
>
> diff --git a/PW/src/setup.f90 b/PW/src/setup.f90
> index 0918ac017..135e58789 100644
> --- a/PW/src/setup.f90
> +++ b/PW/src/setup.f90
> @@ -519,7 +519,10 @@ SUBROUTINE setup()
>!
>! ... nosym: do not use any point-group symmetry (s(:,:,1) is the
> identity)
>!
> -  IF ( nosym ) nsym = 1
> +  IF ( nosym ) THEN
> + nsym = 1
> + invsym = .FALSE.
> +  END IF
>!
>IF ( nsym > 1 .AND. ibrav == 0 ) CALL infomsg('setup', &
> 'DEPRECATED: symmetry with ibrav=0, use correct ibrav instead')
>
> Paolo
>
> On Thu, Apr 18, 2019 at 11:11 AM Lorenzo Paulatto 
> wrote:
>
>> > symmetry detection?We did put nosym=.true. but the code seems to
>> > have set invsym=.true. anyway.
>>
>> I see what you mean,
>> with the exact same input version 6.3 set the variable invsym, from
>> symm_base to false, while the current version sets it to true.
>>
>> This breaks start_therm because the only possible initial velocities
>> that respect the constraint in this case are all zero.
>>
>> The bug is that version 6.3 sets invsym AFTER enforcing nosym=.true.,
>> while git version sets invsym BEFORE enforcing nosym=.true., the
>> subroutine find_sym is identical
>>
>> The change seems to have occurred in commit 23fb73f9b7 inside
>> PW/src/setup.f90 I'll let Paolo Giannozzi have a look before going
>> deeper, as I do not immediately understand what has changed, I think it
>> has something to do with nrot_ vs. nrot, as the former is 1 but the
>> latter is 48 before the call to find_sym in setup.f90 line 513, but
>> find_sym internally uses nrot.
>>
>> cheers
>>
>>
>> Perhaps it is intended that users should
>> > move atoms off of their symmetry positions before running MD
>> > simulations?   Thanks for your advice about this.Natalie
>> >
>> > N. A. W. Holzwarth   email:
>> > nata...@wfu.edu <mailto:nata...@wfu.edu>
>> > Department of Physics      web:
>> > http://www.wfu.edu/~natalie
>> > Wake Forest University phone:
>> > 1-336-758-5510
>> > Winston-Salem, NC 27109 USA office: Rm. 300 Olin
>> > Physical Lab
>> >
>> >
>> > On Wed, Apr 10, 2019 at 6:29 PM Holzwarth, Natalie > > <mailto:nata...@wfu.edu>> wrote:
>> >
>> > Dear Quantum Espresso developers,
>> > Hopefully this might be something that is easy to track down
>> > but I cannot figure it out.   We noticed that we cannot set the
>> > initial temperature in our md simulations in QE 6.4.1  (or 6.4) in
>> > the same way that works fine in QE 6.3.   For example, in a simple
>> > test , the comparison between the results for " grep temperature
>> > *out"   is:
>> >QE   6.3QE 6.4.1
>> >   temperature=  1800. K   temperature=
>> >   0. K
>> >   temperature=  1798.79298998 K   temperature=
>> >   0. K
>> >   temperature=  1795.18924725 K   temperature=
>> >   0.0001 K
>> >   temperature=  1789.20477087 K   temperature=
>> >   0.0002 K
>> >   temperature=  1780.85173941 K   temperature=
>> >   0.0048 K
>> >   temperature=  1770.15802096 K   temperature=
>> >   0.0014 K
>> >   temperature=  1757.15885289 K   temperature=
>> >   0.0032 K
>> >   temperature=  1741.89911601 K   temperature=
>> >   0.0575 K
>

Re: [QE-users] Change in temperature control for md simulation in QE 6.4.1 compared with 6.3 -- perhaps instead an issue with detecting symmetry??

[Holzwarth, Natalie]

I looked into this previously reported problem of the different results
with a simple MD run setting the initial temperature in QE 6.4.1 and 6.3
and (as usual) it seems that the explanation may be more complicated.
What we have often done is to start from an equilibrium geometry and use
the 'initial' key word  in the hopes that all atoms will be given a random
velocity.   In our case, QE detected some symmetry in the atomic positions
and apparently zeroed the initial velocities within the routine
dynamics_module.f90.  Is there a way to suppress this symmetry
detection?We did put nosym=.true. but the code seems to have set
invsym=.true. anyway. Perhaps it is intended that users should move atoms
off of their symmetry positions before running MD simulations?   Thanks
for your advice about this.Natalie

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Wed, Apr 10, 2019 at 6:29 PM Holzwarth, Natalie  wrote:

> Dear Quantum Espresso developers,
>Hopefully this might be something that is easy to track down but I
> cannot figure it out.   We noticed that we cannot set the initial
> temperature in our md simulations in QE 6.4.1  (or 6.4) in the same way
> that works fine in QE 6.3.   For example, in a simple test , the comparison
> between the results for " grep temperature  *out"   is:
>   QE   6.3QE 6.4.1
>  temperature=  1800. K   temperature=
>  0. K
>  temperature=  1798.79298998 K   temperature=
>  0. K
>  temperature=  1795.18924725 K   temperature=
>  0.0001 K
>  temperature=  1789.20477087 K   temperature=
>  0.0002 K
>  temperature=  1780.85173941 K   temperature=
>  0.0048 K
>  temperature=  1770.15802096 K   temperature=
>  0.0014 K
>  temperature=  1757.15885289 K   temperature=
>  0.0032 K
>  temperature=  1741.89911601 K   temperature=
>  0.0575 K
>  temperature=  1724.42918183 K   temperature=
>  0.1204 K
>  temperature=  1704.80836203 K   temperature=
>  0.1108 K
>  temperature=  1683.10589232 K   temperature=
>  0.0872 K
> The sample input file is pasted below.   The only difference between the
> runs is the version of QE.
>   Thanks in advance for your suggestions.Sincerely, Natalie
> ---sample input file for md
> run-
> #!/bin/tcsh
> #
> #SBATCH --nodes=1
> #SBATCH --ntasks-per-node=8
> #SBATCH --cpus-per-task=1
> #SBATCH --account="natalieGrp"
> #SBATCH --output="JOB-%j.o"
> #SBATCH --error="JOB-%j.e"
> #SBATCH --mail-user=nata...@wfu.edu
> #SBATCH --mail-type=BEGIN,END,FAIL
> #SBATCH --job-name="NaCl"
> #SBATCH --time=0-10:00:00
> #SBATCH --mem=24gb
> #SBATCH --partition=small
> umask 002
> # Note: SLURM has no batch input for cputime, excluding.
> #
> source /etc/profile.d/modules.csh
> module purge
> module load rhel7/openmpi/3.1.1-intel-2018
> #
> echo 'hostname' `/bin/hostname`
> echo 'job directory' `pwd`
> #
> setenv TMPDIR /scratch/$SLURM_JOBID
> echo 'Reset TMPDIR for this job to ' $TMPDIR
>
> set PW=/home/natalie/EL7/publiccode/QE/qe-6.4.1/bin/pw.x
>
> #NOTE:SLURM defaults to running jobs in the directory where submitted;
> #NOTE:Consider --workdir directive instead; and check functionality!
> cd ${SLURM_SUBMIT_DIR}
>
> cat > NaCl.in << EOF
>
> 
>   calculation = "md",
>   pseudo_dir  =
> '/deac/natalieGrp/wfurc9/natalie/EL6/rc9/PAWatoms/poscorenhat/',
>   verbosity   = "high",
>   outdir  = "$TMPDIR/",
>   prefix  = "conv",
>   restart_mode = 'from_scratch',
>   nstep = 30,
>   dt = 20,
>   forc_conv_thr = 1.0D-5,
>   etot_conv_thr = 1.0D-6,
>   tstress = .true.,
>   tprnfor = .true.,
> /
> 
>   ibrav   = 1,
>   celldm(1)=1.0331018E+01,
>   nat = 8,
>   ntyp= 2,
>   nosym   =.TRUE.,
>   ecutwfc = 64.D0,
>   use_all_frac = .TRUE.,
>   occupations = "smearing",
>   smearing= "gaussian",
>   degauss = 0.001D0,
> /
> 
>   conv_thr= 1.D-8,
>   electron_maxstep = 200,
> /
> 
>  ion_dynamics = 'verlet',
>  ion_temperature = 'initial',
>  tempw = 1800.d0,
>  pot_extrapolation = 'seco

[QE-users] Change in temperature control for md simulation in QE 6.4.1 compared with 6.3

[Holzwarth, Natalie]

Dear Quantum Espresso developers,
   Hopefully this might be something that is easy to track down but I
cannot figure it out.   We noticed that we cannot set the initial
temperature in our md simulations in QE 6.4.1  (or 6.4) in the same way
that works fine in QE 6.3.   For example, in a simple test , the comparison
between the results for " grep temperature  *out"   is:
  QE   6.3QE 6.4.1
 temperature=  1800. K   temperature=
 0. K
 temperature=  1798.79298998 K   temperature=
 0. K
 temperature=  1795.18924725 K   temperature=
 0.0001 K
 temperature=  1789.20477087 K   temperature=
 0.0002 K
 temperature=  1780.85173941 K   temperature=
 0.0048 K
 temperature=  1770.15802096 K   temperature=
 0.0014 K
 temperature=  1757.15885289 K   temperature=
 0.0032 K
 temperature=  1741.89911601 K   temperature=
 0.0575 K
 temperature=  1724.42918183 K   temperature=
 0.1204 K
 temperature=  1704.80836203 K   temperature=
 0.1108 K
 temperature=  1683.10589232 K   temperature=
 0.0872 K
The sample input file is pasted below.   The only difference between the
runs is the version of QE.
  Thanks in advance for your suggestions.Sincerely, Natalie
---sample input file for md run-
#!/bin/tcsh
#
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=8
#SBATCH --cpus-per-task=1
#SBATCH --account="natalieGrp"
#SBATCH --output="JOB-%j.o"
#SBATCH --error="JOB-%j.e"
#SBATCH --mail-user=nata...@wfu.edu
#SBATCH --mail-type=BEGIN,END,FAIL
#SBATCH --job-name="NaCl"
#SBATCH --time=0-10:00:00
#SBATCH --mem=24gb
#SBATCH --partition=small
umask 002
# Note: SLURM has no batch input for cputime, excluding.
#
source /etc/profile.d/modules.csh
module purge
module load rhel7/openmpi/3.1.1-intel-2018
#
echo 'hostname' `/bin/hostname`
echo 'job directory' `pwd`
#
setenv TMPDIR /scratch/$SLURM_JOBID
echo 'Reset TMPDIR for this job to ' $TMPDIR

set PW=/home/natalie/EL7/publiccode/QE/qe-6.4.1/bin/pw.x

#NOTE:SLURM defaults to running jobs in the directory where submitted;
#NOTE:Consider --workdir directive instead; and check functionality!
cd ${SLURM_SUBMIT_DIR}

cat > NaCl.in << EOF


  calculation = "md",
  pseudo_dir  =
'/deac/natalieGrp/wfurc9/natalie/EL6/rc9/PAWatoms/poscorenhat/',
  verbosity   = "high",
  outdir  = "$TMPDIR/",
  prefix  = "conv",
  restart_mode = 'from_scratch',
  nstep = 30,
  dt = 20,
  forc_conv_thr = 1.0D-5,
  etot_conv_thr = 1.0D-6,
  tstress = .true.,
  tprnfor = .true.,
/

  ibrav   = 1,
  celldm(1)=1.0331018E+01,
  nat = 8,
  ntyp= 2,
  nosym   =.TRUE.,
  ecutwfc = 64.D0,
  use_all_frac = .TRUE.,
  occupations = "smearing",
  smearing= "gaussian",
  degauss = 0.001D0,
/

  conv_thr= 1.D-8,
  electron_maxstep = 200,
/

 ion_dynamics = 'verlet',
 ion_temperature = 'initial',
 tempw = 1800.d0,
 pot_extrapolation = 'second-order',
 wfc_extrapolation = 'second-order',
/

  cell_dynamics='none',
  wmass = 1.0,
  press = 0.0,
/
ATOMIC_SPECIES
Na  22.989769  Na.LDA-PW-paw.UPF
Cl  35.45   Cl.LDA-PW-paw.UPF
ATOMIC_POSITIONS {crystal}
Na   0.0  0.0  0.0
Na   0.5  0.5  0.0
Na   0.0  0.5  0.5
Na   0.5  0.0  0.5
Cl   0.5  0.5  0.5
Cl   0.0  0.0  0.5
Cl   0.5  0.0  0.0
Cl   0.0  0.5  0.0
K_POINTS AUTOMATIC
2 2 2 1 1 1
EOF

mpirun $PW  -in  NaCl.in  >  NaCl.out

-

N. A. W. Holzwarth   email: natalie@

Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [QE-users] Problem using SCAN calculating energy of atomic oxygen

[Holzwarth, Natalie]

I have looked into the SCAN functional for an isolated atom, also finding
that Vxc increases to unphysically large values as the density decreases
exponentially. We were able to demonstrate for ourselves that the SCAN
functional itself is responsible for this behavior due to the appearance of
the density in denominators of various terms.It is my understanding
that the SCAN developers are aware of this issue and are working on a
remedy.In the meantime, perhaps it would be good to use the SCAN
functional only for systems that do not have exponentially decreasing
densities.   At least that was my conclusion.Sincerely, Natalie
Holzwarth

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Wed, Nov 21, 2018 at 1:26 PM Filippo Savazzi 
wrote:

> Thanks Giuseppe,
> I’ll give it a try, I didn’t think about setting the occupation from input.
> Thank you for your help.
>
> Best,
>
> Filippo
>
>
>
> Filippo Savazzi, PhD Student
> Politecnico di Torino, Torino, Italy
>
> > On 21 Nov 2018, at 19:00, Giuseppe Mattioli <
> giuseppe.matti...@ism.cnr.it> wrote:
> >
> >
> > Dear Filippo
> > Isolated open-shell atoms are tricky. Please look here for hints
> >
> > yourpathtoQE6.3/PW/examples/example05
> >
> > HTH
> > Giuseppe
> >
> > Quoting Filippo Savazzi :
> >
> >> Dear QE users,
> >>
> >> I’m Filippo Savazzi, a PhD student from Politecnico di Torino, Italy.
> >> I’m using QE since a couple of years, and just browsing the archives of
> this mailing list or enquiring the mighty google I’ve been lucky enough
> that this is actually the first time I have to post a question.
> >> Thanks everybody for the indirect support you gave me in these years.
> >>
> >> I’m calculating absorption energies of oxygen on a coronene molecule,
> as part of a little evaluation of different available XC functionals that
> I’m doing. I’m calculating the absorption energy both with respect to the
> molecular oxygen and with atomic oxygen.
> >> My problems arise when I try to calculate the energy of a single atom
> of oxygen using SCAN. In this case the energy diverges until the SCF fails.
> I have no troubles running the calculation on the actual system (coronene +
> bridged O), neither on a molecular oxygen (triplet O2); the  issue is just
> localised on the single oxygen atom. My first guess was that the
> implementation of SCAN has either troubles in dealing with isolated systems
> or with spin polarization, but I ruled out these issues when I was able to
> calculate the single point energy of an oxygen molecule. Are you aware of
> any other problems using SCAN in these conditions?
> >> In the following I attach the input for pw.x I’m using, as well as a
> brief example of the SCF part in the output. I already played with cell
> dimension (thinking too much vacuum could have been the problem), as well
> as with ecutwfc and ecutrho (so indirectly with the integration grid), and
> then, just to give it a chance, with the diagonalization method and
> beta-mixing.
> >>
> >> Thank you in advance for your attention.
> >>
> >> Best,
> >> Filippo
> >>
> >>
> >> Filippo Savazzi, PhD Student
> >> Politecnico di Torino, Torino, Italy
> >>
> >>
> >>
> >>
> >> 
> >>   calculation = ’scf',
> >>   restart_mode='from_scratch',
> >>   pseudo_dir = '/home/filippo/pseudo',
> >>   outdir='./tmp_o',
> >>   prefix='oxy',
> >> /
> >> 
> >>   ibrav=6,
> >>   celldm(1)=20,
> >>   celldm(3)=1,
> >>   nat=1,
> >>   ntyp=1,
> >>   input_dft='scan',
> >>   ecutwfc=100,
> >>   tot_magnetization=2,
> >>   nspin=2,
> >> /
> >> 
> >>   diagonalization = 'cg',
> >>   electron_maxstep = 300,
> >>   mixing_mode = 'local-TF',
> >>   mixing_beta = 0.7,
> >>   conv_thr =  1.0d-7,
> >> /
> >> 
> >>   ion_dynamics='damp',
> >>   upscale=1000,
> >> /
> >> ATOMIC_SPECIES
> >> O 15.99 O_ONCV_PBE-1.0.upf
> >> ATOMIC_POSITIONS {angstrom}
> >> O0.   0.   0.
> >> K_POINTS{gamma}
> >>
> >>
> >>
> >>
> >> EXTRACT OF OUTPUT:
> >>
> >> Dense  grid:   540376 G-vectors FFT dimensions: ( 128, 128, 128)
> >>
> >> Estimated max dynamical RAM per process > 116.06 MB
> >>
> >> Estimated total dynamical RAM >   1.36 GB
> >> Generating pointlists ...
> >> new r_m :   0.4125 (alat units)  8.2500 (a.u.) for type1
> >>
> >> Initial potential from superposition of free atoms
> >>
> >> starting charge5.99905, renormalised to6.0
> >>
> >> negative rho (up,down):  4.917E-05 4.917E-05
> >> Starting wfcs are random
> >>
> >> total cpu time spent up to now is3.1 secs
> >>
> >> Self-consistent Calculation
> >>
> >> iteration #  1 ecut=   100.00 Ry beta= 0.70
> >> CG style diagonalization
> >> ethr =  1.00E-02, 

[QE-users] [SUSPECT ATTACHMENT REMOVED] Re: PWCOND: NAN/ SIGSEGV

[Holzwarth, Natalie]

I have chimed into the  Quantum Espresso listserve a few times noting a
similar problem characterized by an intermittent segmentation fault while
running pw.x and ph.x. On our system which runs the Red Hat operating
system (RHEL6u9) and intel 2018 compilers we see the segmentation fault
when using  OpenMPI 3.1.1 and 3.1.0. compiled with Intel 2018.   When we
use OpenMPI 2.1.0, the problem does not appear as often.   In our case,
libpthread is always listed in the error trace.The specific error
message that we get from a ph.x example is pasted below and the run script
and UPF are attached, just in case this is useful information. Thanks,
Natalie

---error from ph.x run--
 Image  PCRoutineLine
Source
ph.x   00D99A1D  for__signal_handl Unknown  Unknown
libpthread-2.12.s  003271E0F7E0  Unknown   Unknown  Unknown
mca_btl_vader.so   2AB74BBB99A7  Unknown   Unknown  Unknown
libopen-pal.so.40  2AB738AD3A54  opal_progress Unknown  Unknown
libmpi.so.40.10.1  2AB7384DBC04  ompi_request_defa Unknown  Unknown
libmpi.so.40.10.1  2AB7385384C5  ompi_coll_base_ba Unknown  Unknown
libmpi.so.40.10.1  2AB7384F26F1  MPI_Barrier   Unknown  Unknown
libmpi_mpifh.so.4  2AB73826D013  MPI_Barrier_f08   Unknown  Unknown
ph.x   00BA9E0E  Unknown   Unknown  Unknown
ph.x   00B9835B  Unknown   Unknown  Unknown
ph.x   0057FE26  Unknown   Unknown  Unknown
ph.x   004BE229  Unknown   Unknown  Unknown
ph.x   004A0F10  Unknown   Unknown  Unknown
ph.x   00415A65  Unknown   Unknown  Unknown
ph.x   0040EE73  Unknown   Unknown  Unknown
ph.x   0040EDDE  Unknown   Unknown  Unknown
libc-2.12.so   00327161ED1D  __libc_start_main Unknown  Unknown
ph.x   0040ECE9  Unknown   Unknown  Unknown
--
mpirun detected that one or more processes exited with non-zero status,
thus causing
the job to be terminated. The first process to do so was:

  Process name: [[24484,1],12]
  Exit code:174
--


N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab

On Fri, Aug 31, 2018 at 5:32 AM, Ankit Jain  wrote:

> Hello Subrata,
>
> setting 'ulimit -u unlimited' does not help.
>
> Thanks,
> Ankit Jain
>
> On 31 Aug 2018, at 11.17, Subrata Jana  wrote:
>
> Hi,
>
> This error was also observed when a different version of a compiler was
> loaded than that used to compile the code. Suggested was to rebuild
> everything and please try this:
>
> ftp://ftp.iitb.ac.in/LDP/en/solrhe/ch06s10.html
>
> With Regards,
> SJ
>
>
> *--
> *
> *SUBRATA JANA*
> *Research Scholar*
>
> *School of Physical Sciences National Institute of Science Education and
> Research (NISER), **Bhubaneswar*
> *PO- Bhimpur-Padanpur, Via- Jatni, District:- Khurda*
>
> *PIN – 752050, Odisha, INDIA*
>
> On Fri, Aug 31, 2018 at 2:14 PM, Ankit Jain  wrote:
>
>> Dear All,
>>
>> I am new to PWCOND calculations and I created my input files following
>> the provided examples.
>> I am trying to do conductance calculation for Metal-conductor-metal
>> system. I am running into SIGSEGV error.
>>
>> Things I tried:
>> - running in serial vs parallel and on larger memory machines (16 cpus
>> with 128 gb memory).
>> - changing ikind in the pwcond.in input from 1 to 2 as my right and left
>> lead are same material.
>> - setting ikind =2, and bdr = 40 in the input to pwcond.x (40 is my
>> system size in the z-direction)
>> - setting ikind=2 and bdl =10 and bds = 30 in the pwcond.x input file. In
>> this case, program does not crash but returns NAN as non-zero value of
>> transmittance.
>>
>> My scf.in, pwcond.in, scf.out and pwcond.out files are attached. The
>> program (pwcond.x) dies with the following error:
>>
>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>> Image  PCRoutineLine
>> Source
>> pwcond.x   00BA019D  Unknown   Unknown
>> Unknown
>> libpthread-2.17.s  7F841B50D6D0  Unknown   Unknown
>> Unknown
>> libiomp5.so7F841A2F4595  Unknown   Unknown
>> Unknown
>> libiomp5.so7F841A2F42D4  Unknown

Re: [QE-users] GIPAW Segmentation Fault

[Holzwarth, Natalie]

I am not sure what is the output for that particular line, but the last
part of the output looks as given below.For different instances of the
run, the particular iteration changes, but the boxed error message returned
by phonon.f90 is always the same.We have seen the error in both 6.2.1
and 6.3 versions of the QE package.  If this is of interest, I will be glad
to send any additional information.The run is for NaCl.Thanks,
Natalie

- end of phonon output file:
 Representation #  3 mode #   3

 Self-consistent Calculation

  iter #   1 total cpu time :  1573.2 secs   av.it.:   6.9
  thresh= 1.000E-02 alpha_mix =  0.700 |ddv_scf|^2 =  1.571E-05

  iter #   2 total cpu time :  1602.0 secs   av.it.:  11.4
  thresh= 3.964E-04 alpha_mix =  0.700 |ddv_scf|^2 =  1.095E-05

  iter #   3 total cpu time :  1629.0 secs   av.it.:  10.6
  thresh= 3.308E-04 alpha_mix =  0.700 |ddv_scf|^2 =  3.191E-08

  iter #   4 total cpu time :  1657.8 secs   av.it.:  11.2
  thresh= 1.786E-05 alpha_mix =  0.700 |ddv_scf|^2 =  2.458E-10

  iter #   5 total cpu time :  1687.6 secs   av.it.:  11.9
  thresh= 1.568E-06 alpha_mix =  0.700 |ddv_scf|^2 =  2.328E-11
---
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
---


N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab

On Tue, Aug 7, 2018 at 12:00 PM, Pietro Delugas  wrote:

> hello
>
> what is the output of
>
> addr2line -p -e ph.x 004BE229
> and what version of ph are you using ?
>
>
> On 07/08/2018 17:06, Holzwarth, Natalie wrote:
>
> This segmentation fault issue has also appeared for us in another QE
> code.Perhaps it is a totally unrelated problem which we find related to
> the openmpi package compiled with intel-3.1.1-2018 and intel-3.1.0-2018.
>  In our case, compiling with openmpi package compiled with intel-2.1.0-2018
> usually (not always) solves the problem.  Compiling with a much older
> openmpi package solves the problem, but is not viable for the current
> configuration of our cluster. Since no one else mentioned the problem until
> now, we think it may have to do with our internal setup???  The error is
> very intermittent,   occurring at different places in the code for the same
> input.The common aspect of this error to the one in the original
> message is libpthread-2.12.so. Most reliably we see the error in ph.x
> with part of the error message:
>
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutineLine
> Source
> ph.x   00D99A1D  for__signal_handl Unknown  Unknown
> libpthread-2.12.s  003271E0F7E0  Unknown   Unknown  Unknown
> mca_btl_vader.so   2AB74BBB99A7  Unknown   Unknown  Unknown
> libopen-pal.so.40  2AB738AD3A54  opal_progress Unknown  Unknown
> libmpi.so.40.10.1  2AB7384DBC04  ompi_request_defa Unknown  Unknown
> libmpi.so.40.10.1  2AB7385384C5  ompi_coll_base_ba Unknown  Unknown
> libmpi.so.40.10.1  2AB7384F26F1  MPI_Barrier   Unknown  Unknown
> libmpi_mpifh.so.4  2AB73826D013  MPI_Barrier_f08   Unknown  Unknown
> ph.x   00BA9E0E  Unknown   Unknown  Unknown
> ph.x   00B9835B  Unknown   Unknown  Unknown
> ph.x   0057FE26  Unknown   Unknown  Unknown
> ph.x   004BE229  Unknown   Unknown  Unknown
> ph.x   004A0F10  Unknown   Unknown  Unknown
> ph.x   00415A65  Unknown   Unknown  Unknown
> ph.x   0040EE73  Unknown   Unknown  Unknown
> ph.x   0040EDDE  Unknown   Unknown  Unknown
> libc-2.12.so   00327161ED1D  __libc_start_main Unknown
> Unknown
> ph.x   0040ECE9  Unknown   Unknown  Unknown
>
> I am very curious about whether you think this may be related or totally
> unrelated.   Thanks,  Natalie Holzwarth
>
> N. A. W. Holzwarth   email:
> nata...@wfu.edu
> Department of Physics  web:
> http://www.wfu.edu/~natalie
> Wake Forest University phone:
> 1-336-758-5510
> Winston-Salem, NC 27109 USA   

Re: [QE-users] GIPAW Segmentation Fault

[Holzwarth, Natalie]

This segmentation fault issue has also appeared for us in another QE code.
  Perhaps it is a totally unrelated problem which we find related to the
openmpi package compiled with intel-3.1.1-2018 and intel-3.1.0-2018.   In
our case, compiling with openmpi package compiled with intel-2.1.0-2018
usually (not always) solves the problem.  Compiling with a much older
openmpi package solves the problem, but is not viable for the current
configuration of our cluster. Since no one else mentioned the problem until
now, we think it may have to do with our internal setup???  The error is
very intermittent,   occurring at different places in the code for the same
input.The common aspect of this error to the one in the original
message is libpthread-2.12.so. Most reliably we see the error in ph.x with
part of the error message:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image  PCRoutineLineSource

ph.x   00D99A1D  for__signal_handl Unknown  Unknown
libpthread-2.12.s  003271E0F7E0  Unknown   Unknown  Unknown
mca_btl_vader.so   2AB74BBB99A7  Unknown   Unknown  Unknown
libopen-pal.so.40  2AB738AD3A54  opal_progress Unknown  Unknown
libmpi.so.40.10.1  2AB7384DBC04  ompi_request_defa Unknown  Unknown
libmpi.so.40.10.1  2AB7385384C5  ompi_coll_base_ba Unknown  Unknown
libmpi.so.40.10.1  2AB7384F26F1  MPI_Barrier   Unknown  Unknown
libmpi_mpifh.so.4  2AB73826D013  MPI_Barrier_f08   Unknown  Unknown
ph.x   00BA9E0E  Unknown   Unknown  Unknown
ph.x   00B9835B  Unknown   Unknown  Unknown
ph.x   0057FE26  Unknown   Unknown  Unknown
ph.x   004BE229  Unknown   Unknown  Unknown
ph.x   004A0F10  Unknown   Unknown  Unknown
ph.x   00415A65  Unknown   Unknown  Unknown
ph.x   0040EE73  Unknown   Unknown  Unknown
ph.x   0040EDDE  Unknown   Unknown  Unknown
libc-2.12.so   00327161ED1D  __libc_start_main Unknown  Unknown
ph.x   0040ECE9  Unknown   Unknown  Unknown

I am very curious about whether you think this may be related or totally
unrelated.   Thanks,  Natalie Holzwarth

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab

On Tue, Aug 7, 2018 at 8:18 AM, Davide Ceresoli 
wrote:

> Dear Ben,
> I'm afraid it's a problem with MKL-blas ZDOTC, which must
> return a complex(dp) result. Very strange, because if you grep
> the source code, we have declared it: complex(dp), external::zdtoc
>
> Can you tell us your compiler and MKL version? can you add
> DFLAGS+=-Dzdotc=zdotc_wrapper
> to the QE make.inc and recompile both (QE and GIPAW)?
>
> Best wishes,
> Davide
>
>
> On 08/06/2018 03:19 PM, Ben Comer wrote:
>
>> Hello,
>>
>> I've been trying to do g factor calculations in GIPAW working for a few
>> days now. I keep getting a segmentation fault (below) no matter how I
>> compile it on our cluster. Does anyone have a good idea of what might be
>> causing this?
>>
>>
>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>> Image  PCRoutine LineSource
>> gipaw.x00C40604  Unknown Unknown  Unknown
>> libpthread-2.12.s  00328DE0F7E0  Unknown Unknown  Unknown
>> libmkl_avx2.so 2AAAB7DA5CA3  mkl_blas_avx2_zdo Unknown  Unknown
>>
>> Thanks,
>>
>> Ben Comer
>>
>> Georgia Tech
>>
>>
>>
>>
> --
> +--+
>   Davide Ceresoli
>   CNR Institute of Molecular Science and Technology (CNR-ISTM)
>   c/o University of Milan, via Golgi 19, 20133 Milan, Italy
>   Email: davide.ceres...@istm.cnr.it
>   Phone: +39-02-50314276, +39-347-1001570 (mobile)
>   Skype: dceresoli
> +--+
> ___
> users mailing list
> users@lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users

Re: [Pw_forum] The relation between total PDOS and DOS

[Holzwarth, Natalie]

In general the sum of the PDOS does not equal the total DOS.In general
the DOS is approximates
DOS(E)= \sum_nk  \delta(E-E_{nk})while PDOS^a= \sum_nk
 \delta(E-E_{nk}) f^a_{nk},   where f_^a_{nk} denotes a weighting factor.
 In general these weight factors do not sum to one.They come
calculating the overlap of the Bloch wave \Psi_{nk} with atomic centered
functions stored in the atomic dataset (UPF) file.More details are
available if interested. That's my 2 cents worth.   Sincerely,
Natalie Holzwarth

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab

On Wed, Aug 10, 2016 at 4:42 AM, reza vatan  wrote:

> Dear all,
>
> I have calculated the Projected Density of State (PDOS) and Density of
> States (DOS) for a system containing Si atoms using projwfc.x and dos.x,
> respectively, implemented in QE program. I'm wondering if I add the PDOS of
> all atoms in the system, should I get the same DOS that I'm getting from
> dos.x calculations?
>
> Many thanks in advances.
>
> Best,
> Reza Vatan Meidanshahi,
> Electrical Engineering Department,
> Arizona State University.
>
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] xcrysden site

[Holzwarth, Natalie]

try www.xcrysden.org

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab

On Tue, May 3, 2016 at 1:05 PM,  wrote:

>  Dear PW users.
>
>  Sorry for the question is not related to QE. But I imagine the most of
> you are xcrysden users.
>
>  I am trying to connect to the xcrysden.org, but it is down. Does anyone
> konw any problem with the site? And, is there any alternative to get
> xcrysden?
>
>  Thank you
>
>  Pedro Moreira
>
>  Assistent professor
>  UFSCar, Brazil
>
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

Re: [Pw_forum] PAW orthonormality and obtaining S|psi>

[Holzwarth, Natalie]

Dear Henry,
   I don't know how to output the full PAW wavefunctions in quantum
espresso.  Did you want to evaluate ithem on a grid of real space points?
There is a program called plotpaw.f90 that seems to output the full PAW
density on a grid of points in real space.Is this close to what you
want to do? In any case, I never used this program and the top says
"experimental and incomplete program ...".Perhaps Paolo might clarify
this?It could be that  this existent code could be modified for your
purposes??  Hopefully someone else might have a better answer.
Sincerely, Natalie


N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab

On Sat, Apr 16, 2016 at 12:39 PM, Henry J Seeley <hsee...@uoregon.edu>
wrote:

> Thank you Natalie,
>
> I've already used projwfc.x for these systems without the 'pawproj'
> option; I didn't realize I was doing this incorrectly! I'll definitely
> make this correction...
> I am still interested in obtaining the wavefunctions however. How do I
> go about getting the "correct" wavefunctions for the PAW method?
>
> Thank you again,
> Hank Seeley
>
>
> On 2016/04/16 07:21, Holzwarth, Natalie wrote:
> > Dear Henry,
> >   In the PAW method, the atomic pseudo basis functions are not
> > designed to be orthogonal to each other, but  there is a "dual
> > relationship" <p_i|\tilde{\psi}_j>=\delta_{ij} with the projector
> > function p_i.   One can use the projector function to estimate the
> > charge associated with an atomic site within the augmentation sphere
> > about that site.   (Some notes are enclosed about this in case you are
> > interested.  The main equations are correct, but the programming
> > details are no longer true.)Paolo Giannozzi programmed this into
> > quantum espresso in version 5.3.0.Perhaps this might suite your
> > needs??   In order to use it you need to use :
> >
> >   
> > pawproj= .true. ,   << new option
> > outdir='$outd/', << old options; change as appropriate
> > prefix='$label',
> > filpdos='pdos',
> > Emin=-25.0, Emax=25.0, DeltaE=0.01,
> > ngauss=0,  degauss=0.01
> > /
> >
> > Sincerely, Natalie Holzwarth
> >
> > N. A. W. Holzwarth   email:
> > nata...@wfu.edu
> > Department of Physics  web:
> > http://www.wfu.edu/~natalie
> > Wake Forest University phone:
> > 1-336-758-5510
> > Winston-Salem, NC 27109 USA office: Rm. 300 Olin
> > Physical Lab
> >
> > On Fri, Apr 15, 2016 at 8:02 PM, Henry J Seeley <hsee...@uoregon.edu>
> > wrote:
> >
> >> Hello all,
> >>
> >> I'm currently trying to use Quantum Espresso to generate the
> >> eigenfunctions for bulk and slab systems of PbS, which I then plan
> >> on projecting onto one another to determine the relative surface or
> >> bulk character of specific slab states. I've generated my sample
> >> systems and have run the scf/nscf calculations, but I've hit some
> >> trouble with the eigenvectors obtained from 'pw_export.x'. I have a
> >> couple questions that I hope some of you may be able to answer. Of
> >> course all my input files will be attached.
> >>
> >> To my surprise I found that different eigenstates of the same system
> >> are NOT orthonormal (<psi_i|psi_i> ~= 0.75, abs(<psi_i|psi_j>) ~=
> >> 0.15). I've done some searching and determined this may have to do
> >> with the PAW psuedo-potentials I am using. Is the PAW method the
> >> problem here?
> >>
> >> In trying to troubleshoot this, I found that eigenstate
> >> orthonormality may be obtained by including the 'uspp_spsi = .TRUE.'
> >> option in the 'pw_export.x' input file, which produces S|psi>, which
> >> is orthonormal by <psi_i|S|psi_j>. Is this correct? If so, how can I
> >> project the two different systems on one another (bulk/slab), i.e.
> >> which system's eigenvector gets the 'S'?
> >>
> >> Finally (and sorry for all the questions at once), I've tried using
> >> the 'uspp_spsi = .TRUE.' option for both the bulk and slab systems,
> >> but I receive an error message for the bulk (but not the slab!):
> >>
> >> *** g

Re: [Pw_forum] Version 5.2.1 for the PP program

[Holzwarth, Natalie]

Dear Filippo,
  Thanks for your helpful comments. We have openmpi version
1.6-intel and the compiler version is intel-2012-lp64.  Please let me
know if more details are needed. I did edit the partialdos.f90 file to
remove the advance="NO". So far,  we have found the 5.2.1 version to
perform well otherwise.Thanks, Natalie


N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab

On Mon, Sep 28, 2015 at 2:54 AM, Filippo Spiga <spiga.fili...@gmail.com>
wrote:

> Dear Natalie,
>
> which version of intel compiler? We need to track these information to fix
> backward compatibility and increase our testing coverage. Anyway, if needed
> I can generate a patch to revert only these specific issue within the next
> 24h.
>
> --
> Mr. Filippo SPIGA, M.Sc.
> Quantum ESPRESSO Foundation
> http://fspiga.github.io ~ skype: filippo.spiga
>
> *
> Disclaimer: "Please note this message and any attachments are CONFIDENTIAL
> and may be privileged or otherwise protected from disclosure. The contents
> are not to be disclosed to anyone other than the addressee. Unauthorized
> recipients are requested to preserve this confidentiality and to advise the
> sender immediately of any error in transmission."
>
> > On Sep 27, 2015, at 11:55 PM, Holzwarth, Natalie <nata...@wfu.edu>
> wrote:
> >
> > In testing the new 5.2.1 version of the program, I noticed that one
> change from 5.1 was in the partial density of states output from
> partialdos.f90 for the title line.
> >
> > For example, in version 5.1, the title line for the pdos output used
> > WRITE(4,'(" pdos(E)   ",$)')
> >
> > while in version 5.2.1 the same pdos output is changed to
> > WRITE(4,'(" pdos(E)   "), advance="NO"')
> >
> > For our intel compiler, the 5.1 version keeps the title line on a single
> line, while the 5.2.1 version puts each piece of the title line on a
> different line.   I guess it is not processing the  advance="NO"
> statement.Since this title line is making the postprocessing difficult,
> I am tempted to put those write statements back to the 5.1 version, or
> perhaps there is a better solution.Thanks in advance for your advice on
> this.   Natalie
> >
> > N. A. W. Holzwarth   email:
> nata...@wfu.edu
> > Department of Physics  web:
> http://www.wfu.edu/~natalie
> > Wake Forest University phone:
> 1-336-758-5510
> > Winston-Salem, NC 27109 USA office: Rm. 300 Olin
> Physical Lab
> > ___
> > Pw_forum mailing list
> > Pw_forum@pwscf.org
> > http://pwscf.org/mailman/listinfo/pw_forum
>
>
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] Version 5.2.1 for the PP program

[Holzwarth, Natalie]

In testing the new 5.2.1 version of the program, I noticed that one change
from 5.1 was in the partial density of states output from partialdos.f90
for the title line.

For example, in version 5.1, the title line for the pdos output used
WRITE(4,'(" pdos(E)   ",$)')

while in version 5.2.1 the same pdos output is changed to
WRITE(4,'(" pdos(E)   "), advance="NO"')

For our intel compiler, the 5.1 version keeps the title line on a single
line, while the 5.2.1 version puts each piece of the title line on a
different line.   I guess it is not processing the  advance="NO"
statement.Since this title line is making the postprocessing difficult,
I am tempted to put those write statements back to the 5.1 version, or
perhaps there is a better solution.Thanks in advance for your advice on
this.   Natalie

N. A. W. Holzwarth   email:
nata...@wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] PAW potentials and ecutrho convergence

[Holzwarth, Natalie]

Dear Joshua,
If you send me the full input file I will be glad to test the PAW
datasets constructed with ATOMPAW code.THe functions on our webpage
http://pwpaw.wfu.edu are mostly focused on accuracy in comparison with the
all-electron results and may not rapidly converge with ecut.  However,
there are several other efforts to generate PAW functions that may converge
more rapidly   Sincerely, Natalie Holzwarth


N. A. W. Holzwarth   email:
natalie at wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab

On Fri, Sep 19, 2014 at 4:16 PM, Joshua Davis 
wrote:

> The plot of the convergence does look like it is oscillating and sort of
> converging to a point but at fairly large energy cut-off. These potentials
> were off the "ready to use" potentials on the QE website.  Would you have
> confidence in the potentials?  PAW is the newest method and there are not
> many of them.  They all use have scalar relativity and not fully
> relativity.  I figured that would be good enough.
>
> Thanks
>
>
>
> 
> Joshua D. Davis
>
> Graduate Assistant
> Department of Chemistry
> Michigan State University
>
> 578 S. Shaw Lane, room 432
> East Lansing, MI 48824
>
> -
>
> On Fri, Sep 19, 2014 at 3:43 PM, Paolo Giannozzi  > wrote:
>
>> Maybe the nonlinear core correction is slowly converging,
>> especially in Sodium which has s and p semicore electrons
>> and a very localized (pseudo-)core charge. Just guessing.
>>
>> P.
>>
>> On Fri, 2014-09-19 at 14:20 -0400, Joshua Davis wrote:
>> > I was performing a convergence test for the energy cut-off for the
>> > density for a set of PAW potentials just to make sure, but I have some
>> > results that confuse me a bit.
>> >
>> >
>> > The compound is a NaB5C (space group: Pm-3m) so the potentials I used
>> > were:
>> >
>> > B.pbe-n-kjpaw_psl.0.1.UPF
>> > C.pbe-n-kjpaw_psl.0.1.UPF
>> > Na.pbe-spn-kjpaw_psl.0.2.UPF
>> >
>> >
>> > The cell was also completely relaxed each time with cell and ion
>> > dynamic being "bfgs" algorithm
>> >
>> >
>> >
>> > Already did a ecutwfc and kpoint convergence test for each and I found
>> > and ecutwfc of 35 Ry and a kpoint mesh of 4x8x8 to be sufficient (I am
>> > calculating a cell doubled in one direction).
>> >
>> >
>> > When I did the ecutwfc convergence test I went from 10 to 50 Ry in
>> > increments of 5 Ry, and I kept the default ecutrho=4*ecutwfc for each
>> > run.
>> >
>> >
>> > so when I did the ecutrho convergence kept ecutwfc at 35 Ry and the
>> > kpoints at 4x8x8 and started at 140 and went to 400 Ry.
>> >
>> >
>> > The graph of my convergence is shown below:
>> > Inline image 1
>> >
>> >
>> > and if the fourm scrubs the image here is the raw data:
>> > ecutrho(Ry),TotalEnergy(ry)
>> > 140,-370.0979858
>> > 150,-370.0980023
>> > 160,-370.0995505
>> > 170,-370.1019804
>> > 180,-370.1047998
>> > 190,-370.1072663
>> > 200,-370.1086284
>> > 250,-370.1048218
>> > 300,-370.1049835
>> > 400,-370.1060986
>> >
>> >
>> >
>> >
>> > The convergence shows a density cut-off of 140 Ry and 150 Ry to be
>> > pretty similar in calculated energy, but after that the calculated
>> > energy quickly drops until a cut-off of 200 Ry.  After that the
>> > calculated energy shoots up at a cut-off of 250 Ry by 0.004 then
>> > tappers down  by 0.002 Ry as it gets to a cut-off of 400 Ry.
>> >
>> >
>> > I thought the energy cut-off for density would be the easiest after
>> > ecutwfc and kpoint, but I want to make sure my results would be fine
>> > based on what I read for he input documentation for ecutrho.  It says
>> > ecutrho=4*ecutwfc is usually good (which is pretty standard for the
>> > PAW method), but I wanted to make sure.  I thought the calculated
>> > energy would not have changed or the calculated energy would have
>> > converged at a reasonable value.
>> >
>> >
>> > Am I doing something wrong? Is the ratio of ecutwfc and ecutrho too
>> > off at the higher energy ecutrho cut-off?  Other posts suggest
>> > lowering ecutwfc and keeping ecutrho cut-off constant for proper
>> > convergence, should I have done this?  I figured sneaking up ecutrho
>> > would be okay.  Am I dumb and this is just an artifact of the PAW
>> > method at a large ratio of ecutwfc to ecutrho?  Is this an artifact of
>> > how the FFT mesh is implemented in QE 5.1?  Should I have not gone
>> > that high in my density cut-off?
>> >
>> >
>> > Any help would be much appreciated.
>> >
>> >
>> > Other considerations:
>> > I used QE 5.1 compiled with ifort 13 and mkl 11.
>> >
>> >
>> >  
>> >calculation = 'vc-relax',
>> >

[Pw_forum] Details of partial density of states calculation

[Holzwarth, Natalie]

Dear Stefano and Lorenzo,
   Thanks for your emails. There are actually 2 threads to my
email.   The first is to understand what is coded now and the second is to
add something in addition to the code if it is desired.On the first
point, you say the projection is onto the reference atomic functions, but I
could not figure out which functions from the PAW dataset were being taken
for this projection. From "reading" the code  It looks like it the  beta
functions which are in fact the projectors. I am not sure if this is
true and/or if these functions are renormalized in some way.   Or perhaps
it is a different function that is taken for this.
   About calculating the partial charges on the basis of the charge in
the augmentation charge, I will be glad to help if that is convenient.   In
addition to terms in the augmentation sphere there would be a contribution
from the plane wave expansion (or pseudo wave) portion of the wavefunction.
  What we did in the past is to just calculate the charge within the sphere
by integrating the Bessel function expansion of the pseudo density for that
state.  If you want to keep the l-components it would be necessary to
modify that pseudo term according to their l-components.   Of course there
are other (perhaps more simple) ways to do this.In principle, this is
not hard, but I would need to understand to code better
  Thanks, Natalie


N. A. W. Holzwarth   email:
natalie at wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Tue, May 14, 2013 at 3:47 AM, Stefano de Gironcoli wrote:

> Dear Natalie, Dear Lorenzo
>
>the code projwfc calculate the projection of the crystal
> wavefunctions on the reference atomic wavefunctions of each atom in
> the cell (after these have bee orthogonalized). as such it strongly
> depends on which atomic wavefunctions are included in the reference
> computation in the atom.
>
>especially in the case these are extended orbitals (like the s-wave
> valence states of transition metals) the projections may not be very
> useful as a way to decompose the dos in atomic contributions.
>
>I think what you suggest, if i understand it correctly, can be a
> useful alternative:
>computing the amount of charge inside the sphere that can be
> assigned to the different angular momentum channels using the PAW
> reconstruction. the piece of information needed, in addition to the
> becp=<beta_a|psi> are the integrals of the corresponding atomic pseudo
> wavefunctions <phi_a|phi_a>_R or <phi_tilte_a|phi_tilde_a>_R+Q_aa
> where phi_a and phi_tilde_a are the AE and PS atomic wavefunctions
> respectively and Q_aa is the integral of the augmentation charge and
> the integrals are limited to the core region inside a radius R.
> something like that...
>
> stefano
>
>
> Quoting "Holzwarth, Natalie" :
>
> > Dear Lorenzo,
> >
> > Thanks for your answer.   I can understand that projwfc may not
> > know about PAW, but  the code apparently calls calbec which seems to
> > calculate the radial integral about an atom <beta|psi> where presumably
> > beta is obtained from the pseudopotential file???Perhaps this
> internal
> > code notation is not consistent with the UPF file?   On the other hand,
> if
> > the notation is consistent, then  the beta term in the UPF file  is the
> > projector for PAW  (I think -- or at least that is true for ATOMPAW).
> > This is the reason for my assumption that <p^a_i|\psi> is calculated to
> > determine the partial density of states.   I am trying to write a paper
> > with some pdos plots and wanted explain what the code does.It seems
> > like my suggestion to provide another option for the code would be a bit
> of
> > work so perhaps can wait.  In any case, it is always good to know what
> has
> > been calculated  Thanks in advance for any further
> > suggestions/discussion.Natalie
> >
> > N. A. W. Holzwarth   email:
> > natalie at wfu.edu
> > Department of Physics  web:
> > http://www.wfu.edu/~natalie
> > Wake Forest University         phone:
> > 1-336-758-5510
> > Winston-Salem, NC 27109 USA office: Rm. 300 Olin
> > Physical Lab
> >
> >
> > On Mon, May 13, 2013 at 5:14 PM, Lorenzo Paulatto <
> > lorenzo.paulatto at impmc.upmc.fr> wrote:
> >
> >> On 

[Pw_forum] Details of partial density of states calculation

[Holzwarth, Natalie]

Dear Lorenzo,

Thanks for your answer.   I can understand that projwfc may not
know about PAW, but  the code apparently calls calbec which seems to
calculate the radial integral about an atom <beta|psi> where presumably
beta is obtained from the pseudopotential file???Perhaps this internal
code notation is not consistent with the UPF file?   On the other hand, if
the notation is consistent, then  the beta term in the UPF file  is the
projector for PAW  (I think -- or at least that is true for ATOMPAW).
This is the reason for my assumption that <p^a_i|\psi> is calculated to
determine the partial density of states.   I am trying to write a paper
with some pdos plots and wanted explain what the code does.It seems
like my suggestion to provide another option for the code would be a bit of
work so perhaps can wait.  In any case, it is always good to know what has
been calculated  Thanks in advance for any further
suggestions/discussion.Natalie

N. A. W. Holzwarth   email:
natalie at wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab


On Mon, May 13, 2013 at 5:14 PM, Lorenzo Paulatto <
lorenzo.paulatto at impmc.upmc.fr> wrote:

> On 05/08/2013 06:43 PM, Holzwarth, Natalie wrote:
>
> > It slightly worries me that the pdos defined in this way is fairly
> > sensitive to the PAW dataset used.I am having a debate with myself
> > about whether it might be good to append a piece of code I wrote long
> > ago to your code to calculate <p^a_i|\psi> and calculate a better
> > estimate of the charge inside the augmentation sphere. (Assuming it
> > would be possible to figure out the details of that code.)   I welcome
> > your advice and commentary.
> >
> Dear Natalie,
> if I remember correctly, the PDOS code is not PAW-aware, i.e. it
> projects on pseudo atomic wavefunctions that it can find in the
> pseudpotential, completely ignoring the PAW projectors and stuff. It
> should depends on the dataset only if the reference configuration is
> changed, but it is true that nobody probably checked it properly.
>
> On the other hand, there is a code that reconstructs the PAW charge
> (it's pawplot.f90 in the PP/src directory), I do not know if it has
> anything in common with what you did. I'll have a look at it if you
> wish, if it improves prowfc it is of course welcome.
>
> bests
>
>
>
> --
> Dr. Lorenzo Paulatto
> IdR @ IMPMC -- CNRS & Universit? Paris 6
> phone:+33 (0)1 44275 084 / skype: paulatz
> www:  http://www-int.impmc.upmc.fr/~paulatto/
> mail: 23-24/4?16 Bo?te courrier 115, 4 place Jussieu 75252 Paris C?dex 5
>
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://pwscf.org/pipermail/pw_forum/attachments/20130513/414d2171/attachment.html
 

[Pw_forum] Details of partial density of states calculation

[Holzwarth, Natalie]

(I tried to send this email a few days ago but since it did not appear in
the forum, I assume it got lost.   Apologies in advance if this is an
annoying duplication.)

This is a very basic question about the partial density of states
calculation using the projwfc.f90 program within the PAW mode.   In reading
the fortran code, it seems that the weighting factor that is calculated is
based on the atom-center projector functions |p^a_i> where a is the atomic
site and i represents the radial and spherical harmonic quantum numbers.
Is it correct that what is written to the pdos output files is the partial
densities with the weight factors ||^2, organized by atom
number a and l_i?

What I wanted to estimate is the charge within the augmentation sphere of
each atom
for each state, but the sum of all of the ||^2 coefficients is
not really that.  The code is somewhat complicated so perhaps there is some
rescaling ??   Or perhaps there is a different code to estimate those
charges?  Or perhaps there is some experience that the existing code is
good good enough for the qualitative analysis of most studies.

It slightly worries me that the pdos defined in this way is fairly
sensitive to the PAW dataset used.I am having a debate with myself
about whether it might be good to append a piece of code I wrote long ago
to your code to calculate  and calculate a better estimate of
the charge inside the augmentation sphere. (Assuming it would be possible
to figure out the details of that code.)   I welcome your advice and
commentary.

 Thanks, Natalie
N. A. W. Holzwarth   email:
natalie at wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab
-- next part --
An HTML attachment was scrubbed...
URL: 
http://pwscf.org/pipermail/pw_forum/attachments/20130508/b953a576/attachment.html
 

[Pw_forum] Details of partial density of states calculation

[Holzwarth, Natalie]

This is a very basic question which I am not too proud to ask (although
perhaps I should be).It has to do with how the projected density of
states is coded for the PAW case in projwfc.f90 pgm.   From reading the
fortran code, I came up with the explanation attached to this email.
Since I am not interested in the l-decomposition of the partial density of
states, all of the ldos(E) terms were summed for each site.  It is not
clear whether there may be some sophisticated scaling factors involved so I
wanted to check with the forum. Or perhaps there is a description in
the literature or on your webpage that answers this question.  Thanks in
advance for your attention. Natalie Holzwarth

N. A. W. Holzwarth   email:
natalie at wfu.edu
Department of Physics  web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab
-- next part --
An HTML attachment was scrubbed...
URL: 
http://pwscf.org/pipermail/pw_forum/attachments/20130505/8efcd1c1/attachment.html
 
-- next part --
A non-text attachment was scrubbed...
Name: PDOS.pdf
Type: application/pdf
Size: 123574 bytes
Desc: not available
Url : 
http://pwscf.org/pipermail/pw_forum/attachments/20130505/8efcd1c1/attachment.pdf
 

[Pw_forum] negative dr2

[Holzwarth, Natalie]

Dear Dan,

I have seen this error in several cases particularly for transition metals
and
for basis and projector functions generated by our atompaw program.  My
understanding
(based on a discussion with Stefano de Gironcoli) is that the program stops
when the
program detects a certain product of one-center terms to be negative.   In
my experience
these terms can be negative before convergence and I have commented out the
offending
line.   In my tests, this allows the program to converge consistently in the
tests I have done.
This is not necessarily safe or well-tested and I did promise to look into
it further.   In case
you would like to also try, the offending line in 4.2.1 is line 553 in
sct_mod.f90:

  IF (okpaw) rho_ddot = rho_ddot + paw_ddot(rho1%bec, rho2%bec)

I repeat that commenting out this line may not be a good idea, but it has
worked for me in
limited tests.  (I still hope to do more tests.)


 Sincerely,

  Natalie Holzwarth

N. A. W. Holzwarth   email:
natalie at wfu.edu
Department of Physics web:
http://www.wfu.edu/~natalie
Wake Forest University phone:
1-336-758-5510
Winston-Salem, NC 27109 USA office: Rm. 300 Olin
Physical Lab

On Wed, Jul 6, 2011 at 5:54 AM, Dan Fors  wrote:

> Dear users,
>
> I am running a simple 2-atomic non-magnetic (NM) bcc Cr system (see
> below for the input file)  with v.4.2.1 and I keep getting an error
> message regarding a negative dr2:
>
> from mix_rho : error # 1
> negative dr2
>
> This error occurs for values close to as well as away from the
> estimated equilibrium volume. What is the possible the origins of this
> error and how may I eliminate it?
>
> I have tried to change the mixing_beta in the range 0.1 to 0.8, as
> well as changing the mixing mode to 'TF'. I have also tried to set
> nspin = 2 with a zero start magnetisation since an anti-ferromagnetic
> (AFM) start configuration does not give rise to the problem (but
> yields the AFM solution instead of the NM one). However. this also
> gives the error. Finally, I tested to use ibrav = 3 and with only one
> atom in the cell, but I still get the above error.
>
> What I have noticed is that in the AFM case I get a couple of very
> flat bands in the bandstructure just above the Fermi level. If I
> change to a USPP potential or an alternative PAW potential these bands
> disappear, and the above error does not occur. Can the potential I use
> in the present case be the source to the error, and if yes, what is
> the reason behind it?
>
> I would appreciate any help or suggestions.
>
> Dan
>
>
>
> %-
>
> 
>calculation = 'scf',
>restart_mode = 'from_scratch',
>prefix = 'Cr',
>tstress = .true.,
>tprnfor = .true.,
>pseudo_dir =
> '/home/forsdan/PROGRAMS/QUANTUM_ESPRESSO/espresso-4.2.1_intel/pseudo/',
>outdir = '/home/forsdan/FeCr_PROJECT/TEMP_PAW/'
> /
> 
>ibrav =  1, celldm(1) = 5.378798, nat =  2, ntyp = 1,
>ecutwfc = 40.0, ecutrho = 180.0, nbnd = 14
>occupations = 'smearing',
>smearing = 'mp', degauss = 0.022,
>nspin = 1,
> /
> 
>electron_maxstep = 100,
>conv_thr =  1.0d-8,
>diagonalization = 'cg',
>mixing_mode = 'plain',
>mixing_beta = 0.3
> /
> ATOMIC_SPECIES
>  Cr  51.996  Cr.pbe-paw_kj_6.UPF
> ATOMIC_POSITIONS {crystal}
>  Cr 0.00 0.00 0.00
>  Cr 0.50 0.50 0.50
> K_POINTS {automatic}
>  12 12 12 0 0 0
>
> %-
> ___
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
>
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www.democritos.it/pipermail/pw_forum/attachments/20110706/dca1903f/attachment.htm