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

[Laurence Marks]

The renormalization will only matter if the inverse of betamix is
regularized. I am not that familiar with how the Johnson algorithm behaves
for bad problems to know if regularization helps in practice, or does matter
for a multisecant method.
On Apr 12, 2011 1:41 AM, "Stefano de Gironcoli" <degironc at sissa.it> wrote:
> It has been there for some time, didn't seem to have any relevant effect.
> do you have evidence of the contrary?
> stefano
>
> On 04/11/2011 05:25 PM, Laurence Marks 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
>>>
>>
>>
>
> _______________________________________________
> 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://lists.quantum-espresso.org/pipermail/users/attachments/20110412/675c8524/attachment.html>