dyevd diagonalization error on a MinGW build

[brhr-iwao]

Dear MOPAC Community,

I built a mopac-22.0.4 binary by using MinGW 6.3, cmake 3.13, GNU make 3.81, gfortran 4.6.2 and OpenBLAS-0.3.23 on Windows XP SP3.

Cmake and make completed successfully.

On test runs, all SCF jobs apparently fail with "dsyevd Diagonalization error., CODE=...".
For example, in the case of tests/keywords/PM6.mop,

PM6.mop

PM6
comment1
comment2
C  0.00 0.0 0.0
O  1.16 0.0 0.0
O -1.16 0.0 0.0

PM6.out

...
      RHF CALCULATION, NO. OF DOUBLY OCCUPIED LEVELS = 8


          Geometry optimization using EF
  dsyevd Diagonalization error., CODE =          11
  dsyevd Diagonalization error., CODE =          11
  dsyevd Diagonalization error., CODE =          11
  dsyevd Diagonalization error., CODE =          11
  dsyevd Diagonalization error., CODE =          11

          DIAGONAL MATRIX USED AS START HESSIAN

 CYCLE:     1 TIME:   0.201 TIME LEFT:  2.00D  GRAD.:999999.999 HEAT:           NaN
 NUMERICAL PROBLEMS IN BRACKETING LAMBDA   200.00000000042286       -1000000.0000000000        200.00000000022285                            NaN                       NaN
  GOING FOR FIXED STEP SIZE....
 NUMERICAL PROBLEMS IN BRACKETING LAMBDA   200.00000000042286       -1000000.0000000000        200.00000000022285                            NaN                       NaN
  GOING FOR FIXED LEVEL SHIFTED NR STEP...
  dsyevd Diagonalization error., CODE =          11
  dsyevd Diagonalization error., CODE =          11
  dsyevd Diagonalization error., CODE =          11
 CYCLE:     2 TIME:   0.125 TIME LEFT:  2.00D  GRAD.:999999.999 HEAT:           NaN
 EVERY DIAGONAL ELEMENTS ARE ZERO ?                 NaN                 NaN                 NaN
  dsyevd Diagonalization error., CODE =           8
 TOO MANY ITERATIONS IN LAMBDA BISECT                       NaN                       NaN                       NaN                       NaN

          TOO MANY ITERATIONS IN LAMBDA BISECT IN EF

 ******************************************************************************
 *                                                                            *
 *     Error and normal termination messages reported in this calculation     *
 *                                                                            *
 * TOO MANY ITERATIONS IN LAMBDA BISECT IN EF                                 *
 * JOB ENDED NORMALLY                                                         *
 *                                                                            *
 ******************************************************************************



 TOTAL JOB TIME:             0.42 SECONDS

 == MOPAC DONE ==

A simple program to check dsyevd functionality works normally.

test.f90

!      .. Parameters ..
      INTEGER          N 
      PARAMETER        ( N = 5 )
      INTEGER          LDA 
      PARAMETER        ( LDA = N )
      INTEGER          LWMAX
      PARAMETER        ( LWMAX = 1000 )
! 
!      .. Local Scalars ..
      INTEGER          INFO, LWORK, LIWORK
! 
!      .. Local Arrays ..
      INTEGER          IWORK( LWMAX )
      DOUBLE PRECISION A( LDA, N ), W( N ), WORK( LWMAX )
	  
      DATA             A/6.39, 0.00, 0.00, 0.00, 0.00, &
       & 0.13, 8.37, 0.00, 0.00, 0.00, &
       & -8.23,-4.46,-9.58, 0.00, 0.00, &
       & 5.71,-6.10,-9.25, 3.72, 0.00, &
       & -3.18, 7.21,-7.42, 8.54, 2.51/
	   

!      .. External Subroutines ..
      EXTERNAL         DSYEVD
      EXTERNAL         PRINT_MATRIX
