From owner-chemistry@ccl.net Fri Nov 18 10:26:01 2016 From: "Eduardo edulsa=ufpr.br" To: CCL Subject: CCL:G: Strange g09 error message Message-Id: <-52496-161118102508-10649-EyHGY9FwDeXW0ihDqYv7hA]_[server.ccl.net> X-Original-From: Eduardo Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed Date: Fri, 18 Nov 2016 13:24:55 -0200 MIME-Version: 1.0 Sent to CCL by: Eduardo [edulsa~~ufpr.br] Dear dR. Buchwald and Mihyailovs > > Sent to CCL by: James Buchwald [buchwj * rpi.edu] > Igors and Prof. Lemos, > > I think your suspicion is correct here - the target machine is equipped > with amd64 CPUs, and I'll bet the Gaussian binary uses a SIMD > instruction set for later Intel models. According to the Gaussian > website (http://www.gaussian.com/g_prod/g09_plat.pdf), rev E01 has three > versions for x86-64 CPUs - an AVX-enabled version, an SSE4.2-enabled > version, and a "legacy" version for older x86-64 processors. > > Both AVX and SSE4.2 first appeared in AMD processors with the Bulldozer > microarchitecture, which first appeared on the market in late 2011. So > if the CPUs are older than that, anything but the "legacy" binary will > crash with an illegal opcode error. > > Best, > James Buchwald > > On 11/16/2016 08:49 AM, Igors Mihailovs igorsm__cfi.lu.lv wrote: >> >> Sent to CCL by: Igors Mihailovs [igorsm**cfi.lu.lv] >> Dear Prof. Lemos, I have also experienced this. I am not sure, but >> probably the Gaussian binaries are incompatible with Your CPU model? >> I.e., the CPU does not understand commands sent by Gaussian. It was a >> pity for me some time ago, knowing in addition that Windows version of >> Gaussian worked on the same PC well for years, but after installing >> Debian 8 Gaussian crashes with this error. My calculation was singlet >> state molecule geometry optimization, by the way. With best regards, >> Igors Mihailovs PhD student, Laboratory of Organic Materials ISSP UL >> >> On 10/11/16 14:24, Eduardo Lemos de sa edulsa|,|ufpr.br wrote: >>> Sent to CCL by: Eduardo Lemos de sa [edulsa-x-ufpr.br] >>> Dear CCLers >>> >>> I am faced with a strange behaviour with g09 (revisions C01 and >>> D01)running in a Debian8, amd64 cpus, with 12 cores and 64 GB ram. >>> >>> My input is: >>> >>> %nprocshared=4 >>> %mem=200MW >>> %chk=b3lyp-mult-optiz-davi.chk >>> #p b3lyp/lanl2dz freq pop=full gfprint gfinput iop(6/7=3) >>> >>> Geometria parcial com .cif from Davi-UFSM >>> >>> 0 5 >>> c >>> c 1 cc2 >>> c 2 cc3 1 ccc3 >>> c 3 cc4 2 ccc4 1 dih4 >>> c 4 cc5 3 ccc5 2 dih5 >>> c 5 cc6 4 ccc6 3 dih6 >>> c 2 cc7 3 ccc7 4 dih7 >>> n 7 nc8 2 ncc8 3 dih8 >>> c 8 cn9 7 cnc9 2 dih9 >>> c 9 cc10 8 ccn10 7 dih10 >>> o 10 oc11 9 occ11 8 dih11 >>> fe 8 fen12 9 fenc12 10 dih12 >>> cl 12 clfe13 8 clfen13 9 dih13 >>> c 9 cc14 8 ccn14 12 dih14 and others 49 (carbon >>> and hydrogen) atoms more >>> >>> This calculation stops (before executing l501) with this tail: >>> >>> Precomputing XC quadrature grid using >>> IXCGrd= 2 IRadAn= 0 IRanWt= -1 IRanGd= >>> 0 AccXCQ= 0.00D+00. >>> NRdTot= 4119 NPtTot= 529522 NUsed= 559187 NTot= >>> 559219 >>> NSgBfM= 386 387 387 387 388 NAtAll= 63 63. >>> Leave Link 302 at Thu Nov 10 09:58:07 2016, MaxMem= 209715200 >>> cpu: 18.6 >>> (Enter /usr/local/gaussian/g09/l303.exe) >>> DipDrv: MaxL=1. >>> Leave Link 303 at Thu Nov 10 09:58:07 2016, MaxMem= 209715200 >>> cpu: 0.9 >>> (Enter /usr/local/gaussian/g09/l401.exe) >>> Harris functional with IExCor= 402 diagonalized for initial guess. >>> ExpMin= 2.20D-02 ExpMax= 7.82D+03 ExpMxC= 2.73D+02 IAcc=3 >>> IRadAn= 5 AccDes= 0.00D+00 >>> HarFok: IExCor= 402 AccDes= 0.00D+00 IRadAn= 5 IDoV= 1 >>> ScaDFX= 1.000000 1.000000 1.000000 1.000000 >>> FoFCou: FMM=F IPFlag= 0 FMFlag= 100000 >>> FMFlg1= 2001 >>> NFxFlg= 0 DoJE=T BraDBF=F KetDBF=T FulRan=T >>> Omega= 0.000000 0.000000 1.000000 0.000000 0.000000 >>> ICntrl= 500 IOpCl= 0 >>> NMat0= 1 NMatS0= 1 NMatT0= 0 NMatD0= 1 >>> NMtDS0= 0 NMtDT0= 0 >>> I1Cent= 4 NGrid= 0. >>> Petite list used in FoFCou. >>> >>> >>> On screen, I only got: >>> >>> Error: illegal instruction, illegal opcode >>> rax 0000000000000029, rbx 00002b20a9159de0, rcx 0000000000000005 >>> rdx 0000000000000008, rsp 00007ffe00935d00, rbp 00007ffe00935de0 >>> rsi 00002b20a9292668, rdi 00002b20a92972f8, r8 00002b20a92972f8 >>> r9 0000000000000008, r10 0000000000000008, r11 ffffffffffffffff >>> r12 00002b20a9185ec8, r13 00002b20a9185d38, r14 00002b20a9292668 >>> r15 0000000000000000 >>> --- traceback not available >>> Aborted >>> >>> The same calculation finished without problems if a used a g09 (rev. >>> A1). >>> >>> After, if I try to run the same input for a small molecular (SO2, as >>> example), I do not have problems. >>> >>> I played with memmory trying to increase to 1200 MW, and the same bad >>> result happened. >>> >>> Please, could you give some hint about how to solve this problem? >>> >>> Thank you in advance >>> >>> Best regards >>> >>> Eduardo >>> >>> >>> >>> Eduardo Lemos de Sa >>> Associated Professor Level 4 >>> Dep. Quimica da Universidade Federal do Paraná >>> fone: +55(41)3361-3300 >>> fax: >>> +55(41)3361-3186http://www.ccl.net/chemistry/sub_unsub.shtmlConferences: >> http://server.ccl.net/chemistry/announcements/conferences/> >> > Thanks for your attention. I suspect that the problem was on incompatibility between g09 binaries and processor type. The strange is that some short calculations (like SO2 molecular optimization and vibrational spectrum calculations) run smoothly (the problem with this incompatibility should block this test), works without problems. I will try to collect more information about my CPU type. Until now, I got this (cat /dev/cpuinfo): processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 8 model name : Six-Core AMD Opteron(tm) Processor 2427 stepping : 0 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings : 6 core id : 0 cpu cores : 6 apicid : 8 initial apicid : 0 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 mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall bogomips : 4400.41 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate Please, is it a "Legacy" processor? Thank you again for your attention Best regards Eduardo -- Eduardo Lemos de Sa Associated Professor Level 4 Dep. Quimica da Universidade Federal do Paraná fone: +55(41)3361-3300 fax: +55(41)3361-3186 From owner-chemistry@ccl.net Fri Nov 18 12:10:00 2016 From: "Dan Pope daniel.j.pope^_^wsu.edu" To: CCL Subject: CCL: Lowest energy in first few SCF iterations Message-Id: <-52497-161116200021-24923-NS2kL+OTxMDFI+qm4z+jIg|a|server.ccl.net> X-Original-From: "Dan Pope" Date: Wed, 16 Nov 2016 20:00:19 -0500 Sent to CCL by: "Dan Pope" [daniel.j.pope(~)wsu.edu] Hello everyone, Im using DMol3 with a GGA-PBE functional and double numerical atomic basis set to model several periodic crystal systems. Across many of these systems, when doing a single point energy calculation, there seems to be a discrepancy between the solutions in the first or second SCF iteration that causes a huge decrease in energy in the 2nd or 3rd iteration, which then recovers to a high energy solution that the SCF then converges to. I do not understand whether this is a result of the initial guess of the SCF, whether or not the SCF is actually going between two totally different solutions, or if this indicates some other instability in the SCF early in the iterations. To study this further I tried using the "charge mixing feature in DMol3 to keep a large amount of character from each previous SCF iteration as part of the guess in the subsequent iteration. Indeed, when I use a lot of charge mixing the overall SCF behavior in the early iterations is stabilized. However, I do not understand why the SCF does not converge to the lower energy solution that it initially bounces to in the 2nd or 3rd iteration. Here is a sample output from a two atom bcc unit cell with no charge mixing. The input parameters are listed below. Total Energy (Ha) -172.625764 -173.051718 -172.447041 -172.439526 -172.439497 -172.439525 -172.439524 -172.439526 -172.439526 -172.439525 -172.439525 -172.439525 Input File # Task parameters Calculate energy Symmetry on Max_memory 4048 File_usage smart Scf_density_convergence 1.000000e-006 Scf_charge_mixing 1.0 Scf_iterations 50 # Electronic parameters Spin_polarization restricted Charge 0 Basis DN Pseudopotential dspp Functional pwc Harris off Aux_density octupole Integration_grid fine Occupation fermi Cutoff_Global 5.8000 angstrom Kpoints monk 14 14 14 From owner-chemistry@ccl.net Fri Nov 18 15:27:01 2016 From: "Igors Mihailovs igorsm%%cfi.lu.lv" To: CCL Subject: CCL:G: Strange g09 error message Message-Id: <-52498-161118151712-16086-/NTzgeubZ5JsztOmp5JSUA**server.ccl.net> X-Original-From: Igors Mihailovs Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed Date: Fri, 18 Nov 2016 22:17:18 +0200 MIME-Version: 1.0 Sent to CCL by: Igors Mihailovs [igorsm===cfi.lu.lv] Dear all, If you are interested, I, in turn, have those problems on Intel(R) Xeon(TM) CPU 3.20GHz CPU family: 15 Model: 6 Stepping: 4 CPU MHz: 3192.104 BogoMIPS: 6383.71 Virtualization: VT-x L1d cache: 16K L2 cache: 2048K NUMA node0 CPU(s): 0-7 Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 2 NUMA node(s): 1 And as I mentioned previously, on Windows Gaussian works on the same PC... Best regards, Igors On 18/11/16 17:24, Eduardo edulsa=ufpr.br wrote: > > Sent to CCL by: Eduardo [edulsa~~ufpr.br] > Dear dR. Buchwald and Mihyailovs > >> >> Sent to CCL by: James Buchwald [buchwj * rpi.edu] >> Igors and Prof. Lemos, >> >> I think your suspicion is correct here - the target machine is equipped >> with amd64 CPUs, and I'll bet the Gaussian binary uses a SIMD >> instruction set for later Intel models. According to the Gaussian >> website (http://www.gaussian.com/g_prod/g09_plat.pdf), rev E01 has three >> versions for x86-64 CPUs - an AVX-enabled version, an SSE4.2-enabled >> version, and a "legacy" version for older x86-64 processors. >> >> Both AVX and SSE4.2 first appeared in AMD processors with the Bulldozer >> microarchitecture, which first appeared on the market in late 2011. So >> if the CPUs are older than that, anything but the "legacy" binary will >> crash with an illegal opcode error. >> >> Best, >> James Buchwald >> >> On 11/16/2016 08:49 AM, Igors Mihailovs igorsm__cfi.lu.lv wrote: >>> >>> Sent to CCL by: Igors Mihailovs [igorsm**cfi.lu.lv] >>> Dear Prof. Lemos, I have also experienced this. I am not sure, but >>> probably the Gaussian binaries are incompatible with Your CPU model? >>> I.e., the CPU does not understand commands sent by Gaussian. It was a >>> pity for me some time ago, knowing in addition that Windows version of >>> Gaussian worked on the same PC well for years, but after installing >>> Debian 8 Gaussian crashes with this error. My calculation was singlet >>> state molecule geometry optimization, by the way. With best regards, >>> Igors Mihailovs PhD student, Laboratory of Organic Materials ISSP UL >>> >>> On 10/11/16 14:24, Eduardo Lemos de sa edulsa|,|ufpr.br wrote: >>>> Sent to CCL by: Eduardo Lemos de sa [edulsa-x-ufpr.br] >>>> Dear CCLers >>>> >>>> I am faced with a strange behaviour with g09 (revisions C01 and >>>> D01)running in a Debian8, amd64 cpus, with 12 cores and 64 GB ram. >>>> >>>> My input is: >>>> >>>> %nprocshared=4 >>>> %mem=200MW >>>> %chk=b3lyp-mult-optiz-davi.chk >>>> #p b3lyp/lanl2dz freq pop=full gfprint gfinput iop(6/7=3) >>>> >>>> Geometria parcial com .cif from Davi-UFSM >>>> >>>> 0 5 >>>> c >>>> c 1 cc2 >>>> c 2 cc3 1 ccc3 >>>> c 3 cc4 2 ccc4 1 dih4 >>>> c 4 cc5 3 ccc5 2 dih5 >>>> c 5 cc6 4 ccc6 3 dih6 >>>> c 2 cc7 3 ccc7 4 dih7 >>>> n 7 nc8 2 ncc8 3 dih8 >>>> c 8 cn9 7 cnc9 2 dih9 >>>> c 9 cc10 8 ccn10 7 dih10 >>>> o 10 oc11 9 occ11 8 dih11 >>>> fe 8 fen12 9 fenc12 10 dih12 >>>> cl 12 clfe13 8 clfen13 9 dih13 >>>> c 9 cc14 8 ccn14 12 dih14 and others 49 (carbon >>>> and hydrogen) atoms more >>>> >>>> This calculation stops (before executing l501) with this tail: >>>> >>>> Precomputing XC quadrature grid using >>>> IXCGrd= 2 IRadAn= 0 IRanWt= -1 IRanGd= >>>> 0 AccXCQ= 0.00D+00. >>>> NRdTot= 4119 NPtTot= 529522 NUsed= 559187 NTot= >>>> 559219 >>>> NSgBfM= 386 387 387 387 388 NAtAll= 63 63. >>>> Leave Link 302 at Thu Nov 10 09:58:07 2016, MaxMem= 209715200 >>>> cpu: 18.6 >>>> (Enter /usr/local/gaussian/g09/l303.exe) >>>> DipDrv: MaxL=1. >>>> Leave Link 303 at Thu Nov 10 09:58:07 2016, MaxMem= 209715200 >>>> cpu: 0.9 >>>> (Enter /usr/local/gaussian/g09/l401.exe) >>>> Harris functional with IExCor= 402 diagonalized for initial guess. >>>> ExpMin= 2.20D-02 ExpMax= 7.82D+03 ExpMxC= 2.73D+02 IAcc=3 >>>> IRadAn= 5 AccDes= 0.00D+00 >>>> HarFok: IExCor= 402 AccDes= 0.00D+00 IRadAn= 5 IDoV= 1 >>>> ScaDFX= 1.000000 1.000000 1.000000 1.000000 >>>> FoFCou: FMM=F IPFlag= 0 FMFlag= 100000 >>>> FMFlg1= 2001 >>>> NFxFlg= 0 DoJE=T BraDBF=F KetDBF=T FulRan=T >>>> Omega= 0.000000 0.000000 1.000000 0.000000 0.000000 >>>> ICntrl= 500 IOpCl= 0 >>>> NMat0= 1 NMatS0= 1 NMatT0= 0 NMatD0= 1 >>>> NMtDS0= 0 NMtDT0= 0 >>>> I1Cent= 4 NGrid= 0. >>>> Petite list used in FoFCou. >>>> >>>> >>>> On screen, I only got: >>>> >>>> Error: illegal instruction, illegal opcode >>>> rax 0000000000000029, rbx 00002b20a9159de0, rcx 0000000000000005 >>>> rdx 0000000000000008, rsp 00007ffe00935d00, rbp 00007ffe00935de0 >>>> rsi 00002b20a9292668, rdi 00002b20a92972f8, r8 00002b20a92972f8 >>>> r9 0000000000000008, r10 0000000000000008, r11 ffffffffffffffff >>>> r12 00002b20a9185ec8, r13 00002b20a9185d38, r14 00002b20a9292668 >>>> r15 0000000000000000 >>>> --- traceback not available >>>> Aborted >>>> >>>> The same calculation finished without problems if a used a g09 (rev. >>>> A1). >>>> >>>> After, if I try to run the same input for a small molecular (SO2, as >>>> example), I do not have problems. >>>> >>>> I played with memmory trying to increase to 1200 MW, and the same bad >>>> result happened. >>>> >>>> Please, could you give some hint about how to solve this problem? >>>> >>>> Thank you in advance >>>> >>>> Best regards >>>> >>>> Eduardo >>>> >>>> >>>> >>>> Eduardo Lemos de Sa >>>> Associated Professor Level 4 >>>> Dep. Quimica da Universidade Federal do Paraná >>>> fone: +55(41)3361-3300 >>>> fax: >>>> +55(41)3361-3186http://www.ccl.net/chemistry/sub_unsub.shtmlConferences: >>>> >>> http://server.ccl.net/chemistry/announcements/conferences/> >>> >> > > Thanks for your attention. > > I suspect that the problem was on incompatibility between g09 binaries > and processor type. The strange is that some short calculations (like > SO2 molecular optimization and vibrational spectrum calculations) run > smoothly (the problem with this incompatibility should block this > test), works without problems. > > I will try to collect more information about my CPU type. Until now, I > got this (cat /dev/cpuinfo): > > processor : 0 > vendor_id : AuthenticAMD > cpu family : 16 > model : 8 > model name : Six-Core AMD Opteron(tm) Processor 2427 > stepping : 0 > cpu MHz : 800.000 > cache size : 512 KB > physical id : 0 > siblings : 6 > core id : 0 > cpu cores : 6 > apicid : 8 > initial apicid : 0 > 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 mmx fxsr sse sse2 ht syscall nx mmxext > fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl > nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm > extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit > wdt hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall > bogomips : 4400.41 > TLB size : 1024 4K pages > clflush size : 64 > cache_alignment : 64 > address sizes : 48 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > Please, is it a "Legacy" processor? > > Thank you again for your attention > > Best regards > > Eduardo > -- Ar cieņu, Igors Mihailovs Organisko materiālu laboratorija LU CFI From owner-chemistry@ccl.net Fri Nov 18 20:53:00 2016 From: "James Buchwald buchwj . rpi.edu" To: CCL Subject: CCL:G: Strange g09 error message Message-Id: <-52499-161118123708-14400-ubFlmzemPEfkW4TqRRLONw]^[server.ccl.net> X-Original-From: James Buchwald Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8; format=flowed Date: Fri, 18 Nov 2016 12:36:59 -0500 MIME-Version: 1.0 Sent to CCL by: James Buchwald [buchwj##rpi.edu] Prof. Lemos, Yes, an Opteron 2427 is a "legacy" processor - it belongs to the AMD K10 microarchitecture, so you don't have SSE4.2 or AVX support. You can see this under the "flags" section of your cpuinfo: there is no "sse4_2" or "avx" flag set. It's perhaps not surprising that some calculations still run correctly - so long as that code doesn't make use of any SSE4.2 or AVX instructions, it should run as normal. Without knowing how the Gaussian code is optimized and how the compiler is optimizing the code automatically, though, it's hard to say what should and shouldn't work. Best, James Buchwald On 11/18/2016 10:24 AM, Eduardo edulsa=ufpr.br wrote: > > Sent to CCL by: Eduardo [edulsa~~ufpr.br] > Dear dR. Buchwald and Mihyailovs > >> >> Sent to CCL by: James Buchwald [buchwj * rpi.edu] >> Igors and Prof. Lemos, >> >> I think your suspicion is correct here - the target machine is equipped >> with amd64 CPUs, and I'll bet the Gaussian binary uses a SIMD >> instruction set for later Intel models. According to the Gaussian >> website (http://www.gaussian.com/g_prod/g09_plat.pdf), rev E01 has three >> versions for x86-64 CPUs - an AVX-enabled version, an SSE4.2-enabled >> version, and a "legacy" version for older x86-64 processors. >> >> Both AVX and SSE4.2 first appeared in AMD processors with the Bulldozer >> microarchitecture, which first appeared on the market in late 2011. So >> if the CPUs are older than that, anything but the "legacy" binary will >> crash with an illegal opcode error. >> >> Best, >> James Buchwald >> >> On 11/16/2016 08:49 AM, Igors Mihailovs igorsm__cfi.lu.lv wrote: >>> >>> Sent to CCL by: Igors Mihailovs [igorsm**cfi.lu.lv] >>> Dear Prof. Lemos, I have also experienced this. I am not sure, but >>> probably the Gaussian binaries are incompatible with Your CPU model? >>> I.e., the CPU does not understand commands sent by Gaussian. It was a >>> pity for me some time ago, knowing in addition that Windows version of >>> Gaussian worked on the same PC well for years, but after installing >>> Debian 8 Gaussian crashes with this error. My calculation was singlet >>> state molecule geometry optimization, by the way. With best regards, >>> Igors Mihailovs PhD student, Laboratory of Organic Materials ISSP UL >>> >>> On 10/11/16 14:24, Eduardo Lemos de sa edulsa|,|ufpr.br wrote: >>>> Sent to CCL by: Eduardo Lemos de sa [edulsa-x-ufpr.br] >>>> Dear CCLers >>>> >>>> I am faced with a strange behaviour with g09 (revisions C01 and >>>> D01)running in a Debian8, amd64 cpus, with 12 cores and 64 GB ram. >>>> >>>> My input is: >>>> >>>> %nprocshared=4 >>>> %mem=200MW >>>> %chk=b3lyp-mult-optiz-davi.chk >>>> #p b3lyp/lanl2dz freq pop=full gfprint gfinput iop(6/7=3) >>>> >>>> Geometria parcial com .cif from Davi-UFSM >>>> >>>> 0 5 >>>> c >>>> c 1 cc2 >>>> c 2 cc3 1 ccc3 >>>> c 3 cc4 2 ccc4 1 dih4 >>>> c 4 cc5 3 ccc5 2 dih5 >>>> c 5 cc6 4 ccc6 3 dih6 >>>> c 2 cc7 3 ccc7 4 dih7 >>>> n 7 nc8 2 ncc8 3 dih8 >>>> c 8 cn9 7 cnc9 2 dih9 >>>> c 9 cc10 8 ccn10 7 dih10 >>>> o 10 oc11 9 occ11 8 dih11 >>>> fe 8 fen12 9 fenc12 10 dih12 >>>> cl 12 clfe13 8 clfen13 9 dih13 >>>> c 9 cc14 8 ccn14 12 dih14 and others 49 (carbon >>>> and hydrogen) atoms more >>>> >>>> This calculation stops (before executing l501) with this tail: >>>> >>>> Precomputing XC quadrature grid using >>>> IXCGrd= 2 IRadAn= 0 IRanWt= -1 IRanGd= >>>> 0 AccXCQ= 0.00D+00. >>>> NRdTot= 4119 NPtTot= 529522 NUsed= 559187 NTot= >>>> 559219 >>>> NSgBfM= 386 387 387 387 388 NAtAll= 63 63. >>>> Leave Link 302 at Thu Nov 10 09:58:07 2016, MaxMem= 209715200 >>>> cpu: 18.6 >>>> (Enter /usr/local/gaussian/g09/l303.exe) >>>> DipDrv: MaxL=1. >>>> Leave Link 303 at Thu Nov 10 09:58:07 2016, MaxMem= 209715200 >>>> cpu: 0.9 >>>> (Enter /usr/local/gaussian/g09/l401.exe) >>>> Harris functional with IExCor= 402 diagonalized for initial guess. >>>> ExpMin= 2.20D-02 ExpMax= 7.82D+03 ExpMxC= 2.73D+02 IAcc=3 >>>> IRadAn= 5 AccDes= 0.00D+00 >>>> HarFok: IExCor= 402 AccDes= 0.00D+00 IRadAn= 5 IDoV= 1 >>>> ScaDFX= 1.000000 1.000000 1.000000 1.000000 >>>> FoFCou: FMM=F IPFlag= 0 FMFlag= 100000 >>>> FMFlg1= 2001 >>>> NFxFlg= 0 DoJE=T BraDBF=F KetDBF=T FulRan=T >>>> Omega= 0.000000 0.000000 1.000000 0.000000 0.000000 >>>> ICntrl= 500 IOpCl= 0 >>>> NMat0= 1 NMatS0= 1 NMatT0= 0 NMatD0= 1 >>>> NMtDS0= 0 NMtDT0= 0 >>>> I1Cent= 4 NGrid= 0. >>>> Petite list used in FoFCou. >>>> >>>> >>>> On screen, I only got: >>>> >>>> Error: illegal instruction, illegal opcode >>>> rax 0000000000000029, rbx 00002b20a9159de0, rcx 0000000000000005 >>>> rdx 0000000000000008, rsp 00007ffe00935d00, rbp 00007ffe00935de0 >>>> rsi 00002b20a9292668, rdi 00002b20a92972f8, r8 00002b20a92972f8 >>>> r9 0000000000000008, r10 0000000000000008, r11 ffffffffffffffff >>>> r12 00002b20a9185ec8, r13 00002b20a9185d38, r14 00002b20a9292668 >>>> r15 0000000000000000 >>>> --- traceback not available >>>> Aborted >>>> >>>> The same calculation finished without problems if a used a g09 (rev. >>>> A1). >>>> >>>> After, if I try to run the same input for a small molecular (SO2, as >>>> example), I do not have problems. >>>> >>>> I played with memmory trying to increase to 1200 MW, and the same bad >>>> result happened. >>>> >>>> Please, could you give some hint about how to solve this problem? >>>> >>>> Thank you in advance >>>> >>>> Best regards >>>> >>>> Eduardo >>>> >>>> >>>> >>>> Eduardo Lemos de Sa >>>> Associated Professor Level 4 >>>> Dep. Quimica da Universidade Federal do Paraná >>>> fone: +55(41)3361-3300 >>>> fax: >>>> +55(41)3361-3186http://www.ccl.net/chemistry/sub_unsub.shtmlConferences: >>>> >>> http://server.ccl.net/chemistry/announcements/conferences/> >>> >> > > Thanks for your attention. > > I suspect that the problem was on incompatibility between g09 binaries > and processor type. The strange is that some short calculations (like > SO2 molecular optimization and vibrational spectrum calculations) run > smoothly (the problem with this incompatibility should block this > test), works without problems. > > I will try to collect more information about my CPU type. Until now, I > got this (cat /dev/cpuinfo): > > processor : 0 > vendor_id : AuthenticAMD > cpu family : 16 > model : 8 > model name : Six-Core AMD Opteron(tm) Processor 2427 > stepping : 0 > cpu MHz : 800.000 > cache size : 512 KB > physical id : 0 > siblings : 6 > core id : 0 > cpu cores : 6 > apicid : 8 > initial apicid : 0 > 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 mmx fxsr sse sse2 ht syscall nx mmxext > fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl > nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm > extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit > wdt hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall > bogomips : 4400.41 > TLB size : 1024 4K pages > clflush size : 64 > cache_alignment : 64 > address sizes : 48 bits physical, 48 bits virtual > power management: ts ttp tm stc 100mhzsteps hwpstate > > Please, is it a "Legacy" processor? > > Thank you again for your attention > > Best regards > > Eduardo > -- James R. Buchwald Doctoral Candidate, Dinolfo Laboratory Dept. of Chemistry and Chemical Biology Rensselaer Polytechnic Institute http://www.rpi.edu/~buchwj From owner-chemistry@ccl.net Fri Nov 18 21:28:00 2016 From: "Andre Schleife schleife%a%illinois.edu" To: CCL Subject: CCL: TDDFT summer school+workshop, Telluride, July 2017 Message-Id: <-52500-161118192015-5790-xmvJiSF8ggiJPp+uwa/KtA#server.ccl.net> X-Original-From: "Andre Schleife" Date: Fri, 18 Nov 2016 19:20:14 -0500 Sent to CCL by: "Andre Schleife" [schleife,,illinois.edu] Dear colleagues, We are happy to announce that on July 11 - 15, 2017, the Telluride Science Research Center is home to the first Telluride School on Time-Dependent Density Functional Theory. Please find all details here: https://www.telluridescience.org/schools/telluride-school-time-dependent-density- function-theory The school plans to host ~30 interested and motivated graduate students and post- docs. Applications are open now and will close on Friday, February 10, 2017. The application link is here: https://telluridescience.org/#overlay=node/add/telluride-school-time-depend-app Following the 5-day school, there will be a 5-day workshop on Excited States: Electronic Structure and Dynamics where invited speakers who are experts in TDDFT and applications will present their latest research. Summer school teachers will be presenting at the workshop, and students are encouraged to stay for the workshop (separate registration is necessary)! School Description: An accurate computational description of electronic excitations and charge-transfer processes that underlie e.g. next-generation energy-conversion, energy-storage, and catalytic systems through time-dependent quantum-mechanical theory is one of the most desirable goals of computational science today! This challenge requires accurate and efficient methods to compute ground and excited states, as well as the ability to explicitly treat real-time dynamics of electrons for systems consisting of hundreds of atoms: TDDFT arguably is the best compromise between accuracy and computational efficiency. While TDDFT is formally exact, in practice approximations are needed and are far from black box. Many TDDFT scientific studies rely on high-performance super computers. Excellent scaling of TDDFT has been reported up to millions of cores, rendering this technique a highly interesting use case for the next generation of super computers. Clearly, it is essential for a user of TDDFT to have deep understanding of the theory along with hands-on experience in order to successfully model systems of interest - this is the goal of this school. School Format: This summer school is aimed at graduate students and postdoctoral fellows from computational as well as experimental research groups who seek to develop a deep understanding of TDDFT, regarding its capabilities, applications, limitations, and high- performance computing context. Attendees will be equipped with the theoretical and practical expertise to simulate time-dependent quantum dynamics of many-electron systems. Theory lectures in the morning of each day, given by world-leading experts, will cover fundamental, theoretical aspects of TDDFT. Hands-on computational sessions in the afternoon will equip students with practical skills in two or three TDDFT codes. Please bring a laptop computer, as there are none available at TSRC and the hands-on activities require a computer! If you have any questions, please do not hesitate to contact the organizers at tddft.us++gmail.com. We are looking forward to seeing you in beautiful Telluride! Christine Isborn (University of California at Merced) Neepa Maitra (Hunter College City University of New York) Andre Schleife (University of Illinois at Urbana-Champaign) http://psi-k.net/events/tddft-summer-schoolworkshop-telluride-july-2017