can set breakpoint

[Brian_Murphy]

I'm using visual studio.

I added a few lines of code to one of my fortran files, and rebuilt the entire solution (debug/win32), but visual studio won't let me set breakpoints on any of the new lines.  Where am I missing?  I did a clean of the solution, and then rebuilt, but this didn't help.

[mecej4]

A little bit of searching on the Web turned up the following links regarding bugs in Arpack, not all of which may have been fixed in the sources at Rice University (even after applying the patches provided there).

DLACPY aliasing bug:
  https://software.intel.com/en-us/articles/how-to-resolve-arpack-issues-with-intel-mkl-110-update-3
A number of fixes:
  https://github.com/opencollab/arpack-ng/tree/master/SRC
  https://mathema.tician.de/software/arpack/
A bug that can be a problem:
  https://mathema.tician.de/arpack-lapack-symbol-duplication/

I obtained the corrected sources at https://github.com/opencollab/arpack-ng/tree/master/SRC, and ran it with the modified source in pararp.zip (#20), with the following changes:

      ncv = min(nx,nev+nev+nev/2)
      ncv = ncv - mod(ncv,2)
      print *,'ncv=',ncv
      ALLOCATE ( d(nx,3), v(nx,ncv))

The program ran without any array bounds errors, and displayed ncv = 14, which is the case that gave you problems. It also ran fine with ncv = 16 and gave essentially the same results.

I have yet to compare the Rice sources with the Arpack-NG sources and use the results of the comparison to see what changes are needed for the Fortran-90 version at http://people.sc.fsu.edu/~jburkardt/f_src/arpack/arpack.html .

[Brian_Murphy]

You're amazing, mecej4.

I can't figure out how to download source code from https://github.com/opencollab/arpack-ng/tree/master/SRC

Is there some trick, or does it require doing routines one at a time?

I'm surprised to see that the ng site's file for dnaupd.f indicates that argument NEV is (INPUT).  The file in the 08/23/2002 patch says it is (INPUT/OUTPUT).  It's been my experience that nev does sometimes get modified during the call.  When it happens, I think it always gets increased by 2.  This doesn't happen all the time, only sometimes.  The original 1996 version of this file says (INPUT).

[mecej4]

To download the files in a group, go to https://github.com/opencollab/arpack-ng . You should see a green button "Clone or Download"; if you click on it, one of the choices is "Download Zip". That will get you all the files.

There are similar problems (changing constants by passing them to subroutines, etc) in much old software. We have to contend with such bugs, squashing those that we find...

[Brian_Murphy]

Thanks again, mecej4.  Sometime I can't see the forest through the trees.  I have downloaded the zip, and I'll be working on swapping out the codes.

What do you think the Florida State web site has to offer that NG does not?  I noticed the FSU source is reformatted to F90 flavor for comments and continuations, but it's only for single precision.

[mecej4]

Brian Murphy wrote:

What do you think the Florida State web site has to offer that NG does not?  I noticed the FSU source is reformatted to F90 flavor for comments and continuations, but it's only for single precision.

In this case, not much. In many other cases, I have found that site useful for its sample input data and output  results.

Probably, the main fix that you need from the NG distribution is the following: In Subroutine DNAUP2, find the second call to DNGETS. Just  before the statement "np = kplusp - nev", insert "nev = min(nev, kplusp-2) ", which is what they call the "Scipy Fix".

[Brian_Murphy]

When I try to build with the NG code, the new version of second.f has the word EXTERNAL replaced with INTRINSIC in the declaration for ETIME.  Either Intel Fortran or Visual Studio doesn't like this.  My Fortran95 book doesn't list ETIME anywhere.

Error 6  error #6407: This symbolic name is not an intrinsic function name or an intrinsic subroutine name.   [ETIME] C:\Users\Brian\Documents\Visual Studio 2010\Projects\Xlrotor\ARPACK\UTIL\second.f 24 

I changed it to EXTERNAL, and then I could build.  Running my test case no longer triggers the out of bounds error.  Yahoo!

[Steven_L_Intel1]

ETIME is not an intrinsic in standard Fortran. 

[mecej4]

You can replace all references to ARSCND by CPU_TIME, or use the following wrapper:

      subroutine arscnd(T)
      real T
      call cpu_time(t)
      return
      end

Intel Fortran does provide ETIME as a non-standard portability function, but it is not an intrinsic.

[Brian_Murphy]

I have been building my arpack project with a LAPACK code which is Version 2.0 September 30, 1994.  I also use a BLAS code from about the same era.  If I remove LAPACK and BLAS components from the visual studio project, the project still builds ok.  Does that mean Intel Fortran is supplying these routines?  However, instead of computing eigenvalues, arpack's dnaupd returns -8 which means some sort of LAPACK error.  When I add my old LAPACK back to the project (but not BLAS), it once again runs ok.

mecej4 - what vintage of LAPACK were you using when you ran my stripped down code?

[Brian_Murphy]

Here's an update.