! 
!      .. Intrinsic Functions ..
      INTRINSIC        INT, MIN
! 
!      .. Executable Statements ..
      WRITE(*,*)'DSYEVD Example Program Results'
! 
!      Query the optimal workspace.
! 
      LWORK = -1
      LIWORK = -1
      CALL DSYEVD( 'Vectors', 'Upper', N, A, LDA, W, WORK, LWORK, &
     &             IWORK, LIWORK, INFO )
      LWORK = MIN( LWMAX, INT( WORK( 1 ) ) )
      LIWORK = MIN( LWMAX, IWORK( 1 ) )
! 
!      Solve eigenproblem.
! 
      CALL DSYEVD( 'Vectors', 'Upper', N, A, LDA, W, WORK, LWORK, &
     &             IWORK, LIWORK, INFO )
! 
!      Check for convergence.
! 
      IF( INFO.GT.0 ) THEN
         WRITE(*,*)'The algorithm failed to compute eigenvalues.'
         STOP
      END IF
! 
!      Print eigenvalues.
! 
      CALL PRINT_MATRIX( 'Eigenvalues', 1, N, W, 1 )
! 
!      Print eigenvectors.
! 
      CALL PRINT_MATRIX( 'Eigenvectors (stored columnwise)', N, N, A, &
     &                   LDA )
      STOP
      END
! 
!      End of DSYEVD Example.
! 
!   =============================================================================
! 
!      Auxiliary routine: printing a matrix.
! 
      SUBROUTINE PRINT_MATRIX( DESC, M, N, A, LDA )
      CHARACTER* (*)    DESC
      INTEGER          M, N, LDA
      DOUBLE PRECISION A( LDA, *)
! 
      INTEGER          I, J
! 
      WRITE(*,*)
      WRITE(*,*) DESC
      DO I = 1, M
         WRITE(* ,9998) ( A( I, J ), J = 1, N )
      END DO
! 
 9998 FORMAT( 11(:,1X,F6.2) )
      RETURN
      END
	 

> gfortran test.f90 C:\...\MinGW\lib\libopenblas.a
> a

DSYEVD Example Program Results

 Eigenvalues
 -17.44 -11.96   6.72  14.25  19.84

 Eigenvectors (stored columnwise)
  -0.26   0.31  -0.74   0.33   0.42
  -0.17  -0.39  -0.38  -0.80   0.16
  -0.89   0.04   0.09   0.03  -0.45
  -0.29  -0.59   0.34   0.31   0.60
  -0.19   0.63   0.44  -0.38   0.48

>

Any ideas will be appreciated.

[godotalgorithm]

This does not appear to be a problem with LAPACK (dsyevd) itself, since it looks like NaN's are getting passed into dsyevd, and it is just flagging appropriate errors in response. MOPAC is producing NaN's in some intermediate step here for some reason.

I have briefly tinkered with building MOPAC on MinGW and MSYS 2 in the past and don't remember any problems other than an inability to combine Intel libraries (i.e. MKL) with GNU libraries in these environments. I can attempt to replicate this problem in a similar environment and get back to you about this.

Is there a reason that you aren't using the latest version of MOPAC? You are using CMake 3.13 here, and latest versions require 3.14, so I suspect that you are using the older version because of limitations in the version of CMake available to you?

Any other information that you provide could be helpful. Are you compiling in a Cygwin environment, in MSYS2, in WSL, or in some other Linux-like environment in Windows? Can you post a CMake log? This problem could depend on the environment, so I might not be able to replicate it without more information.

[brhr-iwao]

Thank you for your reply.

The reason why using cmake 3.13 is it is the latest cmake which supports Windows XP.
I'm using a Windows XP machine for some personal reason.

The output to the console during cmake is as follows:

