1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
The original copyright notice of MOPAC7:
C
C Notice of Public Domain nature of MOPAC
C
C 'This computer program is a work of the United States
C Government and as such is not subject to protection by
C copyright (17 U.S.C. # 105.) Any person who fraudulently
C places a copyright notice or does any other act contrary
C to the provisions of 17 U.S. Code 506(c) shall be subject
C to the penalties provided therein. This notice shall not
C be altered or removed from this software and is to be on
C all reproductions.'
C
Changes made to MOPAC7 code in this work may be used/distributed under the
same rules as the original MOPAC7 package; this work is in Public Domain.
Changes made by Tommi Hassinen, University of Kuopio, Finland, April 2001.
email <thassine@messi.uku.fi>
The MOPAC7 package used as a base for this work was obtained from
ftp://esca.atomki.hu/mopac7/LINUX/mopac-7.01-4.tar.gz
The objective of this work is to export the core functionality of MOPAC7 (the
energy/gradient calculation code + some graphics plotting code) to an external
program. The original fortran source is included, and some careful modifications
are done there. So far they are well-known bug fixes and some extensions, where
original mopac subroutines copied, renamed and modified. At some point later,
more rigorous modifications might be done; the current code is heavily dependent
on global variables and data, so you can't run multiple instances of MOPAC.
The list of modifications follows:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2001-04-18 : We will link miniMOPAC into a C++ program at Linux/UNIX.
Translate MOPAC7 into C using f2c package (version 19991025-1). Build it,
and it should work... Copy mopac.f -> minimopac.f, and for simplicity add
some comments. We will convert the original program into two subroutines,
which will either start or stop the MOPAC7. The idea is roughly following:
start-begin
call GETDAT
open unit 6 as usual...
call READMO
(skip the NATOMS check)...
(skip the keyword "AUTHOR")...
call GEOUT (by default!!!)
call MOLDAT
(skip the SOLVATION stuff)...
(skip the EXTERNAL stuff)...
start-end (ALLOW NO JUMPS OUTSIDE THIS BLOCK!!!)
stop-begin
(start from the label "40")
(skip the WRITMO stuff)...
(skip the POLAR stuff)...
(skip the ESP stuff)...
write times to unit 6
stop-end (ALLOW NO JUMPS OUTSIDE THIS BLOCK!!!)
2001-08-17 : Added a modification to calculate electrostatic potential (ESP)
plots. The original MOPAC contains a keyword "ESP" to fit atomic charges using
ESP. However, it did not work. Found a message at CCL where a patch to MOPAC
was included; other files than esp.f were already modified according to the
message. At esp.f, the /STO6G/ common block sizes were different from those
in the corresponding block at setupg.f; this was fixed. Now the plots are
calculated by setting the point data and then calling elesp_() which calculates
ESP. In elesp_() code, atom positions are first copied by calling a modified
pdgrid_(). I haven't yet checked what the unit of ESP is in mopac, but it seems
to be hartree; the plots look really nice when using the hartree->kJ/mol
conversion factor. The plot calculation process is a bit slow however; perhaps
some unnecessary results are also calculated? Those could be commented out...
2001-08-18 : The old ELESP subroutine is now divided in two parts; first will
initialize the plotting code, and the second will calculate the value. Speed
improvement is significant this way.
2001-09-03 : An idea about how to get rid of global variables: try to combine
all separate common blocks into a single big block. Then that could perhaps be
converted into a struct, and a pointer could be used to access it's elements?
Could the addition of pointer code be done as a search/replace operation???
2001-09-26 : Changes made to mopac.f and minimopac.f; we don't open unit 6
as a file anymore, and this will direct the output to console as text. This
also affected iter.f because unit 6 was also opened there (no idea why).
Also esp.f was slightly changed; unnecessary outputs/dumps were removed.
2001-09-27 : At iter.f, the STOP command at line 518 was removed, and failed
SCF convergence now doesn't close the whole program (this has been a problem
in MOPAC geometry optimizations). Instead of STOP, GOTO 380 is called like
in a case few lines above where the job is continued. THIS CHANGE MIGHT CAUSE
SOME PROBLEMS, BECAUSE WE WILL ACCEPT INACCURATE ENERGIES/FORCES AND WE WILL
FEED THEM TO GEOMETRY OPTIMIZATION AND OTHER ALGORITHMS!!! However, there
seems to be no negative side-effects in practice.
2002-01-31 : It turned out that I had modified etime.c file earlier by adding
#include <time.h> there (thanks Radek! :) The fortran/etime.c file is still
the original unmodified version.
How to build an independent MOPAC executable from fortran source:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
First, copy the contents of miniMOPAC/fortran directory somewhere, and change
to that directory. Then do the following:
f2c *.f
rm minimopac.c
gcc -c -O1 *.c
gcc -o MOPAC *.o -lf2c -lm
So, first we convert the fortran source to C, then compile and link it. The
MOPAC executable expects to find an input file with name FOR005.
How to update the miniMOPAC C source from fortran source:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It seems to be a good strategy to implement most changes and extensions in
fortran side, and then convert that to C. Some modifications in fortran side
will cause *big* changes in C side, for example changes in SIZES file or any
changes in fortran common blocks.
However, some changes are better to do in C side. For example, both MOPAC and
MPQC seems to use some BLAS routines, which have similar names, and therefore
you can't link them together. In the following, this kind of changes are
listed. If you update the C source from fortran, I guess you have to maintain
these changes manually...
ef.c : functions "daxpy", "dscal" and "dswap" conflicted with similar
ones in MPQC; seem to be BLAS routines? Renamed them with mM prefix...
etime.c : #include <time.h> has been added to this file.
EOF
|
