[Wien] WIEN2k_07_executables and AMD Opteron are inconsistent

Laurence Marks L-marks at northwestern.edu
Tue May 1 19:28:17 CEST 2007


You can run the equivalent of the -in1new flag manually by executing
"write_in1 -ql" at the terminal  for a unpolarized case, add "-up" for
a polarized case. I suspect that this will fail and give you an error
message, probably related to differences in unix commands (there is no
real standard for many of the basic unix commands).

N.B., I don't think write_in1 is trapped for errors; perhaps it should
be in run_lapw.

On 5/1/07, jadhikari at clarku.edu <jadhikari at clarku.edu> wrote:
> Dear all,
>
> I am having exactly the same problem with Operton and new version.
>
> Subin
>
> > Dear WIEN2k group,
> >   We reported a problem concerning the last line of the in1 file last
> > Sunday. Since we have not received any response, we suspect that our
> > given information was not enough. Therefore here we would give more
> > information. Hope this time we receive some comments from you. We are
> > running the latest version of the code using the
> > WIEN2k_07_executables.tar file. The last line of the case.in1 file,
> > K-VECTORS FROM UNIT:4   -9.0       2.0      emin/emax window, is
> > truncated after some iterations in the case of including in1new flag. In
> > order to make sure, we have run several cases. For each case two kinds
> > of calculations are performed. One kind is performed taking into account
> > the in1new flag. For the second kind the in1new is switched off.  The
> > calculations for all the cases including in1new flag are stopped with
> > similar error due to the incomplete in1 file. However, all the cases
> > without in1new flag are performed completely. We repeat these
> > calculations in single and parallel
> >  modes, and found that the error is independent of the mode of
> > calculations, namely on the single mode the same problem is occurred. We
> > performed similar calculations, i.e., similar executable version of the
> > code and similar cases, on a P IV and found that there is no any problem
> > concerning the in1new flag there. We repeated these calculations on a
> > Xeon machine in both modes of single and parallel using shared memory
> > considered in siteconfig_lapw. Here for the case of Xeon similar to P IV
> > everything is also okay independent of the modes of calculations as well
> > as our in1new flag.
> >   However, we would run on the cluster performing more precise
> > calculations by keeping the in1new flag. But we cannot do this, because
> > it is impossible, at the present time, for us to compile the program on
> > the cluster. Then we will be indebted, if you reproduce the
> > WIEN2k_07_executables.tar file so that we can linearize the energies
> > switching on the in1new on our cluster, AMD Opteron(tm) Processor.
> > Obviously, this is not an optimum using of the cluster, but we can
> > survive with it at least for some time.
> >
> >   In summery, this is a report which shows that the executable wien2k
> > cannot continuously perform linearization on AMD Opteron Processor.
> >   Just for your information the cpu information of the above mentioned
> > three systems are appended:
> >   ------------ AMD Opteron(tm) Processor---------------------
> >   processor       : 0
> >   vendor_id       : AuthenticAMD
> >   cpu family      : 15
> >   model           : 5
> >   model name      : AMD Opteron(tm) Processor 250
> >   stepping        : 10
> >   cpu MHz         : 2405.522
> >   cache size      : 1024 KB
> >   fpu             : yes
> >   fpu_exception   : yes
> >   cpuid level     : 1
> >   wp              : yes
> >   flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm
> > 3dnowext 3dnow
> >   bogomips        : 4815.10
> >   TLB size        : 1024 4K pages
> >   clflush size    : 64
> >   cache_alignment : 64
> >   address sizes   : 40 bits physical, 48 bits virtual
> >   power management: ts fid vid ttp
> >    processor       : 1
> >   vendor_id       : AuthenticAMD
> >   cpu family      : 15
> >   model           : 5
> >   model name      : AMD Opteron(tm) Processor 250
> >   stepping        : 10
> >   cpu MHz         : 2405.522
> >   cache size      : 1024 KB
> >   fpu             : yes
> >   fpu_exception   : yes
> >   cpuid level     : 1
> >   wp              : yes
> >   flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm
> > 3dnowext 3dnow
> >   bogomips        : 4811.05
> >   TLB size        : 1024 4K pages
> >   clflush size    : 64
> >   cache_alignment : 64
> >   address sizes   : 40 bits physical, 48 bits virtual
> >   power management: ts fid vid ttp
> >   --------------------------------------
> > Xeon------------------------------------
> >   processor       : 0
> >   vendor_id       : GenuineIntel
> >   cpu family      : 15
> >   model           : 4
> >   model name      :                   Intel(R) Xeon(TM) CPU 3.20GHz
> >   stepping        : 1
> >   cpu MHz         : 3200.216
> >   cache size      : 1024 KB
> >   fpu             : yes
> >   fpu_exception   : yes
> >   cpuid level     : 5
> >   wp              : yes
> >   flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
> > lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
> >   bogomips        : 6404.94
> >   clflush size    : 64
> >   cache_alignment : 128
> >   address sizes   : 36 bits physical, 48 bits virtual
> >   power management:
> >   processor       : 1
> >   vendor_id       : GenuineIntel
> >   cpu family      : 15
> >   model           : 4
> >   model name      :                   Intel(R) Xeon(TM) CPU 3.20GHz
> >   stepping        : 1
> >   cpu MHz         : 3200.216
> >   cache size      : 1024 KB
> >   fpu             : yes
> >   fpu_exception   : yes
> >   cpuid level     : 5
> >   wp              : yes
> >   flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
> > lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
> >   bogomips        : 6400.66
> >   clflush size    : 64
> >   cache_alignment : 128
> >   address sizes   : 36 bits physical, 48 bits virtual
> >   power management:
> >    ----------------------- Intel(R) Pentium(R)
> > 4---------------------------------------
> >   processor       : 0
> >   vendor_id       : GenuineIntel
> >   model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz
> >   stepping        : 3
> >   cpu MHz         : 2813.578
> >   cache size      : 1024 KB
> >   fpu             : yes
> >   fpu_exception   : yes
> >   flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
> >   bogomips        : 5609.88
> >
> >   processor       : 1
> >   vendor_id       : GenuineIntel
> >   cpu family      : 15
> >   model           : 3
> >   model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz
> >   stepping        : 3
> >   cpu MHz         : 2813.578
> >   cache size      : 1024 KB
> >   Morteza  Rafiee
> >
> >
> > ---------------------------------
> > Ahhh...imagining that irresistible "new car" smell?
> >  Check outnew cars at Yahoo!
> > Autos._______________________________________________
> > Wien mailing list
> > Wien at zeus.theochem.tuwien.ac.at
> > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> >
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>


-- 
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2220 N Campus Drive
Northwestern University
Evanston, IL 60208, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
email: L-marks at northwestern dot edu
Web: www.numis.northwestern.edu
EMM2007 http://ns.crys.ras.ru/EMMM07/
Commission on Electron Diffraction of IUCR
www.numis.northwestern.edu/IUCR_CED


More information about the Wien mailing list