C:\mopac-22.0.4\build>cmake -G"MinGW Makefiles" -D"CMAKE_MAKE_PROGRAM"=make.exe -D"CMAKE_Fortran_COMPILER"=gfortran.exe
..
-- The Fortran compiler identification is GNU 4.6.2
-- Check for working Fortran compiler: C:/MinGW/bin/gfortran.exe
-- Check for working Fortran compiler: C:/MinGW/bin/gfortran.exe  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether C:/MinGW/bin/gfortran.exe supports Fortran 90
-- Checking whether C:/MinGW/bin/gfortran.exe supports Fortran 90 -- yes
-- The C compiler identification is GNU 4.5.0
-- Check for working C compiler: C:/MinGW/bin/gcc.exe
-- Check for working C compiler: C:/MinGW/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Shared library and dynamic executables
-- Build type is Release
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - not found
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- Looking for Fortran sgemm
-- Looking for Fortran sgemm - found
-- Found BLAS: C:/MinGW/lib/libopenblas.a
-- Looking for Fortran cheev
-- Looking for Fortran cheev - found
-- A library with LAPACK API found.
-- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)
-- Found OpenMP_Fortran: -fopenmp (found version "3.0")
-- Could NOT find OpenMP (missing: OpenMP_C_FOUND) (found version "3.0")
-- Found Python: C:/Python27/python.exe (found version "2.7.14") found components:  Interpreter
-- Configuring done
-- Generating done
-- Build files have been written to: C:/mopac-22.0.4/build

C:\mopac-22.0.4\build>

I've never built mopac on Cygwin, MSYS2 or WSL.

Thank you in advance.

[godotalgorithm]

Got it, you are using MinGW from the DOS command prompt. I have always used MinGW tools from a Linux-like shell, but it seems like they were designed for use with any command-line interface on Windows. I will try to replicate this problem on the DOS command prompt of a Windows 10 machine with all of the software versions that you have listed. I don't have access to a Windows XP machine unless I use a virtual machine, and hopefully this problem is not sensitive to the Windows version.

[godotalgorithm]

