How to compile Mopac 7.1 using g77 or gfortran
in [Fortran]
|
From: Steven G. Kargl on 2 Oct 2008 00:41 In article <RPednVKmv_wI03nVnZ2dnUVZ_r3inZ2d(a)comcast.com>, kargl(a)REMOVE.apl.washington.edu (Steven G. Kargl) writes: > In article <QOOdnUfwHYcd0HnVnZ2dnUVZ_o_inZ2d(a)comcast.com>, > kargl(a)REMOVE.apl.washington.edu (Steven G. Kargl) writes: >> In article <bb182196-3796-4281-b193-3ec40df1bf2e(a)y21g2000hsf.googlegroups.com>, >> "Jinsong.Zhao(a)gmail.com" <Jinsong.Zhao(a)gmail.com> writes: >>> On Oct 2, 12:52�am, Tobias Burnus <bur...(a)net-b.de> wrote: >>>> >>>> I sincerely doubt this. (Not that compiler bugs don't exist, but >>>> programming errors are much more likely.) Looking at the valgrind >>>> output (using gfortran) and at ifort -check all, I would claim that >>>> >>>> � � � if (mode == 1) then >>>> � � � � ... >>>> � � � else >>>> � � � � allocate(c(norbs, norbs), wj(1), wk(1), eigs(norbs), >>>> dxyz(3*numat), grad(nvar)) >>>> � � � � ... >>>> � � � end if >>>> � � � grad = 0.d0 �! <<< Line 47 >>>> >>>> is wrong if grad is not allocated (as valgrind & ifort -check all >>>> indicate). Moving up "grad" one line or allocating it for mode == 1 >>>> helps. (No, I'm not reading the whole program to check what is the >>>> algorithmically correct solution.) >>>> >>>> Tobias >>> Thank you, Tobias, for your test. >>> if grad = 0.d0 is moved up one line, then grad will not be execute >>> using the above input file, and will give error results. >>> if grad = 0.d0 is put before if (mode == 1) (line 12), then also >>> segmentation fault. it is same to be placed at line. >> >> grad isn't allocated. For your input file, it appears you've located >> a bug in mopac >> >> REMOVE:kargl[381] ./mopac sgk.dat >> STOP grad not allocated! >> REMOVE:kargl[382] diff -u setup_mopac_arrays.F90.orig setup_mopac_arrays.F90 >> --- setup_mopac_arrays.F90.orig 2008-10-01 21:08:55.000000000 -0700 >> +++ setup_mopac_arrays.F90 2008-10-01 21:10:03.000000000 -0700 >> @@ -44,6 +44,11 @@ >> allocate(fb(mpack), cb(norbs, norbs), pbold(6*mpack), pbold2(6*mpack), & >> & pbold3(max(mpack, 400))) >> end if >> + >> + if (.not. allocated(grad)) then >> + stop 'grad not allocated!' >> + end if >> + >> grad = 0.d0 >> else >> ! > > Ugh! > > A a crappy piece of software! After fixing > > REMOVE:kargl[413] diff -u deriv.F90.orig deriv.F90 > --- deriv.F90.orig 2008-10-01 21:27:45.000000000 -0700 > +++ deriv.F90 2008-10-01 21:27:43.000000000 -0700 > @@ -69,6 +69,9 @@ > !*********************************************************************** > data icalcn/ 0/ > if (icalcn /= numcal) then > + if (.not. allocated(aidref)) then > + allocate(aidref(nvar)) > + end if > aidref = 0.d0 > aifrst = index(keywrd,' RESTART') == 0 > saddle = index(keywrd, " SADDLE") /= 0 > > you hit > REMOVE:kargl[412] ./mopac sgk.dat > At line 109 of file cartab.F90 > Fortran runtime error: Array reference out of bounds for array 'nallop', > lower bound of dimension 1 exceeded (-1077948016 < 1) > Yeah, it's a monologue! This is definitely poorly written software. You need to add the -fno-automatic command line option to get something that will run. You're also going to need to investigate other assumptions in the software. With your input, the last few lines of the output file are EXCESS NUMBER OF OPTIMIZATION CYCLES CURRENT VALUE OF GRADIENT NORM = NaN CURRENT VALUE OF GEOMETRY AM1 T=600 NOINTER VECTORS LOCAL EF EXAMPLE OF MOPAC DATA-SET FOR ETHYLENE The only geometric constraint is that the system must be planar C 0.00000000 0 0.0000000 0 0.0000000 0 0 0 0 4.0000 C NaN 1 0.0000000 0 0.0000000 0 1 0 0 4.0000 H NaN 1 NaN 1 0.0000000 0 2 1 0 1.0000 H NaN 1 NaN 1 0.0000000 0 1 2 3 1.0000 H NaN 1 NaN 1 180.0000000 0 1 2 3 1.0000 H NaN 1 NaN 1 0.0000000 0 2 1 5 1.0000 TOTAL CPU TIME: 7.53 SECONDS == MOPAC DONE == I suspect the NaN are not what you want. This suggest that the software assumes certain values are initialized to 0 at start up. -- steve
From: Jinsong.Zhao on 2 Oct 2008 01:52 On Oct 2, 12:26 pm, ka...(a)REMOVE.apl.washington.edu (Steven G. Kargl) wrote: > In article <bb182196-3796-4281-b193-3ec40df1b...(a)y21g2000hsf.googlegroups..com>, > "Jinsong.Z...(a)gmail.com" <Jinsong.Z...(a)gmail.com> writes: > > > > > On Oct 2, 12:52 am, Tobias Burnus <bur...(a)net-b.de> wrote: > > >> I sincerely doubt this. (Not that compiler bugs don't exist, but > >> programming errors are much more likely.) Looking at the valgrind > >> output (using gfortran) and at ifort -check all, I would claim that > > >> if (mode == 1) then > >> ... > >> else > >> allocate(c(norbs, norbs), wj(1), wk(1), eigs(norbs), > >> dxyz(3*numat), grad(nvar)) > >> ... > >> end if > >> grad = 0.d0 ! <<< Line 47 > > >> is wrong if grad is not allocated (as valgrind & ifort -check all > >> indicate). Moving up "grad" one line or allocating it for mode == 1 > >> helps. (No, I'm not reading the whole program to check what is the > >> algorithmically correct solution.) > > >> Tobias > > Thank you, Tobias, for your test. > > if grad = 0.d0 is moved up one line, then grad will not be execute > > using the above input file, and will give error results. > > if grad = 0.d0 is put before if (mode == 1) (line 12), then also > > segmentation fault. it is same to be placed at line. > > grad isn't allocated. For your input file, it appears you've located > a bug in mopac > > REMOVE:kargl[381] ./mopac sgk.dat > STOP grad not allocated! > REMOVE:kargl[382] diff -u setup_mopac_arrays.F90.orig setup_mopac_arrays.F90 > --- setup_mopac_arrays.F90.orig 2008-10-01 21:08:55.000000000 -0700 > +++ setup_mopac_arrays.F90 2008-10-01 21:10:03.000000000 -0700 > @@ -44,6 +44,11 @@ > allocate(fb(mpack), cb(norbs, norbs), pbold(6*mpack), pbold2(6*mpack), & > & pbold3(max(mpack, 400))) > end if > + > + if (.not. allocated(grad)) then > + stop 'grad not allocated!' > + end if > + > grad = 0.d0 > else > ! after add those lines, my MOPAC dose not segmentation fault, but give STOP grad not allocated, and stopped. what's version of your gfortran? I am now on a remote Linux workstation, and I can not install a newer gfortran. Thanks again for your effort on this program. Regards, Jinsong
From: Richard Maine on 2 Oct 2008 02:56 Jinsong.Zhao(a)gmail.com <Jinsong.Zhao(a)gmail.com> wrote: > On Oct 2, 12:26 pm, ka...(a)REMOVE.apl.washington.edu (Steven G. Kargl) > wrote: > > grad isn't allocated. For your input file, it appears you've located > > a bug in mopac .... > after add those lines, my MOPAC dose not segmentation fault, but give > STOP grad not allocated, and stopped. > > what's version of your gfortran? I am now on a remote Linux > workstation, and I can not install a newer gfortran. You seem to be fixated on the possibility of compiler problems. While I haven't taken the time to investigate myself (obviously not nearly as much as Steve has), nothing I have heard in this thread has suggested any significant likelihood of compiler problems being the issue here. The problem(s) Steve pointed out are problems in the code - not the compiler. Changing the compiler version isn't going to fix them. The lines that Steve added just diagnose the problem; yes he told it to stop with that message if the particular problem was detected. Not that compiler errors can't happen. They do. And gFortran has allegedly matured a lot in the relatively recent past (I say "allegedly" just because I haven't tried it recently myself) and thus it seems that a common for the solution to gFortran problems is to install a newer version. But I just don't see any evidence that this is a compiler problem in the first place. I will take the opportunity to point out that this appears to be yet another example of the phenomenon I mentioned in another thread not too long ago - that I often see novice programmers suspecting compiler errors when the actual errors are in the code. In this case, I'm aware that it isn't your code, making it a slightly different phenomenon, but a related one. Alas, I'm afraid that I'm not inclinded to put in the amount of work needed to debug a code of this size with the number of problems that Steve has found (and possibly others that he didn't yet uncover.) That's too much like real work. So no, I don't have much in the way of constructive suggestions. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: Dr Ivan D. Reid on 2 Oct 2008 03:18 On Wed, 01 Oct 2008 23:31:17 -0500, Steven G. Kargl <kargl(a)REMOVE.apl.washington.edu> wrote in <RPednVKmv_wI03nVnZ2dnUVZ_r3inZ2d(a)comcast.com>: > REMOVE:kargl[413] diff -u deriv.F90.orig deriv.F90 > --- deriv.F90.orig 2008-10-01 21:27:45.000000000 -0700 > +++ deriv.F90 2008-10-01 21:27:43.000000000 -0700 > @@ -69,6 +69,9 @@ > !*********************************************************************** > data icalcn/ 0/ > if (icalcn /= numcal) then > + if (.not. allocated(aidref)) then > + allocate(aidref(nvar)) > + end if > aidref = 0.d0 > aifrst = index(keywrd,' RESTART') == 0 > saddle = index(keywrd, " SADDLE") /= 0 > you hit > REMOVE:kargl[412] ./mopac sgk.dat > At line 109 of file cartab.F90 > Fortran runtime error: Array reference out of bounds for array 'nallop', > lower bound of dimension 1 exceeded (-1077948016 < 1) There was a problem with bounds checking with MOPAC 6, since it used the old "convention" of specifying argument arrays of unknown length in subroutines with size 1 -- this has probably carried over into the later version. (Looking through my source, I see that I must have replaced all of these declarations with a * at some point; I definitely remember being bitten by it.) -- Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration, Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN KotPT -- "for stupidity above and beyond the call of duty".
From: glen herrmannsfeldt on 2 Oct 2008 04:47
Richard Maine wrote: (snip) > You seem to be fixated on the possibility of compiler problems. While I > haven't taken the time to investigate myself (obviously not nearly as > much as Steve has), nothing I have heard in this thread has suggested > any significant likelihood of compiler problems being the issue here. > The problem(s) Steve pointed out are problems in the code - not the > compiler. Changing the compiler version isn't going to fix them. The > lines that Steve added just diagnose the problem; yes he told it to stop > with that message if the particular problem was detected. In the case of beginning programmers writing their own programs, it would seem likely that problems are in the program and not the compiler. When using a program that supposedly has already been well debugged and tested, it is even easier to blame the compiler. It seems, though, that this program hasn't been as well tested as one might expect. -- glen |