Subject: Re: CCL:symmetry change

From: Roy Jensen <[email-masked]>
Date: Thu, 05 Apr 2001 01:37:22 -0700

The following simple job dies as stated. I am using G98W A.9.
Phillip has a H2O input file that also fails. I am curious if his also
completes a complete iteration after the symmetry change is detected
before crashing with x=2.

Roy Jensen

**********************************************
#P UB3LYP/3-21G opt(verytight) IOP(2/9=222,2/16=3)

Sample run to show problem with IOP(2/16=x) and changing symmetry.
x=1,2,3 should allow the job to continue when the symmetry changes. 
This is not the case. A FIOCOM error occurs one or two iterations 
after the symmetry change is detected:
     x=1 or 3 dies immediately after the symmetry change is detected.
     x=2 completes one itteration and then dies.

0 1
H
N 1 R1
C 2 R2 1 A1
X 3 1. 2 90. 1 0.
O 3 R3 4 A2 1 D1

R1=1.00
R2=1.20
R3=1.19
A1=140.7
A2=86.2
D1=179.9999
**********************************************

On Thu, 05 Apr 2001 09:38:07 +0200, you wrote:

> Roy Jensen wrote:
> > 
> > I have not been able to get this IOP to work in G98W. Gaussian is
> > aware of the error; I have sent them a simple input file that fails.
> > No response yet...
> > 
> > Roy Jensen
> > 
> > > Instead of the NOSYM keyword, and loosing the efficiency..., you can use
> > > the
> > > keyword IOP(2/16=N) which keeps all advantages of symmetry and keep
> > > going if the point group change.
> > > If N=1 : keep going
> > >    N=2 : keep going and leave symmetry on, using the old symmetry
> > >    N=3 : keep going and leave symmetry on, using the new symmetry.
> 
> Which value is not working? I use IOP(2/16=1) and it works perfectly, 
> at least as long as I remember. Could you, please, send me the input 
> file which presents this discrepancy. I am very curious about it.
> Yours.

---

From: Xavier ASSFELD <[email-masked]>
Date: Thu, 05 Apr 2001 11:40:55 +0200

Amazing!

I tried, unsuccessfuly, to make your job run correctly.
You are right. This keyword fails when the symmetry is
increased. In all the cases I have studied so far, the
symmetry was decreased and the keyword seems to work fine.

here follows a small example.

# HF/STO-3G SCF=DIRECT SCAN IOP(2/16=3)

NH3

0  1
X
N  1  1.
H  2  R  1 A
H  2  R  1 A  3  120.
H  2  R  1 A  3  240.

R  0.9
A  90. 3 10.

-- 

                                      ...Xav

WARNING! NEW E-MAIL ADDRESS !
(u-nancy changed to uhp-nancy)

Ast. Pr. Xavier Assfeld             [email-masked]
Laboratoire de Chimie theorique     (T) 33 3 83 91 21 49
Universite Henri Poincare           (F) 33 3 83 91 25 30
F-54506 Nancy BP 239                http://www.lctn.uhp-nancy.fr

---

From: Nicolas Ferre <[email-masked]>
Date: Thu, 5 Apr 2001 13:12:46 +0100

Hi all,
In fact, it is a read-write file error. Due to the symmetry increase, the 
amount of memory allocated for this rwf (579) is not sufficient. To correct 
this bug, if you have access to the source code, you can add the following 
lines in the link 202. In subroutine Omega, just before the line 

     Call FileIO(1,-IRwNEq,InToWP(NOp2*NAtoms),NEqAtm,0) 

add
 
      CALL FILEIO(11,-IRWNEQ,LEN,NEqAtm,0)                                    
      IF(LEN.NE.0) THEN                                                       
         LEN=INTOWP(NOP2*NATOMS)-LEN                                          
         CALL FILEIO(20,-IRWNEQ,LEN,NEqAtm,0) 
      ENDIF
It adjusts the length of the rwf.
The job you gave now works fine ... until it crashes because 20 optimization 
steps are not enough to achieve a verytight optimization job !

			Nicolas

