[Wien] WIEN2k_07_executables and AMD Opteron are inconsistent
jadhikari@clarku.edu
jadhikari at clarku.edu
Tue May 1 17:00:41 CEST 2007
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
>
More information about the Wien
mailing list