1. I returned to the 1994 versions of arpack SRC and UTIL.
2. Actually, UTIL is all 1995, but SRC includes patches from 2002.
3. I inserted the "Scipy fix" into SRC/dnaup2.f
4. I removed the old LAPACK and BLAS library builds from my Vstudio project.
5. The stripped down test project builds and runs good! :)
6. I built my full blown application the same way, and it runs good! :)^2

I will accept this as my current solution.  Updating to the newer arpack-ng would be nice, but my attempts to use it ran into problems I don't want to tackle right now.

Many thanks to you, mecej4, for guiding me through this.  I would have never gotten there without your help.

[mecej4]

Brian Murphy wrote:

mecej4 - what vintage of LAPACK were you using when you ran my stripped down code?

All the BLAS/Lapack routines that your test code and Arpack need are in MKL. In all my runs, I used MKL. The current version of MKL matches Lapack 3.6. (See https://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-2017-release-notes) .

Since you already use MKL/Pardiso, you should be able to build by just leaving out your non-MKL Lapack and BLAS libraries from the link step.

I think that the Lapack error (-8) that you encountered may be related to the calls to DLACPY with aliased arguments that are documented in the NG-sources. This bug affects routines DSAPPS and DNAPPS, and the fix is to replace the call by an equivalent set of calls to DCOPY, or to use a lower level of optimization when compiling the source files of the routines affected.

[Brian_Murphy]

I guess I'm lucky my code runs with the older arpack plus scipy fix.  Because it doesn't run with newer arpack-ng.  The part I don't understand is why you can run this case and I can't.

I also tried adding to the project dlacpy.f from the old lapack that came with the original arpack, but still got -8. 

[mecej4]

Here is a Zip of the NG-Arpack routines needed, my modified version of your driver and your data files. To build, unpack the Zip, build using the command line

     ifort /MP /check:bounds *.f mkl_rt.lib /Fepardiso

and run the resulting Pardiso.exe in the same directory. You should see the three pairs of eigenvalues printed out.

[Brian_Murphy]

I don't have my computer configured to build from a command line, so I made a visual studio project.  The compile command line is:

/nologo /debug:full /Od /stand:f90 /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /Qmkl:sequential /c

The linker command line is:

/OUT:"Debug\pardiso.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\pardiso\Debug\pardiso.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\pardiso\Debug\pardiso.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\pardiso\Debug\pardiso.lib"

It builds and runs, but dnaupd still returns -8.  Could the /Qmkl:sequential  be causing this?  The version of Intel Fortran I have installed is:

Intel® C++ Composer XE 2013 Update 5 Integration for Microsoft* Visual Studio* 2010, Version 13.0.1211.2010, Copyright © 2002-2013 Intel Corporation. All rights reserved.

[andrew_4619]

On the start menu under the Intel folder there are options to on a cmd window for 32 or 64 bit compilation.

Run one of those browse to the source folder and run  ifort /MP /check:bounds *.f mkl_rt.lib /Fepardiso as advised. It worked for me.

[Brian_Murphy]

Thanks for the tip.  It built the exe and I could run it.  But dnaupd still generated a -8 error.  This happens after 14 iterations.

= -8: Error return from LAPACK eigenvalue calculation

Does that mean my version of MKL must be the problem?

[andrew_4619]

I know next to nothing about MKL but  given I followed mecej4's instructions from #34 and it all worked then logic suggests that:

*If* you followed #34 and #36 then:

1) Your compiler level is different (older) and my have some  problem

2) Your MKL  level is different and may have some problem

3) You may have other issues with window and/or the hardware.

My first suggestion is in the Intel command prompt do "SET > env.txt" and then open env.txt. You should find MKL entries under INCLUDE, LIB, MKLROOT and PATH. Is there more than one MKL listed? What MKLs are listed? I would expect are looking for some mish mash problem of version inconsistency.

[mecej4]

Andrew's hunch 2) is on the mark. If I use Intel Fortran 11.1.070, the EXE fails with an error in MKL_DCSRCOO. His work in verifying the runs is helpful.

The EXE produced by the 64-bit version of Intel Fortran 14.0.4.237 fails with the -8 error code from DNAUPD, but the 32-bit version is able to run to completion. I believe that the responsible bugs are in MKL rather than the compiler. I remember that there were some errors/deficiencies in MKL_DCSRCOO that were fixed a couple of years ago. 

The oldest release of Intel Fortran among those that I still have that leads to successful runs is 15.0.7.

Brian Murphy: Is it feasible for you to move to the current or a more recent version than 14.0.4 ?

[Brian_Murphy]

I tried to upgrade, but my subscription has expired.  Do you know if an upgrade to today's Composer XE includes visual studio?  I presently have visual studio 2010, but I doubt today's Composer XE will work with it.

[andrew_4619]

Yes thay all have a VS Shell option you might also we able to use VS community ( a full VS) if you meet the licence conditions.

[Brian_Murphy]

I will ask my project sponsor to get me the upgraded to the latest Composer XE. 

I just read some online info about Visual Studio, and there are so many variations that it's beyond my ability (or patience) to make sense of it.