On Thursday 05 April 2001 10:37, Roy Jensen wrote:
> > > > Instead of the NOSYM keyword, and loosing the efficiency..., you can
> > > > use the
> -= This is automatically added to each message by mailing script =-
> [email-masked] -- To Everybody  | [email-masked] -- To Admins
> [email-masked] -- HELP CHEMISTRY or HELP SEARCH
> [email-masked] -- archive search    |    Gopher: gopher.ccl.net
> 70 Ftp: ftp.ccl.net  |  WWW: http://www.ccl.net/chemistry/   | Jan:
> [email-masked]

-- 
Nicolas FERRE
Equipe de Chimie Theorique - UMR UHP/CNRS 7565
BP 139 - 54506 VANDOEUVRE-LES-NANCY - FRANCE

Phone: +33 3 83 91 20 00 (ask for 35 52)
Fax :    +33 3 83 91 25 30
http://www.lctn.uhp-nancy.fr/Etudiants/Nicolas.Ferre.html

---

From: "Phillip D. Matz" <[email-masked]>
Date: Thu, 5 Apr 2001 09:24:57 -0700

Hi!

Looks like I missed out on all the dialogue between Roy and Xavier...  At
any rate, to answer Roy's question when IOP(2/16=2) is employed the H2O job
crashes during the initial guess (l401.exe) immediately following the
detected change in symmetry (from Cs to C2v).

I think Roy is onto something by noticing the order of symmetry change is
dictating the success of these jobs.  My simple jobs crash when the symmetry
is increased (from Cs to C2v).  At least this means that, for certain jobs,
we can set up our jobs intelligently and take advantage of the reduction in
computation costs due to symmetry.

Does anyone know of the historic reasoning why this is even an issue?  I'm
not a programmer but it seems like this is a programming issue.  I don't
know if I would call it a *feature* when my job stops because the molecular
symmetry changes - a comment regarding the change in pt. group in my output
file is nice but I would be quite happy if the job just kept going and
finished correctly.

Respectfully,

Phillip Matz

----- Original Message -----
From: "Roy Jensen" <[email-masked]>
To: "Xavier ASSFELD" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, April 05, 2001 1:37 AM
Subject: Re: CCL:symmetry change

> before crashing with x=2.
use

---

From: "Phillip D. Matz" <[email-masked]>
Date: Thu, 5 Apr 2001 09:41:34 -0700

Hi Nicolas,

Don't get me wrong here, but is it common to change the source code?  I
can't imagine Gaussian, Inc. thinking this is a great idea.  The last thing
I want to read in the literature is how someone used G98 for their
calculations but they had to *massage* their source code to get the numbers
they wanted.

It just has bad things written all over it...

Ingenious solution though, you have definitely tracked down the culprit (the
rwf size) and determined a solution.  The scientific method prevails, but I
still feel it sets a dangerous precedence in regards to modifying commercial
grade source code.  We may know it is not the thing to do, but what happens
to person who searches the archives 5 months from now and finds your "bug
fix" solution?

Respectfully,

Phillip Matz

----- Original Message -----
From: "Nicolas Ferre" <[email-masked]>
To: "Roy Jensen" <[email-masked]>; "Xavier ASSFELD"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, April 05, 2001 5:12 AM
Subject: Re: CCL:symmetry change

---

From: Roy Jensen <[email-masked]>
Date: Thu, 5 Apr 2001 14:18:15 -0700 (PDT)

> This keyword fails when the symmetry is increased.
> When the symmetry is decreased, the keyword works fine.

It is interesting that IOP(2/16=2) (use old symmetry) almost works. It
completes 1 itteration before crashing with a FIOCOM error. There must be
some slight difference in the rwf file size, even though the symmetry
remains unchanged.

Regarding the modification of code.
I sent this problem to Gaussian weeks ago and have not had a response.
As long as Nicolas does not start selling ab initio software, he is not
violating the licensing agreement (I believe). Providing the fix to
Gaussian saves the programmers time and trouble. I will have to wait for
the next revision of G98W. Those using Unix can modify the source code,
recompile, and be on their way not having to worry about this 'feature'
again.

Thanks to everyone for the fruitful discussion on this topic.

Roy Jensen