[Pw_forum] questions on molecular dynamics example

[Eduardo Ariel Menendez P]

Wow!! You are not taking hollidays yet! Thanks for your cooperation.
I have rather low memory, then maybe disk_io is good for me.
Regarding the wfc extrapolation, I just realize that I am doing velocity
rescaling at every ionic step, hence a 'second order ' extrapolation would
be fooled. However, I don not understand why in the example 4 I do not see
differences between the use of extrrapolation or commenting it.

> From: "Axel Kohlmeyer" <akohlmey at cmm.chem.upenn.edu>
> To: pw_forum at pwscf.org
> Subject: Re: [Pw_forum] questions on molecular dynamics example
> Reply-To: pw_forum at pwscf.org
>
> On 12/25/06, Eduardo Ariel Menendez P
> <emenendez at macul.ciencias.uchile.cl> wrote:
> > Hi Paolo,
> > I saw these options in the examples of molecular dynamics woth PW. There
> > is few information in the Doc files and the forum.
> >
> >     pot_extrapolation=3D'second-order',
> >     wfc_extrapolation=3D'second-order',
> >
> > I guessed that extrapolation options would reduce the number of
> > self-consistent steps in MD steps. However, in the case I am running
> > (CdTe) he number of self consistent steps at each ionic steps averages
> > 16, regardless of the extrapolation keywords.
> >
> > Other keyword that I see in the examples is
> >     disk_io=3D'high',etc,
> > Is this keyword useful to improve the efficiency of molecular dynamics?
>
> that depends on the individual example and hardware.
> with a higher disk_io level, more data is written to disk
> and re-read instead of being kept in memory. if you have
> a lot of memory, a lower disk_io level should be better.
> in fact, for some machines with no local disk storage,
> it would be nice of have a disk_io level of 'no', i.e. keep
> everything in memory...
>
> >
> > Other issue. I had this error in step 90
> >      iteration #  4     ecut=3D    30.00 Ry     beta=3D0.70
> >      Davidson diagonalization with overlap
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=
> %%%%%
> >      from rdiaghg : error #      1986
> >      info =3D/=3D 0
>
>
> did you try changing the diagonalizer?
>
> > Consulting the manual and the forum I see that it is difficult to find
> > the cause, and that the first choice is restart
> > and see what happens. I did it and the calculation just continued without
> > error. ?Does it allows to discard the possible cause of bad
> > pseudopotential, and bug of the lapack algorithm, in favor of buggy mahin=
> e
> > optimization of lapack (MKL) ?
>
> i don't think that you have a buggy MKL. it might just be, that it get fed =
> an
> input that it cannot converge. the fact that you do not see any improvement=
> s
> from wavefunction extrapolations could indicate that the order of your stat=
> es
> keeps changing a lot and perhaps the davidson implementation is more
> sensitive there.
> (note: i'm not an expert here, but currently trying to learn about the deta=
> ils
> of these issues myself).
>
> i noticed however, that with different lapack implementations, this kind of
> error message keeps popping up more or less often (e.g. more often with
> ATLAS than with ACML than with MKL). also the compiler seems to have
> some impact, so it might be that very small differences in accuracy may
> have a large impact here (which would make it difficult to rule out all oth=
> er
> possible sources of problems like suboptimal pseudopotentials, as they
> tend to enhance existing accuracy problems...).
>
> ciao,
>    axel.
>
> >
> > Thanks
> > Eduardo
> >
> > Eduardo A. Menendez Proupin
> > Department of Physics
> > Faculty of Science