Ok, I have an update. While the links above to the various software versions you are using were helpful, I was unable to get that version of gfortran working correctly from that distribution point. I ended up installing MinGW (with make and gfortran) from the MinGW installer at [https://osdn.net/projects/mingw/], which had much newer versions of everything. I compiled both OpenBLAS and MOPAC from a DOS command prompt using CMake 3.13 and your options, and everything seems to work fine.

Are you compiling OpenBLAS yourself, or are you using a pre-compiled version? If you are compiling it, are you using the default makefile or CMake?

Are you able to install these updated versions of MinGW tools on a Windows XP machine? I would recommend trying again using the latest version of MinGW, and if MOPAC still isn't working, then the issue must be related to Windows 10 vs. Windows XP. Once you've tried this on your end, I'll try to set up a Windows XP virtual machine and compile MOPAC on there if you are still having problems.

[brhr-iwao]

Sorry for providing inadequate/inaccurate information.

Gfortran 4.5.0 is not certainly included in the package.

I downloaded the following gfortran 4.5.0 lzmas from sourceforge and put the content dependencies to the MinGW directory manually.

• gcc-fortran-4.5.0_20100311-2-mingw32-bin.tar.lzma
• libgfortran-4.5.0_20100311-2-mingw32-dll-3.tar.lzma
• gcc-core-4.5.0_20100311-2-mingw32-bin.tar.lzma
• libgcc-4.5.0_20100311-2-mingw32-dll-1.tar.lzma

Additionally libgmp-10.dll、libmpc-2.dll and libmpfr-1.dll are required by libexec\gcc\i686-pc-mingw32\4.5.0\f951.exe.
They are contained the following packages:

• https://sourceforge.net/projects/mingw/files/MinGW/Base/gmp/gmp-5.0.1-1/libgmp-5.0.1-1-mingw32-dll-10.tar.lzma/download
• https://sourceforge.net/projects/mingw/files/MinGW/Base/mpc/mpc-0.8.1-1/libmpc-0.8.1-1-mingw32-dll-2.tar.lzma/download
• https://sourceforge.net/projects/mingw/files/MinGW/Base/mpfr/mpfr-2.4.1-1/libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma/download

This is a troublesome task. But I forgot because of rather previous work.

I had been splicing the dependencies by hand as usual.
As you pointed out, it is highly likely that something is broken due to incompatible dependencies.
I will try to rebuild the MinGW environment.

Thank you so much.

[godotalgorithm]

Ok, with these files, I am able to reproduce the compilation error that you reported observing with gfortran 4.5.0. That sequence of errors ends in an internal compiler error, which signifies a problem with the compiler rather than the program being compiled. This could either be a problem with the build environment, or a genuine bug in older versions of gfortran.

I am interested in MOPAC's portability, and this situation has me curious about MOPAC's ability to compile with older versions of gfortran, which is going to be the main compiler for the broadest possible accessibility (your situation being a good example). While I can't follow up on this immediately, I will go through a portability exercise of compiling MOPAC with successively older versions of gfortran and report on what range of versions MOPAC is able to compile on successfully. I'll update this thread and also the main README file with this information.

[brhr-iwao]

I've got it. The MinGW rebuild is not finished yet. I hope the information from me would be of some use.

[brhr-iwao]

Dear Dr. Moussa

I am happy to report that I was able to build mopac-22.0.4 on a standalone XP machine using the 32-bit version of MinGW which you taught.

The followings are an instruction-style description how I acutually did :

1. Install the latest MinGW on an offline XP machine

   1. Downlaod mingw-get-setup.exe from the osdn website and double-click it to launch "MinGW Installation Manager Setup Tool" on an online Windows PC which does not hove to be a XP machine.
      Follow the "MinGW Installation Manager Setup Tool" wizard to install "MinGW Installation Manager" (mingw-get.exe), which will be installed to C:\MinGW (where are changable) by default.
   2. Double-click C:\MinGW\bin\mingw-get.exe to launch the MinGW Installation Manager.
      Select "Basic Setup" in the left pane. Mark all packages in the upper-right pane for installtion.
      Select "Apply Changes" in the "Installation" menu to install the basic packages.
      The basic packages seem to include "make" and "gfortran".
   3. After the installation is completed, copy the C:\MinGW folder and its contents to an offline XP machine storage.
      Cmake must be installed to a XP machine separately from MinGW.
   4. Make sure that the environment variable PATH does not include something like C:\MinGW\bin and the environment variables don't include somthting like GCC_ROOT variable on the XP machine. If they remains, error such as "cannot execute cc1plus: CreateProcess: No such file or directory" may occure during gcc runs. Therefore I think that MinGW can be used only from msys (cannot be used from the command prompt) in acutual fact.

2. Build OpenBLAS

   1. Download and extract OpenBLAS-0.3.23 to somewhere like C:\MinGW\msys\1.0\home\username on the XP machine.
   2. Double-click C:\MinGW\msys\1.0\msys.bat to launch MSYS. Execute the following commands:

$ cd OpenBLAS-0.3.23
$ mkdir build
$ cd build
$ cmake -G"MSYS Makefiles" ..
$ make

If "make" completed successfully, copy build/lib/libopenblas.a to msys/1.0/lib.

3. Build mopac
   Download and Extract mopac-22.0.4 to somewhere like C:\MinGW\msys\1.0\home\username on the XP machine, just like in the case of OpenBLAS.
   Execute the following commands on the MSYS:

$ cd mopac-22.0.4
$ mkdir build
$ cd build
$ cmake -G"MSYS Makefiles" ..
$ make

The generated mopac.exe depends on libgcc_s_dw2-1.dll, libgfortran-5.dll, libquadmath-0.dll which are found in C:\MinGW\bin and the generated libmopac.dll.
The executable apparently works fine.

Thank you so much.