comment on accuracy parameter in BAND input file

Search:

comment on accuracy parameter in BAND input file

From: MANUEL PEREZ JIGATO <mpj_at_email.domain.hidden>
Date: Fri, 6 Jun 2003 19:43:21 +0300 (EEST)

sorry i forgot to write down in the second paragraph
(see my email below)
that when you have primitive cells in periodic systems
(not forces to check upon for accuracy), probably the
best test to follow in terms of accuracy, is the
stress (for a surface take only the strain derivative
however you could also check the surface energy)
for a single point ground state calculation.

however, these are tough convergence criteria, which
probably would slow down quite a bit the publication
rate in the field, especially on surfaces.

Manolo

On Fri, 6 Jun 2003, MANUEL PEREZ JIGATO wrote:

>
> hi Roar
>
> thanks for your kind and detailed advice and description of
> possible numerical accuracy checkups
>
> i'd like to ask in relation to your making reference to
> accuracy in general (and numerical integration in particular)
> as measured by total energy variations less than ca. 0.01 eV,
> of course that makes sense for a single point calculation,
> but probably when heavy geometry optimisation is carried out,
> it is probably a more appropriate test to follow up the forces
> on the atoms for a finite sytem (molecule or cluster), and
> probably, for a ground state calculation on a periodic solid
> however really a strong criterium (this is a bit on the
> tough side of things -too extreme convergence-). When the solid
> has more than one atom, or some atoms not-fixed by the space
> group -so that you could get non-zero forces if you shifted them-
> then you could also follow up the force criterium for accuracy.
>
> However, and this concerns me much more at the moment,
> for a response-tcdft calculation, i guess the only way i
> can follow up ACCURACY (in any form or parameter) is by
> checking that Kai_e (the electric susceptibility) and
> the final result of epsilon at different frequencies, do not
> change too much. Probably in cases of sharp resonances or
> localised states the peak position would be important
> but for a bulk solid this is usually not the case
>
> Does it make sense?? or else how would you check on accuracy
> for the computation of response of a bulk solid?
>
> regards
>
> Manolo
>
>
>
>
> On Thu, 5 Jun 2003, Roar A. Olsen wrote:
>
> > Hi Manuel,
> >
> > > i would appreciate having information on the following :
> > >
> > > "*** WARNING: Norm of basis functions inaccurate "
> > >
> > > this happens when i run BAND, during a single-point ground state
> > > calculation
> > >
> > > Does it mean there is a serious problem in my calculation?
> >
> > Most likely there is not a serious problem with your calculation.
> > If BAND thinks that it is too bad it will actually stop.
> > In my experience you're probably quite safe. That this the
> > short answer.
> >
> > Below is a longer answer and a suggestion to do a larger set
> > of tests to make sure that you're ok. I recommend it, but it involves
> > burning some cpu-hours, a luxery you might not have...
> >
> > I've seen this warning message very often during the calculations
> > I've performed over the past years and in the begining I had the
> > same worries as you. After testing the accuracy of my calculations
> > by increasing the numerical integration accuracy (in real space,
> > see below) on a number of occasions, none of the jobs giving this
> > warning message seemed to have any convegence problems wrt to numerical
> > (real space) integration accuracy. So I more or less stopped worrying
> > about it. That is, as long as I work with a "known" system. Each
> > time I switch to a new system and this message pops up I take
> > care to test the convergence wrt (real space) integration accuracy
> > properly.
> >
> > If you are new to the code it might be a good idea to do a number
> > of convergency test wrt to the integration accuracy.
> > E.g. running the same input with "Accuracy" set to 3.0, 3.5, 4.0,
> > 4.5, 5.0, 5.5, and 6.0. Most likely you will find that 4.0-5.0
> > will give results that are converged in the 0.01 eV range.
> > The most accurate of these calculations might be rather expensive,
> > but I recomend it for building up some personal confidence in the
> > code.
> >
> > What you might want to be aware of is that changing "Accuracy" will
> > influence more than the real space integration accuracy alone -
> > a large number of computational parameters are influnced by
> > changing "Accuracy". But in most cases this is what you would
> > like to test anyway.
> >
> > But if, after having tested the convergence wrt to "Accuracy",
> > you still suspect that there might be something fishy with the
> > real space integration accuracy, you could test this more
> > specifically by keeping "Accuracy" fixed and change only
> > the parameter governing the real space integration accuracy,
> > "Accint". This can be done with the blocked key
> >
> > Integration
> > Accint <value>
> > End
> >
> > added to your input. So, go for it ;-)
> >
> > Best regards,
> > -Roar.
> >
> > /---------------------------------------------------\
> > | Roar A. Olsen |
> > | (r.a.olsen "at" chem "dot" leidenuniv "dot" nl) |
> > | Leiden Institute of Chemistry |
> > | Gorleaus Laboratory |
> > | Leiden University |
> > | P.O. Box 9502 |
> > | 2300 RA Leiden |
> > | The Netherlands |
> > | |
> > | ph. +31 71 527 5569 |
> > | fax. +31 71 527 4488 |
> > \---------------------------------------------------/
> >
> >
>
>

-- 
###########################################################################
 Manuel Perez Jigato
 Helsinki University of Technology
 Laboratory of Physics
 Room U203
 Otakaari 1M
 Otaniemi, Espoo
 P.O. Box 1100
 FIN-02015 HUT
 Finland
 Tel: +358-(0)9-451 3107
 Fax: +358-(0)9-451 3116
 E-mail: mpj_at_fyslab.hut.fi
###########################################################################
"Nobody tells me what to think, except Mrs. Pauling."
							Linus Pauling
###########################################################################
Received on 2003-06-06 18:43:07

This archive was generated by hypermail 2.2.0 : 2006-11-02 07:00:02 CET