Re: [Pw_forum] Problem: different output with identical input

2016-12-29 Thread Pietro Delugas 

Dear Pablo

Final Coordinates and Job Done do not mean that  relaxation reached 
convergence you may have reached the max number of steps and relaxation 
stopped.


Check few lines before "Begin Final coordinates" you should find 
something like "bfgs converged in  scf cycles"


Did you try to use the same relaxation run for the 2 different first 
steps ? Do final results coincide in this case ?



On 28/12/2016 19:01, Pablo García Risueño wrote:

Dear Stefano

Thank you very much for your reply. I answer to your questions below.

2016-12-28 16:29 GMT+01:00 Stefano de Gironcoli >:


Dear Pablo Garcia Risueño

I'm not sure I understand the problem.
the two final positions for ecut=30 are identical to my eyes.
the two final positions for ecut=60 differ by about 10-5 A. !
If the property you are interested in depends so strongly on the
atomic positions you better learn how to live with it. Even assuming
that you are using perfect xc functional, perfect pseudopotentials and
converged cutoff and k-points (which likely you don't), your
calculation is neglecting zero point energy, thermal expansion,
quantum nature of H motion, ...
/
/

/Yes, my concern is not that the results are not perfect (of course 
DFT makes non-negligible errors). My concern is that fully identical 
input files run in the same machine and with the same executable 
provide different results./


As for your specific question. In principle if you tighten enough
the convergence the minima should tend to converge toward a common
value. However the stopping criteria will make the two calculations
stop as soon they are satisfied. In your case as soon as each force
component is lower than 10-6 Ry/au and the energy does not change more
that 10-8. Did the calculation complete ? 10-8 for the energy is
easily reachable but 10-6 for the forces looks to me very demanding.
/
/

/Yes, the calculations do finish. I read 'Begin final coordinates' 
(...) and 'JOB DONE' at the end of the output files. My system is very 
small (just 26 atoms and 56 electrons)./


  Anyhow... even if the relaxation did complete successfully two
equivalent calculations may still differ. If you run your calculations
with exactly the same input on exactly the same machine with exactly
the same mpi setup the results should be identical 


/This is exactly what I do./

..but why doing
twice exactly the same calculation ?. 

/The 'relax' calculation is the first step of a complicated process. I 
run two different calculations because the 6th step of the process is 
different. I obtained very different results at the end of the full 
process; then I tried to trace back the differences. And then I saw 
that despite the fact that the 1st step is identical for two different 
runs, the results of the 1st step are different. This made me think 
that there might be a bug, or a wrong parameter in my input files./


If however you change anything
in the input (Davidson vs CG, starting wavefunction options, mixing
mode, BFGS-related parameters) or parallel computational setup the
relaxation history will be slightly different and the final
configurations will differ by a certain amount allowed by the
tolerance defined by your stopping criteria.

/I changed nothing, this is why I am surprised with the results.../


Thank you very much for your attention. Best regards.


  HTH

stefano

Quoting Pablo García Risueño >:

> Dear professor
>
> Thank you very much for your reply. The differences are
important in this
> case, my final calculated quantities are very sensitive to these
optimized
> positions. Should I change any of the ***conv_thr variables, or
other
> variable, to have the same result for same inputs?
>
> Is there any random number in the algorithm of relax
calculations, can we
> be sure that different outputs with the same input are not due
to any bug?
>
> Thank you very much. Best regards.
>
> 2016-12-28 14:10 GMT+01:00 Paolo Giannozzi
>:
>
>> The differences you find are very small. Nothing to worry about
in my
>> opinion.
>>
>> By the way: Davidson diagonalization is typically faster than
CG; do not
>> specify incompatible options in K_POINTS (gamma or automatic,
not both;
>> gamma should be used unless you have a good reason not to)
>>
>> Paolo
>>
>> Il 28/dic/2016 01:46 PM, "Pablo García Risueño"
>
>> ha scritto:
>> >
>> > Dear Espresso community
>> >
>> > I have one problem that is important for me; it is somewhat
surprising.
>> I run

Re: [Pw_forum] Problem: different output with identical input

2016-12-28 Thread Pablo García Risueño 
Dear Stefano

Thank you very much for your reply. I answer to your questions below.

2016-12-28 16:29 GMT+01:00 Stefano de Gironcoli :

> Dear Pablo Garcia Risueño
>
> I'm not sure I understand the problem.
> the two final positions for ecut=30 are identical to my eyes.
> the two final positions for ecut=60 differ by about 10-5 A. !
> If the property you are interested in depends so strongly on the
> atomic positions you better learn how to live with it. Even assuming
> that you are using perfect xc functional, perfect pseudopotentials and
> converged cutoff and k-points (which likely you don't), your
> calculation is neglecting zero point energy, thermal expansion,
> quantum nature of H motion, ...
>
> *Yes, my concern is not that the results are not perfect (of course DFT
makes non-negligible errors). My concern is that fully identical input
files run in the same machine and with the same executable provide
different results.*


> As for your specific question. In principle if you tighten enough
> the convergence the minima should tend to converge toward a common
> value. However the stopping criteria will make the two calculations
> stop as soon they are satisfied. In your case as soon as each force
> component is lower than 10-6 Ry/au and the energy does not change more
> that 10-8. Did the calculation complete ? 10-8 for the energy is
> easily reachable but 10-6 for the forces looks to me very demanding.
>
> *Yes, the calculations do finish. I read 'Begin final coordinates' (...)
and 'JOB DONE' at the end of the output files. My system is very small
(just 26 atoms and 56 electrons).*


>   Anyhow... even if the relaxation did complete successfully two
> equivalent calculations may still differ. If you run your calculations
> with exactly the same input on exactly the same machine with exactly
> the same mpi setup the results should be identical

*This is exactly what I do.*


> ..but why doing
> twice exactly the same calculation ?.

*The 'relax' calculation is the first step of a complicated process. I run
two different calculations because the 6th step of the process is
different. I obtained very different results at the end of the full
process; then I tried to trace back the differences. And then I saw that
despite the fact that the 1st step is identical for two different runs, the
results of the 1st step are different. This made me think that there might
be a bug, or a wrong parameter in my input files.*


> If however you change anything
> in the input (Davidson vs CG, starting wavefunction options, mixing
> mode, BFGS-related parameters) or parallel computational setup the
> relaxation history will be slightly different and the final
> configurations will differ by a certain amount allowed by the
> tolerance defined by your stopping criteria.
>
*I changed nothing, this is why I am surprised with the results...*


Thank you very much for your attention. Best regards.


  HTH
>
> stefano
>
> Quoting Pablo García Risueño :
>
> > Dear professor
> >
> > Thank you very much for your reply. The differences are important in this
> > case, my final calculated quantities are very sensitive to these
> optimized
> > positions. Should I change any of the ***conv_thr variables, or other
> > variable, to have the same result for same inputs?
> >
> > Is there any random number in the algorithm of relax calculations, can we
> > be sure that different outputs with the same input are not due to any
> bug?
> >
> > Thank you very much. Best regards.
> >
> > 2016-12-28 14:10 GMT+01:00 Paolo Giannozzi :
> >
> >> The differences you find are very small. Nothing to worry about in my
> >> opinion.
> >>
> >> By the way: Davidson diagonalization is typically faster than CG; do not
> >> specify incompatible options in K_POINTS (gamma or automatic, not both;
> >> gamma should be used unless you have a good reason not to)
> >>
> >> Paolo
> >>
> >> Il 28/dic/2016 01:46 PM, "Pablo García Risueño" <
> garcia.risu...@gmail.com>
> >> ha scritto:
> >> >
> >> > Dear Espresso community
> >> >
> >> > I have one problem that is important for me; it is somewhat
> surprising.
> >> I run geometry optimization (relax) calculations with pw.x with
> identical
> >> input files, and I obtain rather different final coordinates. The
> problem
> >> does not happen if ecutwfc is 30, but it does appear for cutoffs of 60,
> 80
> >> or 90. Below one can see the exact input file, and examples of the
> >> difference between the final coordinates for both runs (both run with
> >> identical input) for given cutoffs.
> >> >
> >> > Could anybody give me a clue on the origin of the problem, and how to
> >> solve it?
> >> >
> >> > Thank you very much. Best regards.
> >> >
> >> >
> >> >
> >> > Input file:
> >> >
> >> >
> >> >
> >> > 
> >> >
> >> > calculation = 'relax',
> >> >
> >> > restart_mode = 'from_scratch',
> >> >
> >> > prefix='',
> >> >
> >> >

Re: [Pw_forum] Problem: different output with identical input

2016-12-28 Thread Stefano de Gironcoli 
Dear Pablo Garcia Risueño

I'm not sure I understand the problem.
the two final positions for ecut=30 are identical to my eyes.
the two final positions for ecut=60 differ by about 10-5 A. !
If the property you are interested in depends so strongly on the  
atomic positions you better learn how to live with it. Even assuming  
that you are using perfect xc functional, perfect pseudopotentials and  
converged cutoff and k-points (which likely you don't), your  
calculation is neglecting zero point energy, thermal expansion,  
quantum nature of H motion, ...

As for your specific question. In principle if you tighten enough  
the convergence the minima should tend to converge toward a common  
value. However the stopping criteria will make the two calculations  
stop as soon they are satisfied. In your case as soon as each force  
component is lower than 10-6 Ry/au and the energy does not change more  
that 10-8. Did the calculation complete ? 10-8 for the energy is  
easily reachable but 10-6 for the forces looks to me very demanding.

  Anyhow... even if the relaxation did complete successfully two  
equivalent calculations may still differ. If you run your calculations  
with exactly the same input on exactly the same machine with exactly  
the same mpi setup the results should be identical ..but why doing  
twice exactly the same calculation ?. If however you change anything  
in the input (Davidson vs CG, starting wavefunction options, mixing  
mode, BFGS-related parameters) or parallel computational setup the  
relaxation history will be slightly different and the final  
configurations will differ by a certain amount allowed by the  
tolerance defined by your stopping criteria.

  HTH

stefano

Quoting Pablo García Risueño :

> Dear professor
>
> Thank you very much for your reply. The differences are important in this
> case, my final calculated quantities are very sensitive to these optimized
> positions. Should I change any of the ***conv_thr variables, or other
> variable, to have the same result for same inputs?
>
> Is there any random number in the algorithm of relax calculations, can we
> be sure that different outputs with the same input are not due to any bug?
>
> Thank you very much. Best regards.
>
> 2016-12-28 14:10 GMT+01:00 Paolo Giannozzi :
>
>> The differences you find are very small. Nothing to worry about in my
>> opinion.
>>
>> By the way: Davidson diagonalization is typically faster than CG; do not
>> specify incompatible options in K_POINTS (gamma or automatic, not both;
>> gamma should be used unless you have a good reason not to)
>>
>> Paolo
>>
>> Il 28/dic/2016 01:46 PM, "Pablo García Risueño" 
>> ha scritto:
>> >
>> > Dear Espresso community
>> >
>> > I have one problem that is important for me; it is somewhat surprising.
>> I run geometry optimization (relax) calculations with pw.x with identical
>> input files, and I obtain rather different final coordinates. The problem
>> does not happen if ecutwfc is 30, but it does appear for cutoffs of 60, 80
>> or 90. Below one can see the exact input file, and examples of the
>> difference between the final coordinates for both runs (both run with
>> identical input) for given cutoffs.
>> >
>> > Could anybody give me a clue on the origin of the problem, and how to
>> solve it?
>> >
>> > Thank you very much. Best regards.
>> >
>> >
>> >
>> > Input file:
>> >
>> >
>> >
>> > 
>> >
>> > calculation = 'relax',
>> >
>> > restart_mode = 'from_scratch',
>> >
>> > prefix='',
>> >
>> > outdir = './',
>> >
>> > pseudo_dir = '/path_xxx/PP/',
>> >
>> > forc_conv_thr = 1.0D-6 ,
>> >
>> > etot_conv_thr = 1.0D-8 ,
>> >
>> >  /
>> >
>> > 
>> >
>> > ibrav = 0, a=18.0,
>> >
>> > nat= 26, ntyp= 2,
>> >
>> > ecutwfc = 30d0,
>> >
>> > nbnd = 100,
>> >
>> > /
>> >
>> > 
>> >
>> > conv_thr = 1.0e-9,
>> >
>> > mixing_beta = 0.7,
>> >
>> > mixing_mode = 'plain',
>> >
>> > diagonalization = 'cg'
>> >
>> > /
>> >
>> > 
>> >
>> > /
>> >
>> >
>> >
>> > ATOMIC_SPECIES
>> >
>> > C   12.0107   C.pz-vbc.UPF
>> >
>> > H   1.007825035  H.pz-vbc.UPF
>> >
>> >
>> >
>> > ATOMIC_POSITIONS { angstrom }
>> >
>> > C  8.891700e+00 8.891700e+00 8.891700e+00
>> >
>> > C  9.783400e+00 9.783400e+00 8.00e+00
>> >
>> > C  9.783400e+00 8.00e+00 9.783400e+00
>> >
>> > C  8.00e+00 9.783400e+00 9.783400e+00
>> >
>> > C  8.891700e+00 1.067510e+01 1.067510e+01
>> >
>> > C  1.067510e+01 1.067510e+01 8.891700e+00
>> >
>> > C  1.067510e+01 8.891700e+00 1.067510e+01
>> >
>> > C  9.783400e+00 1.156680e+01 9.783400e+00
>> >
>> > C  9.783400e+00 9.783400e+00 1.156680e+01
>> >
>> > C  1.156680e+01 9.783400e+00 9.783400e+00
>> >
>> > H  8.391700e+00 8.391700e+00 8.391700e+00
>> >
>> > H  7.50e+00 1.028340e+01 9.283400e+00
>> >
>> > H

Re: [Pw_forum] Problem: different output with identical input

2016-12-28 Thread Paolo Giannozzi 
If the quantity you are trying to compute is sensitive to differences of
the order of 4*10^{-5} A in atomic positions, you have chosen an hopeless
task, in my opinion.

Paolo

Il 28/dic/2016 02:18 PM, "Pablo García Risueño" 
ha scritto:

> Dear professor
>
> Thank you very much for your reply. The differences are important in this
> case, my final calculated quantities are very sensitive to these optimized
> positions. Should I change any of the ***conv_thr variables, or other
> variable, to have the same result for same inputs?
>
> Is there any random number in the algorithm of relax calculations, can we
> be sure that different outputs with the same input are not due to any bug?
>
> Thank you very much. Best regards.
>
> 2016-12-28 14:10 GMT+01:00 Paolo Giannozzi :
>
>> The differences you find are very small. Nothing to worry about in my
>> opinion.
>>
>> By the way: Davidson diagonalization is typically faster than CG; do not
>> specify incompatible options in K_POINTS (gamma or automatic, not both;
>> gamma should be used unless you have a good reason not to)
>>
>> Paolo
>>
>> Il 28/dic/2016 01:46 PM, "Pablo García Risueño" 
>> ha scritto:
>> >
>> > Dear Espresso community
>> >
>> > I have one problem that is important for me; it is somewhat surprising.
>> I run geometry optimization (relax) calculations with pw.x with identical
>> input files, and I obtain rather different final coordinates. The problem
>> does not happen if ecutwfc is 30, but it does appear for cutoffs of 60, 80
>> or 90. Below one can see the exact input file, and examples of the
>> difference between the final coordinates for both runs (both run with
>> identical input) for given cutoffs.
>> >
>> > Could anybody give me a clue on the origin of the problem, and how to
>> solve it?
>> >
>> > Thank you very much. Best regards.
>> >
>> >
>> >
>> > Input file:
>> >
>> >
>> >
>> > 
>> >
>> > calculation = 'relax',
>> >
>> > restart_mode = 'from_scratch',
>> >
>> > prefix='',
>> >
>> > outdir = './',
>> >
>> > pseudo_dir = '/path_xxx/PP/',
>> >
>> > forc_conv_thr = 1.0D-6 ,
>> >
>> > etot_conv_thr = 1.0D-8 ,
>> >
>> >  /
>> >
>> > 
>> >
>> > ibrav = 0, a=18.0,
>> >
>> > nat= 26, ntyp= 2,
>> >
>> > ecutwfc = 30d0,
>> >
>> > nbnd = 100,
>> >
>> > /
>> >
>> > 
>> >
>> > conv_thr = 1.0e-9,
>> >
>> > mixing_beta = 0.7,
>> >
>> > mixing_mode = 'plain',
>> >
>> > diagonalization = 'cg'
>> >
>> > /
>> >
>> > 
>> >
>> > /
>> >
>> >
>> >
>> > ATOMIC_SPECIES
>> >
>> > C   12.0107   C.pz-vbc.UPF
>> >
>> > H   1.007825035  H.pz-vbc.UPF
>> >
>> >
>> >
>> > ATOMIC_POSITIONS { angstrom }
>> >
>> > C  8.891700e+00 8.891700e+00 8.891700e+00
>> >
>> > C  9.783400e+00 9.783400e+00 8.00e+00
>> >
>> > C  9.783400e+00 8.00e+00 9.783400e+00
>> >
>> > C  8.00e+00 9.783400e+00 9.783400e+00
>> >
>> > C  8.891700e+00 1.067510e+01 1.067510e+01
>> >
>> > C  1.067510e+01 1.067510e+01 8.891700e+00
>> >
>> > C  1.067510e+01 8.891700e+00 1.067510e+01
>> >
>> > C  9.783400e+00 1.156680e+01 9.783400e+00
>> >
>> > C  9.783400e+00 9.783400e+00 1.156680e+01
>> >
>> > C  1.156680e+01 9.783400e+00 9.783400e+00
>> >
>> > H  8.391700e+00 8.391700e+00 8.391700e+00
>> >
>> > H  7.50e+00 1.028340e+01 9.283400e+00
>> >
>> > H  7.50e+00 9.283400e+00 1.028340e+01
>> >
>> > H  9.283400e+00 1.028340e+01 7.50e+00
>> >
>> > H  1.028340e+01 9.283400e+00 7.50e+00
>> >
>> > H  9.283400e+00 7.50e+00 1.028340e+01
>> >
>> > H  1.028340e+01 7.50e+00 9.283400e+00
>> >
>> > H  9.283400e+00 1.206680e+01 9.283400e+00
>> >
>> > H  1.206680e+01 9.283400e+00 9.283400e+00
>> >
>> > H  9.283400e+00 9.283400e+00 1.206680e+01
>> >
>> > H  8.391700e+00 1.117510e+01 1.117510e+01
>> >
>> > H  1.117510e+01 1.117510e+01 8.391700e+00
>> >
>> > H  1.117510e+01 8.391700e+00 1.117510e+01
>> >
>> > H  1.028340e+01 1.206680e+01 1.028340e+01
>> >
>> > H  1.028340e+01 1.028340e+01 1.206680e+01
>> >
>> > H  1.206680e+01 1.028340e+01 1.028340e+01
>> >
>> >
>> >
>> >
>> >
>> > CELL_PARAMETERS {cubic}
>> >
>> >  1.00  0.00  0.00
>> >
>> >  0.00  1.00  0.00
>> >
>> >  0.00  0.00  1.00
>> >
>> >
>> >
>> > K_POINTS {gamma} {automatic}
>> >
>> > 1 1 1  0 0 0
>> >
>> >
>> >
>> >
>> >
>> > The program is run with
>> >
>> >
>> >
>> > mpirun -np 32 /path_xxx/pw.x
>> >
>> >
>> >
>> > Final coordinates: The first two rows for ecutwfc=30 for two runs with
>> identical input are:
>> >
>> > ATOMIC_POSITIONS (angstrom)
>> > C  8.898432121  8.898432121  8.898432121
>> > C  9.783306562  9.783306562  8.019670107
>> >
>> > ATOMIC_POSITIONS (angstrom)
>> > C  8.898432121  8.898432121  8.898432121
>> > C  9.783306562  9.783306562  8.019670109
>> >
>> >
>> > Final

Re: [Pw_forum] Problem: different output with identical input

2016-12-28 Thread Pablo García Risueño 
Dear professor

Thank you very much for your reply. The differences are important in this
case, my final calculated quantities are very sensitive to these optimized
positions. Should I change any of the ***conv_thr variables, or other
variable, to have the same result for same inputs?

Is there any random number in the algorithm of relax calculations, can we
be sure that different outputs with the same input are not due to any bug?

Thank you very much. Best regards.

2016-12-28 14:10 GMT+01:00 Paolo Giannozzi :

> The differences you find are very small. Nothing to worry about in my
> opinion.
>
> By the way: Davidson diagonalization is typically faster than CG; do not
> specify incompatible options in K_POINTS (gamma or automatic, not both;
> gamma should be used unless you have a good reason not to)
>
> Paolo
>
> Il 28/dic/2016 01:46 PM, "Pablo García Risueño" 
> ha scritto:
> >
> > Dear Espresso community
> >
> > I have one problem that is important for me; it is somewhat surprising.
> I run geometry optimization (relax) calculations with pw.x with identical
> input files, and I obtain rather different final coordinates. The problem
> does not happen if ecutwfc is 30, but it does appear for cutoffs of 60, 80
> or 90. Below one can see the exact input file, and examples of the
> difference between the final coordinates for both runs (both run with
> identical input) for given cutoffs.
> >
> > Could anybody give me a clue on the origin of the problem, and how to
> solve it?
> >
> > Thank you very much. Best regards.
> >
> >
> >
> > Input file:
> >
> >
> >
> > 
> >
> > calculation = 'relax',
> >
> > restart_mode = 'from_scratch',
> >
> > prefix='',
> >
> > outdir = './',
> >
> > pseudo_dir = '/path_xxx/PP/',
> >
> > forc_conv_thr = 1.0D-6 ,
> >
> > etot_conv_thr = 1.0D-8 ,
> >
> >  /
> >
> > 
> >
> > ibrav = 0, a=18.0,
> >
> > nat= 26, ntyp= 2,
> >
> > ecutwfc = 30d0,
> >
> > nbnd = 100,
> >
> > /
> >
> > 
> >
> > conv_thr = 1.0e-9,
> >
> > mixing_beta = 0.7,
> >
> > mixing_mode = 'plain',
> >
> > diagonalization = 'cg'
> >
> > /
> >
> > 
> >
> > /
> >
> >
> >
> > ATOMIC_SPECIES
> >
> > C   12.0107   C.pz-vbc.UPF
> >
> > H   1.007825035  H.pz-vbc.UPF
> >
> >
> >
> > ATOMIC_POSITIONS { angstrom }
> >
> > C  8.891700e+00 8.891700e+00 8.891700e+00
> >
> > C  9.783400e+00 9.783400e+00 8.00e+00
> >
> > C  9.783400e+00 8.00e+00 9.783400e+00
> >
> > C  8.00e+00 9.783400e+00 9.783400e+00
> >
> > C  8.891700e+00 1.067510e+01 1.067510e+01
> >
> > C  1.067510e+01 1.067510e+01 8.891700e+00
> >
> > C  1.067510e+01 8.891700e+00 1.067510e+01
> >
> > C  9.783400e+00 1.156680e+01 9.783400e+00
> >
> > C  9.783400e+00 9.783400e+00 1.156680e+01
> >
> > C  1.156680e+01 9.783400e+00 9.783400e+00
> >
> > H  8.391700e+00 8.391700e+00 8.391700e+00
> >
> > H  7.50e+00 1.028340e+01 9.283400e+00
> >
> > H  7.50e+00 9.283400e+00 1.028340e+01
> >
> > H  9.283400e+00 1.028340e+01 7.50e+00
> >
> > H  1.028340e+01 9.283400e+00 7.50e+00
> >
> > H  9.283400e+00 7.50e+00 1.028340e+01
> >
> > H  1.028340e+01 7.50e+00 9.283400e+00
> >
> > H  9.283400e+00 1.206680e+01 9.283400e+00
> >
> > H  1.206680e+01 9.283400e+00 9.283400e+00
> >
> > H  9.283400e+00 9.283400e+00 1.206680e+01
> >
> > H  8.391700e+00 1.117510e+01 1.117510e+01
> >
> > H  1.117510e+01 1.117510e+01 8.391700e+00
> >
> > H  1.117510e+01 8.391700e+00 1.117510e+01
> >
> > H  1.028340e+01 1.206680e+01 1.028340e+01
> >
> > H  1.028340e+01 1.028340e+01 1.206680e+01
> >
> > H  1.206680e+01 1.028340e+01 1.028340e+01
> >
> >
> >
> >
> >
> > CELL_PARAMETERS {cubic}
> >
> >  1.00  0.00  0.00
> >
> >  0.00  1.00  0.00
> >
> >  0.00  0.00  1.00
> >
> >
> >
> > K_POINTS {gamma} {automatic}
> >
> > 1 1 1  0 0 0
> >
> >
> >
> >
> >
> > The program is run with
> >
> >
> >
> > mpirun -np 32 /path_xxx/pw.x
> >
> >
> >
> > Final coordinates: The first two rows for ecutwfc=30 for two runs with
> identical input are:
> >
> > ATOMIC_POSITIONS (angstrom)
> > C  8.898432121  8.898432121  8.898432121
> > C  9.783306562  9.783306562  8.019670107
> >
> > ATOMIC_POSITIONS (angstrom)
> > C  8.898432121  8.898432121  8.898432121
> > C  9.783306562  9.783306562  8.019670109
> >
> >
> > Final coordinates: The first two rows for ecutwfc=60 for two runs with
> identical input are:
> >
> > ATOMIC_POSITIONS (angstrom)
> > C  8.904988579  8.904988579  8.904988579
> > C  9.783426086  9.783426086  8.031809869
> >
> > ATOMIC_POSITIONS (angstrom)
> > C  8.904962246  8.904962246  8.904962246
> > C  9.783425401  9.783425401  8.031847251
> >
> > --
> > --
> >
> > Dr. Pablo García Risueño
> >
> > Institut für Physikalische Chemie, Universität Hamburg, Grindelallee
> 117, 20146

Re: [Pw_forum] Problem: different output with identical input

2016-12-28 Thread Paolo Giannozzi 
The differences you find are very small. Nothing to worry about in my
opinion.

By the way: Davidson diagonalization is typically faster than CG; do not
specify incompatible options in K_POINTS (gamma or automatic, not both;
gamma should be used unless you have a good reason not to)

Paolo
Il 28/dic/2016 01:46 PM, "Pablo García Risueño" 
ha scritto:
>
> Dear Espresso community
>
> I have one problem that is important for me; it is somewhat surprising. I
run geometry optimization (relax) calculations with pw.x with identical
input files, and I obtain rather different final coordinates. The problem
does not happen if ecutwfc is 30, but it does appear for cutoffs of 60, 80
or 90. Below one can see the exact input file, and examples of the
difference between the final coordinates for both runs (both run with
identical input) for given cutoffs.
>
> Could anybody give me a clue on the origin of the problem, and how to
solve it?
>
> Thank you very much. Best regards.
>
>
>
> Input file:
>
>
>
> 
>
> calculation = 'relax',
>
> restart_mode = 'from_scratch',
>
> prefix='',
>
> outdir = './',
>
> pseudo_dir = '/path_xxx/PP/',
>
> forc_conv_thr = 1.0D-6 ,
>
> etot_conv_thr = 1.0D-8 ,
>
>  /
>
> 
>
> ibrav = 0, a=18.0,
>
> nat= 26, ntyp= 2,
>
> ecutwfc = 30d0,
>
> nbnd = 100,
>
> /
>
> 
>
> conv_thr = 1.0e-9,
>
> mixing_beta = 0.7,
>
> mixing_mode = 'plain',
>
> diagonalization = 'cg'
>
> /
>
> 
>
> /
>
>
>
> ATOMIC_SPECIES
>
> C   12.0107   C.pz-vbc.UPF
>
> H   1.007825035  H.pz-vbc.UPF
>
>
>
> ATOMIC_POSITIONS { angstrom }
>
> C  8.891700e+00 8.891700e+00 8.891700e+00
>
> C  9.783400e+00 9.783400e+00 8.00e+00
>
> C  9.783400e+00 8.00e+00 9.783400e+00
>
> C  8.00e+00 9.783400e+00 9.783400e+00
>
> C  8.891700e+00 1.067510e+01 1.067510e+01
>
> C  1.067510e+01 1.067510e+01 8.891700e+00
>
> C  1.067510e+01 8.891700e+00 1.067510e+01
>
> C  9.783400e+00 1.156680e+01 9.783400e+00
>
> C  9.783400e+00 9.783400e+00 1.156680e+01
>
> C  1.156680e+01 9.783400e+00 9.783400e+00
>
> H  8.391700e+00 8.391700e+00 8.391700e+00
>
> H  7.50e+00 1.028340e+01 9.283400e+00
>
> H  7.50e+00 9.283400e+00 1.028340e+01
>
> H  9.283400e+00 1.028340e+01 7.50e+00
>
> H  1.028340e+01 9.283400e+00 7.50e+00
>
> H  9.283400e+00 7.50e+00 1.028340e+01
>
> H  1.028340e+01 7.50e+00 9.283400e+00
>
> H  9.283400e+00 1.206680e+01 9.283400e+00
>
> H  1.206680e+01 9.283400e+00 9.283400e+00
>
> H  9.283400e+00 9.283400e+00 1.206680e+01
>
> H  8.391700e+00 1.117510e+01 1.117510e+01
>
> H  1.117510e+01 1.117510e+01 8.391700e+00
>
> H  1.117510e+01 8.391700e+00 1.117510e+01
>
> H  1.028340e+01 1.206680e+01 1.028340e+01
>
> H  1.028340e+01 1.028340e+01 1.206680e+01
>
> H  1.206680e+01 1.028340e+01 1.028340e+01
>
>
>
>
>
> CELL_PARAMETERS {cubic}
>
>  1.00  0.00  0.00
>
>  0.00  1.00  0.00
>
>  0.00  0.00  1.00
>
>
>
> K_POINTS {gamma} {automatic}
>
> 1 1 1  0 0 0
>
>
>
>
>
> The program is run with
>
>
>
> mpirun -np 32 /path_xxx/pw.x
>
>
>
> Final coordinates: The first two rows for ecutwfc=30 for two runs with
identical input are:
>
> ATOMIC_POSITIONS (angstrom)
> C  8.898432121  8.898432121  8.898432121
> C  9.783306562  9.783306562  8.019670107
>
> ATOMIC_POSITIONS (angstrom)
> C  8.898432121  8.898432121  8.898432121
> C  9.783306562  9.783306562  8.019670109
>
>
> Final coordinates: The first two rows for ecutwfc=60 for two runs with
identical input are:
>
> ATOMIC_POSITIONS (angstrom)
> C  8.904988579  8.904988579  8.904988579
> C  9.783426086  9.783426086  8.031809869
>
> ATOMIC_POSITIONS (angstrom)
> C  8.904962246  8.904962246  8.904962246
> C  9.783425401  9.783425401  8.031847251
>
> --
> --
>
> Dr. Pablo García Risueño
>
> Institut für Physikalische Chemie, Universität Hamburg, Grindelallee 117,
20146 Hamburg
>
> Tel. +49 040 42 83 84 82 7
>
> ___
> 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] Problem: different output with identical input

2016-12-28 Thread Ilya Ryabinkin 
Iterative solution of KS equations (with a given threshold) limits the
number of significant figures in both energy and properties values.
The total energy is less sensitive than property values are. What
happens is the following: you *gradients* have limited accuracy --
beyond threshold the digits are largely random. These errors propagate
and accumulate throughout geometry optimization.

--
Ilya

On Wed, Dec 28, 2016 at 7:45 AM, Pablo García Risueño
 wrote:
> Dear Espresso community
>
> I have one problem that is important for me; it is somewhat surprising. I
> run geometry optimization (relax) calculations with pw.x with identical
> input files, and I obtain rather different final coordinates. The problem
> does not happen if ecutwfc is 30, but it does appear for cutoffs of 60, 80
> or 90. Below one can see the exact input file, and examples of the
> difference between the final coordinates for both runs (both run with
> identical input) for given cutoffs.
>
> Could anybody give me a clue on the origin of the problem, and how to solve
> it?
>
> Thank you very much. Best regards.
>
>
>
> Input file:
>
>
>
> 
>
> calculation = 'relax',
>
> restart_mode = 'from_scratch',
>
> prefix='',
>
> outdir = './',
>
> pseudo_dir = '/path_xxx/PP/',
>
> forc_conv_thr = 1.0D-6 ,
>
> etot_conv_thr = 1.0D-8 ,
>
>  /
>
> 
>
> ibrav = 0, a=18.0,
>
> nat= 26, ntyp= 2,
>
> ecutwfc = 30d0,
>
> nbnd = 100,
>
> /
>
> 
>
> conv_thr = 1.0e-9,
>
> mixing_beta = 0.7,
>
> mixing_mode = 'plain',
>
> diagonalization = 'cg'
>
> /
>
> 
>
> /
>
>
>
> ATOMIC_SPECIES
>
> C   12.0107   C.pz-vbc.UPF
>
> H   1.007825035  H.pz-vbc.UPF
>
>
>
> ATOMIC_POSITIONS { angstrom }
>
> C  8.891700e+00 8.891700e+00 8.891700e+00
>
> C  9.783400e+00 9.783400e+00 8.00e+00
>
> C  9.783400e+00 8.00e+00 9.783400e+00
>
> C  8.00e+00 9.783400e+00 9.783400e+00
>
> C  8.891700e+00 1.067510e+01 1.067510e+01
>
> C  1.067510e+01 1.067510e+01 8.891700e+00
>
> C  1.067510e+01 8.891700e+00 1.067510e+01
>
> C  9.783400e+00 1.156680e+01 9.783400e+00
>
> C  9.783400e+00 9.783400e+00 1.156680e+01
>
> C  1.156680e+01 9.783400e+00 9.783400e+00
>
> H  8.391700e+00 8.391700e+00 8.391700e+00
>
> H  7.50e+00 1.028340e+01 9.283400e+00
>
> H  7.50e+00 9.283400e+00 1.028340e+01
>
> H  9.283400e+00 1.028340e+01 7.50e+00
>
> H  1.028340e+01 9.283400e+00 7.50e+00
>
> H  9.283400e+00 7.50e+00 1.028340e+01
>
> H  1.028340e+01 7.50e+00 9.283400e+00
>
> H  9.283400e+00 1.206680e+01 9.283400e+00
>
> H  1.206680e+01 9.283400e+00 9.283400e+00
>
> H  9.283400e+00 9.283400e+00 1.206680e+01
>
> H  8.391700e+00 1.117510e+01 1.117510e+01
>
> H  1.117510e+01 1.117510e+01 8.391700e+00
>
> H  1.117510e+01 8.391700e+00 1.117510e+01
>
> H  1.028340e+01 1.206680e+01 1.028340e+01
>
> H  1.028340e+01 1.028340e+01 1.206680e+01
>
> H  1.206680e+01 1.028340e+01 1.028340e+01
>
>
>
>
>
> CELL_PARAMETERS {cubic}
>
>  1.00  0.00  0.00
>
>  0.00  1.00  0.00
>
>  0.00  0.00  1.00
>
>
>
> K_POINTS {gamma} {automatic}
>
> 1 1 1  0 0 0
>
>
>
>
>
> The program is run with
>
>
>
> mpirun -np 32 /path_xxx/pw.x
>
>
>
> Final coordinates: The first two rows for ecutwfc=30 for two runs with
> identical input are:
>
> ATOMIC_POSITIONS (angstrom)
> C  8.898432121  8.898432121  8.898432121
> C  9.783306562  9.783306562  8.019670107
>
> ATOMIC_POSITIONS (angstrom)
> C  8.898432121  8.898432121  8.898432121
> C  9.783306562  9.783306562  8.019670109
>
>
> Final coordinates: The first two rows for ecutwfc=60 for two runs with
> identical input are:
>
> ATOMIC_POSITIONS (angstrom)
> C  8.904988579  8.904988579  8.904988579
> C  9.783426086  9.783426086  8.031809869
>
> ATOMIC_POSITIONS (angstrom)
> C  8.904962246  8.904962246  8.904962246
> C  9.783425401  9.783425401  8.031847251
>
> --
> --
>
> Dr. Pablo García Risueño
>
> Institut für Physikalische Chemie, Universität Hamburg, Grindelallee 117,
> 20146 Hamburg
>
> Tel. +49 040 42 83 84 82 7
>
> ___
> Pw_forum mailing list
> Pw_forum@pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum



-- 
***
Ilya Ryabinkin
 Postdoctoral Scholar
  Physical and Environmental Sciences
   University of Toronto Scarborough
  http://www.utsc.utoronto.ca/~aizmaylov/Members.html
***

___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum

[Pw_forum] Problem: different output with identical input

2016-12-28 Thread Pablo García Risueño 
Dear Espresso community

I have one problem that is important for me; it is somewhat surprising. I
run geometry optimization (relax) calculations with pw.x with identical
input files, and I obtain rather different final coordinates. The problem
does not happen if ecutwfc is 30, but it does appear for cutoffs of 60, 80
or 90. Below one can see the exact input file, and examples of the
difference between the final coordinates for both runs (both run with
identical input) for given cutoffs.

Could anybody give me a clue on the origin of the problem, and how to solve
it?

Thank you very much. Best regards.



Input file:





calculation = 'relax',

restart_mode = 'from_scratch',

prefix='',

outdir = './',

pseudo_dir = '/path_xxx/PP/',

forc_conv_thr = 1.0D-6 ,

etot_conv_thr = 1.0D-8 ,

 /



ibrav = 0, a=18.0,

nat= 26, ntyp= 2,

ecutwfc = 30d0,

nbnd = 100,

/



conv_thr = 1.0e-9,

mixing_beta = 0.7,

mixing_mode = 'plain',

diagonalization = 'cg'

/



/



ATOMIC_SPECIES

C   12.0107   C.pz-vbc.UPF

H   1.007825035  H.pz-vbc.UPF



ATOMIC_POSITIONS { angstrom }

C  8.891700e+00 8.891700e+00 8.891700e+00

C  9.783400e+00 9.783400e+00 8.00e+00

C  9.783400e+00 8.00e+00 9.783400e+00

C  8.00e+00 9.783400e+00 9.783400e+00

C  8.891700e+00 1.067510e+01 1.067510e+01

C  1.067510e+01 1.067510e+01 8.891700e+00

C  1.067510e+01 8.891700e+00 1.067510e+01

C  9.783400e+00 1.156680e+01 9.783400e+00

C  9.783400e+00 9.783400e+00 1.156680e+01

C  1.156680e+01 9.783400e+00 9.783400e+00

H  8.391700e+00 8.391700e+00 8.391700e+00

H  7.50e+00 1.028340e+01 9.283400e+00

H  7.50e+00 9.283400e+00 1.028340e+01

H  9.283400e+00 1.028340e+01 7.50e+00

H  1.028340e+01 9.283400e+00 7.50e+00

H  9.283400e+00 7.50e+00 1.028340e+01

H  1.028340e+01 7.50e+00 9.283400e+00

H  9.283400e+00 1.206680e+01 9.283400e+00

H  1.206680e+01 9.283400e+00 9.283400e+00

H  9.283400e+00 9.283400e+00 1.206680e+01

H  8.391700e+00 1.117510e+01 1.117510e+01

H  1.117510e+01 1.117510e+01 8.391700e+00

H  1.117510e+01 8.391700e+00 1.117510e+01

H  1.028340e+01 1.206680e+01 1.028340e+01

H  1.028340e+01 1.028340e+01 1.206680e+01

H  1.206680e+01 1.028340e+01 1.028340e+01





CELL_PARAMETERS {cubic}

 1.00  0.00  0.00

 0.00  1.00  0.00

 0.00  0.00  1.00



K_POINTS {gamma} {automatic}

1 1 1  0 0 0





The program is run with



mpirun -np 32 /path_xxx/pw.x


Final coordinates: The first two rows for ecutwfc=30 for two runs with
identical input are:

ATOMIC_POSITIONS (angstrom)
C  8.898432121  8.898432121  8.898432121
C  9.783306562  9.783306562  8.01967010*7*

ATOMIC_POSITIONS (angstrom)
C  8.898432121  8.898432121  8.898432121
C  9.783306562  9.783306562  8.01967010*9*


Final coordinates: The first two rows for ecutwfc=60 for two runs with
identical input are:

ATOMIC_POSITIONS (angstrom)
C  8.904988579  8.904988579  8.904988579
C  9.783426086  9.783426086  8.031809869

ATOMIC_POSITIONS (angstrom)
C  8.904962246  8.904962246  8.904962246
C  9.783425401  9.783425401  8.031847251

-- 
--

Dr. Pablo García Risueño

Institut für Physikalische Chemie, Universität Hamburg, Grindelallee 117,
20146 Hamburg

Tel. +49 040 42 83 84 82 7
___
Pw_forum mailing list
Pw_forum@pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum