From owner-nwchem-users@emsl.pnl.gov Fri Apr 27 11:55:41 2007 Received: from odyssey.emsl.pnl.gov (localhost [127.0.0.1]) by odyssey.emsl.pnl.gov (8.13.8/8.13.8) with ESMTP id l3RItecr020686 for ; Fri, 27 Apr 2007 11:55:41 -0700 (PDT) Received: (from majordom@localhost) by odyssey.emsl.pnl.gov (8.13.8/8.13.8/Submit) id l3RIteXL020685 for nwchem-users-outgoing-0915; Fri, 27 Apr 2007 11:55:40 -0700 (PDT) X-Authentication-Warning: odyssey.emsl.pnl.gov: majordom set sender to owner-nwchem-users@emsl.pnl.gov using -f X-Possible-Spoof: True X-IronPort-AV: i="4.14,462,1170662400"; d="scan'208"; a="29876261:sNHT41646836" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [NWCHEM] periodic code and hf: the truth? Date: Fri, 27 Apr 2007 11:55:36 -0700 Message-ID: In-Reply-To: <4631DF19.11F0.001D.0@empa.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NWCHEM] periodic code and hf: the truth? Thread-Index: AceIsYhqzS3zBKrxTPqz1MpGJb+hlgARZkVA References: <4631DF19.11F0.001D.0@empa.ch> From: "Bylaska, Eric J" To: "Daniele Passerone" , Cc: "Wang, Dunyou" , "DeJong, Wibe A" X-OriginalArrivalTime: 27 Apr 2007 18:55:37.0669 (UTC) FILETIME=[A4D22F50:01C788FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by odyssey.emsl.pnl.gov id l3RItdw5020682 Sender: owner-nwchem-users@emsl.pnl.gov Precedence: bulk Daniele, I'm very sorry for your problems with the code. In looking at your past emails you seem to be having two problems. 1) Getting the code to run in parallel over sockets 2) Using HF. Question 1) In looking at you email you're using the following compilation variables. export LARGE_FILES="TRUE" export TCGRSH=`which ssh` export NWCHEM_MODULES=all export NWCHEM_TARGET=LINUX64 export USE_MPI="y" export USE_MPIF="y" export LIBMPI="-lfmpich -lmpich -lpmpich" export MPI_LOC="/opt/mpich/intel" export MPI_LIB="$MPI_LOC/lib" export MPI_INCLUDE="$MPI_LOC/include" I suspect that your problem is that mpi was compiled with integer*4 fortran bindings instead of integer*8 fortran bindings. On many 64 bit machines integers are by default 4 bytes in C rather than 8 bytes. The simplest thing to do is to unset "USE_MPIF" The code should still work, however, all the message passing will be strictly synchronous. However, since it looks like your running over sockets it probably doesn't matter that much. You can try to compile mpich with integer*8 bindings however, you'll probably have to change the mpich source code to make this work, in particular the MPI_INTEGER variables will have to be defined as 8 bytes. Another option is to get a copy of the development version of nwchem from Dunyou Wang (dunyou.wang@pnl.gov). I have recently implemented a patch to take care of the integer*4 binding problem. In the development version to use integer*4 bindings in mpi setenv USE_MPIF .true. setenv USE_MPIF4 .true. Question 2) The problem your running into with the HF code is two fold. i) The pseudopotential generation code does not currently have exact exchange in it. Therefore you need to generate the pseudopotential with lda or pbe96. Another option is to generate a pseudopotential with another pseudopotential code such as OPIUM. ii) The default code that generates the intitial wavefunctions does recognize exact exchange in 5.0. The type checking in this fell through the cracks in the 5.0 release. However, this is in general not a big deal since to run the HF code efficiently one should first get an intitial wavefunction using a non-exact exchange function. You can change the intital wavefunction generator to a random guess by setting the following variable in the run-time database (rtdb) set nwpw:lcao_skip .true. Both of these type checking problems should be fixed by the next release. In the meantime, The following sequence should allow you to run a pbe0 calculation: ... nwpw xc pbe96 end task pspw energy Nwpw xc pbe0 End Task pspw energy Two run a HF calculation... Nwpw End Task pspw energy Nwpw xc hf End Task pspw energy Finally, a few comments about using exact exchange with 5.0 1) Exact exchange calculations are considerably more expensive than non-hybrid functions. While we have been able to run 500 atoms using this code, we were using a minimum of 64 processors with a fast paralllel network to do these type of calculations. That being said if your calculating simple semiconductor systems, such as Si, SiC, GaN...., where cutoff energies are 40Ry (20au) or less I've run the exact exchange code with up to 64 atoms pretty easilly. However, if your running transition metal oxide systems with cutoff energies of +100Ry then you may need a big computer to do a non-trivial calculation. 2) analytic stresses for exact exchange have been implemented and are using by default in a unit cell optimization. 3) exact exchange in not currently implemented into the band structure or paw codes. I've been working on these capabilities and there is a chance they'll make it into the next release. 4) virtual orbital are not calculated by default in pspw. To calculate virtual orbitals set the following rtdb variable set nwpw:excited_ne 2 2 Eric Bylaska -----Original Message----- From: owner-nwchem-developers@emsl.pnl.gov [mailto:owner-nwchem-developers@emsl.pnl.gov] On Behalf Of Daniele Passerone Sent: Friday, April 27, 2007 2:32 AM To: nwchem-users@emsl.pnl.gov Subject: [NWCHEM] periodic code and hf: the truth? Dear Nwchem developers and users, I would like to know what is the current state of development for such and useful code like the pw code of nwchem which allows to use hartree-fock exchange in periodic systems. We are having MANY problems with this code, things that were working in nwchem 4.7 are not working anymore in version 5.0, many submissions to the mailing lists on the subject "pspw" are often left without answer, and so on. Not to speak about the lacking of documentation about this. So, we are considering now to move to a commercial code, since it does not seem possible to produce serious scientific results within this scheme. I would like to learn that I am wrong, and I understand the effort behind the nwchem development. But I am rather disappointed by the lack of information about this particular code, and its future in the nwchem suite. Thank you in advance for your clarification, Daniele Passerone