Subject: Potential Problems with DeFT

From: [email-masked] (Alain St-Amant)
Date: Fri, 7 Jul 1995 19:36:08 -0400

[email-masked] (Delin Shen) writes:

>
>Dear Netters,
>
>   We are currently installing DeFT program of Dr. St-Amant in several 
>computer systems. we  came cross one section of the program that we think 
>might has a minor mistake:
>
>  subroutine delphidr.f
>
>  >>130     call delphi(ndelphi,ncenters,nptcharges,ngrid,ngridby2,natomtype,
>  >>131    &            iwkvec,epsilon,coord,wkvec(jf),coordptcharge,ptcharge,
>  >>132    &            wkvec(ja),wkvec(jb),wkvec(jc),wkvec(jd),wkvec(je),
>  >>133    &            wkvec(ig),wkvec(jh))
>                                                         ^^
>         Should it be "jg" instead of "ig"?

Sorry about that.  Yes it should be "jg" instead of "ig".  For those using
the code, don't worry about it.  `delphi' is the module having to do with
the program's solvation model, which I never got around to finishing up.
It's very similar to the Honig/Friesner work.  As it is, there's nothing
in the input deck that you can add to make this routine jump into action.

>   There also some other sections of the program that don't conform standard
> Fortran. We sent Dr. St-Amant a message more than month ago about this and
> haven't got any answers yet.

Sorry about the delay in getting back.  To anybody who doesn't get a reply
within a day or two, just e-mail me again.

Again, don't worry about it.  Answers are in no way affected.  The problem
that arose is that one of the subroutines (gradxxds1.f) had an extra
(or *bonus* :-)) argument at the end of its argument list (grad).
This argument is never used throughout the course of the subroutine.  The
calls to this subroutine therefore seem to have one too few arguments.  Since
the missing argument is the never used last argument, no problem.  No wonder
it slipped my attention.  But to make everything nice, people should remove
'grad' from the 'gradxxd1.f' argument list.

>  We have reproduced all sample output. The problem we have right now
>is a test run we did with benzene optimization using a fine and random grid:
>D6h symmetry input gives nonsymmetrical result. Since it is optimization
>without conserving the symmetry, we are not expecting output with D6h
>symmetry. What bothers us is that C-H bond distances differ about 0.03 A.

This is way too big a variation.  True, the grids can't maintain the symmetry
of benzene, and there will be variations in bond lengths, but nowhere near this
large.  I've run it, and I get nowhere near the errors^H^H^H^H^H^H noise (:-)
you're getting.  All C--C bonds are within 0.0001 Angstroms of each other and
all C--H bonds are within 0.0001 Angstroms of each other, which of course is
but a fraction of the inherent errors of DFT relative to experiment.  This
is actually better than usual.  Don't be shocked with something of the order
of 0.001-0.002 Angstroms.  A fine grid slaps on about 3000 points per atoms.

Send me a copy of your input deck, and I'll check it for potential problems.

For those wondering why we can't maintain D6H symmetry:

   Unfortunately, the grids used don't have the symmetry of the molecule
   in question and symmetry is broken.  We could enforce symmetry, but that
   would be sweeping the problem under a rug.  Randomizing the orientation
   of the angular points on the radial shells is an attempt to smooth out
   the noise in the total energy (at the cost of losing symmetry in systems
   that actually could maintain their symmetry with the grids in question).

Hope this helps.

Nicely recovering from the coronary I had when I saw 0.03 Angstroms,

Alain

P.S.  DeFT is available for free from the OSC archives.  If you want, just
      come over to the U. of Ottawa Chemistry WWW site and there will be a
      hyperlink to the specific place in the archives where DeFT is stored.