[Pw_forum] One minor bug, one not minor and two questions

[Laurence Marks]

Correction, I did not notice that you are not renormalizing. With
#define __NORMALIZE_BETAMIX it should be more like

          if(iter_used .gt. 1)betamix(i,i)=betamix(i,i) + 2.0D-5

which, interestingly, is almost exactly the same regularization as
used elsewhere.

On Mon, Apr 11, 2011 at 10:25 AM, Laurence Marks
<L-marks at northwestern.edu> wrote:
> Thanks.
>
> Another question if I may. From the looks of PW/mix_rho.f90 you do not
> use the weights in the Johnson paper, just a straight inverse of
> betamix (what would be called Y^T Y in the optimization literature) at
> lines 289-295? Have you considered a regularization, e.g. adding after
> line 278 something like
>
>        betamix(i,i)=betamix(i,i) + 1.D-7/iter_used
>
> which is about right for your Al (001) example. The regularization
> term (e.g. PRB 78, 075114 (2008)) is a bit empirical, although I might
> be able to change this.
>
> This is safe, so long as mix_rho.f90 is only used for mixing densities
> during the scf iterations -- is it used elsewhere?
>
> On Mon, Apr 11, 2011 at 5:12 AM, Stefano de Gironcoli <degironc at sissa.it> wrote:
>> in my previous  post
>>
>> reminder -> remainder
>>
>> stefano
>>
>> On 04/11/2011 11:57 AM, Stefano de Gironcoli wrote:
>>> dear Laurence Marks
>>>
>>>      thank you for contributing this patch for bfgs !
>>>> A quick question. In the ion optimization it looks like you are
>>>> starting from some iterpolation of the new density (i.e. "NEW-OLD
>>>> atomic charge density approx. for the potential"), what is it?
>>> if i remember correctly the charge density of the new positions is
>>> written
>>> as the superposition of atomic charges plus a reminder which is computed
>>> as the scf rho minus the superposition of atomic charges at the old
>>> positions.
>>>
>>> rho_trial_new = rho_atomic_newR + (rho_scf_oldR - rho_atomic_oldR)
>>>
>>> this is done for the first ionic iteration and assumes that the main
>>> change in the density is due to rigid displacement of atomic-like
>>> contributions.
>>>
>>> At subsequent iterations the reminder (rho_scf_oldR-rho_atomic_oldR)
>>> can be extrapolated on the basis of its change in the previous couple
>>> of iterations
>>>
>>>  Stefano de Gironcoli
>>>
>>> On 04/11/2011 01:11 AM, Laurence Marks wrote:
>>>> For completeness, added proper comments.
>>>>
>>>> On Sun, Apr 10, 2011 at 4:13 PM, Laurence Marks
>>>> <L-marks at northwestern.edu>  wrote:
>>>>> A very minor bug that you probably known: some of the routines in
>>>>> S3DE/iotk/src have lines such as "# 1 "iotk_write_interf.spp" ". Most
>>>>> sensible preprocessors will ignore these and just give warnings.
>>>>>
>>>>> A more serious bug. Your bfgs code does not have curvature failure
>>>>> conditions trapped. Not to get too technical here (contact me offline
>>>>> if needed), unless one is close to the minimum bfgs fails unless this
>>>>> is done. The failure is well documented, less well known, as is the
>>>>> change needed (at least the standard form). I am attaching a modified
>>>>> version with the standard fix. It gives a slightly lower energy with
>>>>> smaller forces in about the same number of iterations -- due to
>>>>> numerical limitations I cannot compare exactly with your reference
>>>>> directory. I am a newbie with this code so there could be other
>>>>> repercussions of this change if it is used for something except
>>>>> optimizing the atomic positions, so perhaps a few tests are
>>>>> appropriate for harder problems.
>>>>>
>>>>> A quick question. In the ion optimization it looks like you are
>>>>> starting from some iterpolation of the new density (i.e. "NEW-OLD
>>>>> atomic charge density approx. for the potential"), what is it?
>>>>>
>>>>> Another quick one: line 1766 of install/configure.ac nulls out
>>>>> scalapack_libs and the lines below look like they are special tests,
>>>>> which seems to be inconsistent with line 150 and standard protocols of
>>>>> letting the user define input variables. (OK, while scalapack is
>>>>> probably only useful for large problems I might want to do some.)
>>>>>
>>>>> --
>>>>> Professor Laurence Marks
>>>>> Department of Materials Science and Engineering
>>>>> MSE Rm 2036 Cook Hall
>>>>> 2220 N Campus Drive
>>>>> Northwestern University
>>>>> Evanston, IL 60208, USA
>>>>> Tel: (847) 491-3996 Fax: (847) 491-7820
>>>>> email: L-marks at northwestern dot edu
>>>>> Web: www.numis.northwestern.edu
>>>>> Chair, Commission on Electron Crystallography of IUCR
>>>>> www.numis.northwestern.edu/
>>>>> Research is to see what everybody else has seen, and to think what
>>>>> nobody else has thought
>>>>> Albert Szent-Gyorgi
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pw_forum mailing list
>>>> Pw_forum at pwscf.org
>>>> http://www.democritos.it/mailman/listinfo/pw_forum
>>>
>>>
>>
>> _______________________________________________
>> Pw_forum mailing list
>> Pw_forum at pwscf.org
>> http://www.democritos.it/mailman/listinfo/pw_forum
>>
>
>
>
> --
> Laurence Marks
> Department of Materials Science and Engineering
> MSE Rm 2036 Cook Hall
> 2220 N Campus Drive
> Northwestern University
> Evanston, IL 60208, USA
> Tel: (847) 491-3996 Fax: (847) 491-7820
> email: L-marks at northwestern dot edu
> Web: www.numis.northwestern.edu
> Chair, Commission on Electron Crystallography of IUCR
> www.numis.northwestern.edu/
> Research is to see what everybody else has seen, and to think what
> nobody else has thought
> Albert Szent-Gyorgi
>



-- 
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2220 N Campus Drive
Northwestern University
Evanston, IL 60208, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
email: L-marks at northwestern dot edu
Web: www.numis.northwestern.edu
Chair, Commission on Electron Crystallography of IUCR
www.numis.northwestern.edu/
Research is to see what everybody else has seen, and to think what
nobody else has thought
Albert Szent-Gyorgi