[Wien] Re: Bug in lapwso?

[Krzysztof Osuch]

Dear Prof. Blaha,

I am using a cluster of Pentium IV processors and Red Hat Linux 9.0.
The whole problem was caused by the ifc 8.0, which I decided to use to
to the reported inconsistencies of ifc 7.1 and the new c libraries. What
misled me completely, was the fact that I could compile all the
subprograms and linked them with the mkl 7.0 libraries without any
problem (no error messages). I could then run the programs for small
systems (1,2) atoms u=in the unit cell. With a larger system 1ML
Au/Nb(100) though, lapw1 was terminated with the message "segmentation
violation" and a core dumped. The investigation of the core file with
idb showed that the size of some matrices which depend on kmax1start
etc. was exceeded. After I had increased these parameters, I could run
lapw1(c) without any problem again. This made me suspect that kmax123
were not dynamically determined. And a similar situation occurred again
with lapwso. After receiving your message I recompiled the code using
ifc 7.1 and mkl70 libraries and now all the problems disappeared. I
simply did not expect that the use of a newer version of ifc (now
compatible with the new linux c libraries) could cause this type of
problems.

I would like to apologize to the Wien team for my previous message.



Best regards

K. Osuch


On Fri, 2004-03-12 at 15:27, Krzysztof Osuch wrote:
> > 
> > Dear Wien team,
> > 
> > I recently (after the last update reported on the wien website, i.e.
> > after the 9th February) updated my version downloading all the
> > executables and tested it for small systems e.g. fcc Au (including s-o).
> > Everything worked perfect. Then I moved to larger systems: 1AuML/Nb(100)
> > with 10 atoms in the unit cell. Suprisingly lapw1 was stopped producing
> > a core. After spending half a day, using the idb I traced the problem
> > down to the fact that  the new parameters:
> > PARAMETER          (KMAX1START=   50)
> > PARAMETER          (KMAX2START=   50)
> > PARAMETER          (KMAX3START=   75)
> >  
> > were given too small values in the param.inc_r file.
> > Now, after optimising the geometry of the system I wanted to include the
> > s-o coupling. (which worked very well with older versions of the code,
> > from half a year ago - I did extensive calculations on this system at
> > that time - and I am still using the same input .in* files (after, of
> > course running 100atomfix on them). Again lapwso is dumped producing a
> > core. The examination of the core give the followin results:
> > 
> > object file name: ../lapwso
> > core file name: core.5842
> > Reading symbolic information ...done
> > Unexpected note type in core:1189489535
> > Core file produced from executable lapwso
> > Initial part of arglist: /home/osuchk/wien2k/lapwso lapwso.def
> > Thread terminated at PC 0x8069220 by signal SEGV
> > 
> > (idb) where
> > >0  0x8069220 in hmsec(fl=.TRUE. (4294967295), emm=(...), ne=(...),
> > nv=(...), ee=(...), meigve=(...), ri_mat=(...), ri_orb=(...), kkk=1,
> > jspin=1, ipr=1) "hmsec.f":87
> > #1  0x8079740 in lapwso() "lapwso.f":191
> > #2  0x80ba6e4 in main(...) in ../lapwso
> > #3  0x42015704 in __libc_start_main(...) in /lib/tls/libc.so.6
> > #4  0x804b361 in _start(...) "../sysdeps/i386/elf/start.S":81
> > 
> > 
> > >0  0x8069220 in hmsec(fl=.TRUE. (4294967295), emm=(...), ne=(...),
> > nv=(...), ee=(...), meigve=(...), ri_mat=(...), ri_orb=(...), kkk=1,
> > jspin=1, ipr=1) "hmsec.f":87
> > abcdlm=(...)
> > abstol=2
> > cc=56.107799999999997
> > couplo=(...)
> > czero=(0, 0)
> > dd=(9, -18)
> > dtime1=1
> > dtime2=-1
> > dtime3=-2
> > dwork=(...)
> > ee=(...)
> > emm=(...)
> > en=(...)
> > fl=.TRUE. (4294967295)
> > h_=(...)
> > hexl=(...)
> > hso=(...)
> > hsoc=(-9, 9)
> > i=-1070596096
> > ibf=1074790400
> > ibi=-1072693248
> > 
> > At this stage, suprisingly the value of nban2 is
> > 
> > (idb) print nban2
> > -1072693248
> > (idb)
> > 
> > I do not know where all these problems come from. Is anybody able to
> > help?
> > 
> > I want to stress once again that lapwso runs perfectly well for small
> > systems like bcc Rh or fcc Au. Is there again some new parameter, which
> > hides somwhere in the code, and whose value is set too small?
> > 
> > Just an appeal to wien developers - to save some time of the users -
> > please take some more care in testing the updates, before releasing them
> > and let us inform about what needs to be changed to avoid problems with
> > larger systems (it is a fortran 90 code !!!!!)
> > 
> > With best regards
> > 
> > K. Osuch  
> > 
> >