Nearly all grid related data is in single precision (unless you explicitly compiled it with double precision).
As I stated your convergence path is not the same (which could arise due to this "error") and thus you should not expect the same results. As I said, you target a tolerance not a definite answer. Decrease tolerance if you are not satisfied and test if they dont converge towards the same minimum. Your error is on the 8 digit. That is very satisfactory and not a big energy difference compared to the total Kohn-Sham energy. Nick 2012/3/25 Guangping Zhang <[email protected]> > Dear all, > > Thanks for all your replies. > > I think the difference of 0.0001eV is very big. I wonder is this relevant > to the presion setting in the precision.F file? For single precision use a > selected_real_kind(6,30) kind and for double precision use a > selected_real_kind(14,100) kind. I now do not know the energies are all > relevant to the double precision kind data. If they are use some single > precision kind data, the difference seems to be understandable because what > Ray has said. But if the energies are all relevant to the double precision > kind data, if there is a difference on the fourth decimal, it need > hundreds of thousand accumulation to achive such a differece. > > Best regards > > Guangping > > 2012-03-25 > ------------------------------ > Guangping Zhang > ------------------------------ > *发件人：*Ray Sheppard > *发送时间：*2012-03-25 09:53 > *主题：*Re: [SIESTA-L] results denpend on the number of core using > *收件人：*"siesta-l"<[email protected]> > *抄送：* > > Lets try again. > > On 3/24/2012 9:43 PM, Ray Sheppard wrote: > > Hi Guangping, Nick and everyone, > I was waiting for someone to write in but I thought I might toss in my > two cents. First, in the > data you sent, you had about 7 or 8 digits of precision in your > calculations. The number system > in a computer is a closed set. At some point you go from a very large > number to a very small > number by adding a positive value. So, computers use approximations by > definition. IEEE 754-2008 > defines required precision standards. We will skip over the whole, you > can not achieve greater > precision than your least precise input part and the Numerical Analysis, > how these these precisions > propagate through a calculation part. A single precision (32-bit floating > point number) has about 7 and > a quarter digits of precision according to the standard. Beyond that, you > will need to understand how > error terms propagate as they are combined. A particular processor might > have a term E1f. 12*E1f > is not the same as the sum of the series X=1->12 EXf where each X is on a > unique processor. For numbers > of X less than about a thousand, this is usually negligible. In other > words, the sum of the differences in > the error functions falls at least one digit below the guaranteed > precision. So, in short, the fact that your > computer will happily print out a bunch of lower significant digits, that > does not mean they have any meaning. > I hope this is helpful. > Ray > > > On 3/24/2012 6:15 PM, Nick Papior Andersen wrote: > > As well as reductions in parallel should never be expected to yield the > exact same result every time. There are numerical rounding differences when > not enforcing the same reduction scheme every time, which is the case when > using MPI-library reductions. I will not argue whether it can or can not > contribute to an error of that order, but the fact that your convergence > path is not similar I would not expect the exact same result, after all you > are targeting a tolerance, not an "exact" solution. > > But also as Huan notes, is it the same executable? > > Nick > > 2012/3/24 Huan Tran <[email protected]> > >> I think 0.001 eV is a small quantity, and it may come from different >> library when you run 1 core (serial) and 12 core (parallel). >> >> >> >> >> On Sat, Mar 24, 2012 at 5:50 AM, Guangping Zhang <[email protected]> wrote: >> >>> Dear siesta users: >>> >>> I have now encounter a question: the results differ when using different >>> number of core to parallel. >>> >>> 1 core: >>> siesta: 124 -33928.6003 -33928.6031 -33928.6366 0.0002 -4.1261 >>> siesta: 125 -33928.6004 -33928.6012 -33928.6346 0.0001 -4.1251 >>> siesta: 126 -33928.6003 -33928.6009 -33928.6344 0.0001 -4.1258 >>> >>> siesta: E_KS(eV) = -33928.6012 >>> >>> siesta: E_KS - E_eggbox = -33928.6012 >>> >>> 12 core: >>> >>> siesta: 123 -33928.6004 -33928.6064 -33928.6398 0.0003 -4.1246 >>> siesta: 124 -33928.6003 -33928.6026 -33928.6360 0.0001 -4.1257 >>> siesta: 125 -33928.6003 -33928.6018 -33928.6352 0.0001 -4.1256 >>> siesta: 126 -33928.6004 -33928.5996 -33928.6331 0.0001 -4.1253 >>> >>> siesta: E_KS(eV) = -33928.6001 >>> >>> siesta: E_KS - E_eggbox = -33928.6001 >>> >>> The E_KS differs 0.001 eV. I think it is significant. I think the >>> number of core using to paralle only affect the speed. The results should >>> be the same. Or there is something I am missing? >>> >>> And I have another question: when I do the geometry optimization, which >>> energy is used to calculated the force? And when I do molecular dynamics, >>> which energy is used for the force? >>> >>> I think the KS energy of a single point DFT calculation and the KS >>> energy of a molecular dynamics should be the same for the same structure. >>> Am I right? >>> >>> Any suggestions will be regarded. >>> >>> Best >>> >>> Guangping >>> >>> 2012-03-24 >>> ------------------------------ >>> Guangping Zhang >>> >> >> >> >> -- >> Regards >> Huan Tran >> Department of Physics >> University of Basel, Switzerland >> Email: [email protected] >> > > > >
