[Pw_forum] cp.x and lemieux TRU64 Alpha

[Konstantin Kudin]

 It seems that since two 64-bit versions (Alpha and x86-64) blow up
almost identically under otherwise vastly different environments, there
is a good indication that the bug is due to the code itself.

 The size of Real*8 arrays is not affected by 32/64 bits. Then there
could be some integer misallocation if somewhere the 4-byte integer is
hardcoded for 32 bits but becomes 8 bytes under 64-bits and overwrites
something else.

 If some variables/arrays are accessed before being initialized, one
could set all Real*8 to 'NaN' via compiler flags, and see if the code
fails. SGI compilers were especially user friendly with respect to
crashes, and could easily tell where the crash happened by using "dbx
corefile; where". SGI is also a 64-bit machine, and should fail
similarly to Alpha if the code itself contains a bug.

 Kostya


--- Yonas Abraham <yonasb at yahoo.com> wrote:

> Hi,
> 
> I did a comparison b/n the two 64 bits. Actually, when
> we look in detail to the diff in log file, even the
> PGI 64 bit version blows out, but strangling, it
> adjusted it self with a different guess, I guess. here
> is the log for the PGI 64 bit.
> 
>   diff=     2.498089579263851       iter=            
> 1
>   diff=     6.083014579370730       iter=            
> 2
>   diff=     20.35737489304835       iter=            
> 3
>   diff=     129.7643878903619       iter=            
> 4
>   diff=     3621.400080136234       iter=            
> 5
>   diff=     4616116.523432171       iter=            
> 6
>   diff=     12739856780499.26       iter=            
> 7
>   diff=    1.2524752110924165E+026  iter=            
> 8
>   diff=    1.2478638673171860E+052  iter=            
> 9
>   diff=    1.2250435300965247E+104  iter=           
> 10
>   diff=    1.1771833447890517E+208  iter=           
> 11
>   diff=                        inf  iter=           
> 12
>   diff=     1.752692656206230       iter=           
> 13
>   diff=    0.2853517316994355       iter=           
> 14
>   diff=    0.1048934415556536       iter=           
> 15
>   diff=    4.4504330932978231E-002  iter=           
> 16
> 
> 
> in the case of alpha TRU64 version, after Iter=11, it
> crushed and stop but the case of PGI it resets itself
> once it reached  inf.
> 
> how is this happen? is there any switch that controls
> this?
>  
> 
> 
> --- Paolo Giannozzi <giannozz at nest.sns.it> wrote:
> 
> > On Tuesday 26 October 2004 17:40, Yonas Abraham
> > wrote:
> > 
> > > we took the same input parameter identical source
> > code
> > > and run it in PGI compiler both 32 and 64 bit
> > versions and
> > > intel on 32 bit machines and worked just fine
> > [...]
> > > here is the snapshot of the ortho diff.
> > >
> > >  diff=    2.58117779926850       iter=           
> > 1
> > >  diff=    6.73012657805981       iter=           
> > 2
> > 
> > 1) check for un-initialized variables, with the
> > appropriate compiler 
> > flag, if any
> > 2) restart from the same file on two different
> > machines (both 64-bit: 
> > it is possible in principle, in practise I don't
> > know), compare what 
> > ortho does in the two cases
> > 3) if you cannot restart from the same file, try
> > anyway to track
> > what ortho does in two calculations as similar as
> > possible on 
> > different machines
> > 
> > Paolo
> > -- 
> > Paolo Giannozzi             e-mail: 
> > giannozz at nest.sns.it
> > Scuola Normale Superiore    Phone:   +39/050-509876,
> > Fax:-563513 
> > Piazza dei Cavalieri 7      I-56126 Pisa, Italy
> > _______________________________________________
> >
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> Read only the mail you want - Yahoo! Mail SpamGuard.
> http://promotions.yahoo.com/new_mail 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com