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 <nwchem-users-outgoing-0915@odyssey.emsl.pnl.gov>; 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: <C4BF0852F93C9E40AFD9338575B896580173FABB@EMAIL01.pnl.gov>
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" <Eric.Bylaska@pnl.gov>
To: "Daniele Passerone" <Daniele.Passerone@empa.ch>,
        <nwchem-users@emsl.pnl.gov>
Cc: "Wang, Dunyou" <dunyou.wang@pnl.gov>,
        "DeJong, Wibe A" <Wibe.DeJong@pnl.gov>
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