topic LSAME is a Lapack routine -- in Intel® Fortran Compiler

IMSL and going from visual studio 2012 to 2010

Brian_Murphy — Mon, 07 Mar 2016 21:49:53 GMT

I have ported a working project from one computer with visual studio 2012 to another with visual studio 2010, and I'm getting a strange error from a routine named LSAME during an IMSL operation that is computing a matrix solution using overloaded operators and Harwell sparse matrices. It looks like RESULT = A .ix. RHS. I think the problem is in the porting, not the program. Is there anything I should have done while porting to make it work?

I think the VS2012 system has visual fortran composer XE 2013 update 5, and the VS2010 system has update 4. Could that be my problem?

Crystal ball out for repairs.

Steven_L_Intel1 — Mon, 07 Mar 2016 21:58:06 GMT

Crystal ball out for repairs. Please elaborate on what the "strange error" is. Also, do you have the same version of IMSL installed on both computers?

Sorry about that, Steve. I

Brian_Murphy — Mon, 07 Mar 2016 22:15:24 GMT

Sorry about that, Steve. I was hoping there was something really obvious I failed to do. Here's the error message. This happens on the statement that does the matrix solution. There is no character variable being passed by me on that statement.

forrtl: severe (408): fort: (18): Dummy character variable 'CA' has length 1 which is greater than actual variable length 0

I don't know how to find the IMSL version. I found a file named imslsupport.txt in the FNL folder for both systems that says w_fcompxe_imsl_2013.0.002

I have a file named w_fcompxe_novsshell_2013.6.204.exe that I could apply to the VS2010 system, but I don't have an IMSL file to go with it, or is IMSL is built into it?

I tried to install the Update

Brian_Murphy — Mon, 07 Mar 2016 22:58:16 GMT

I tried to install the Update 6 file, and I got a message saying I couldn't install it. I think because my subscription has expired.

You have the correct IMSL

Steven_L_Intel1 — Mon, 07 Mar 2016 23:28:12 GMT

You have the correct IMSL version. The IMSL installer is separate.

It simply looks as if the older compiler had a bug fixed in the newer one. I remember seeing a bug with a symptom like that a while ago. Perhaps if you turn off array bounds checking you can continue.

I have managed to install

Brian_Murphy — Mon, 07 Mar 2016 23:59:11 GMT

I have managed to install Update 5 onto the system with Update 4. But this seems to have broken IMSL, so I will try to reinstall IMSL. Now where did I put that darned thing?

Brian

I reinstalled IMSL, and that

Brian_Murphy — Tue, 08 Mar 2016 00:39:17 GMT

I reinstalled IMSL, and that didn't help.

error #5102: Cannot open include file 'link_fnl_static.h'
error #7002: Error in opening the compiled module file. Check INCLUDE paths.

It doesn't make any sense that installing update 5 would mess this up, as well as reinstalling IMSL didn't fix it. There must be something really screwed up. Where do I "check include paths". I've been looking, but I can't find this.

Read https://software.intel

Steven_L_Intel1 — Tue, 08 Mar 2016 00:45:00 GMT

Read https://software.intel.com/en-us/articles/installing-and-using-the-imsl-libraries/

Thanks again, Steve. It was

Brian_Murphy — Tue, 08 Mar 2016 00:56:20 GMT

Thanks again, Steve. It was Tools/Options/Intel Composer XE/Visual Fortran/Compilers/ etc...........

It now builds and runs, but I'm still getting exactly the same error at exactly the same place. Darn.

The only error that appears during building is this:

Error 3 general error c101008d: Failed to write the updated manifest to the resource of file "C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\DLLUserTor\DLLUserTor\Debug\DLLUserTor.dll". The parameter is incorrect. mt.exe

A new file DLLUserTor.dll did get created during the build. I get feeling this isn't important. Or is it?

Later tonight I will double check the arrays being passed to the .ix. operation. I think I'm running a case that ran fine on the other system, but I will make sure about that.

The mt.exe error may or may

Steven_L_Intel1 — Tue, 08 Mar 2016 02:01:26 GMT

The mt.exe error may or may not be important, but it is odd. I have seen a variation where it complains that the EXE is open by another user, but the "parameter is incorrect" suggests a syntax error on the command line used to run mt, and that should be generated automatically. Can you attach a ZIP of the buildlog.htm?

You're getting that 408 character length error? Is there a traceback?

The buildlog is attached.

Brian_Murphy — Tue, 08 Mar 2016 02:36:32 GMT

The buildlog is attached.

The following is what appears in the console window:

forrtl: severe (408): fort: (18): Dummy character variable 'CA' has length 1 whi
ch is greater than actual variable length 0

Image              PC        Routine            Line        Source
libifcoremdd.dll   003E1A70 Unknown               Unknown Unknown
libifcoremdd.dll   003CDB26 Unknown               Unknown Unknown
libifcoremdd.dll   0034EF12 Unknown               Unknown Unknown
libifcoremdd.dll   0034F683 Unknown               Unknown Unknown
XLTRC2.exe         017564C6 _LSAME                     37 lsame.f
XLTRC2.exe         01A5104F Unknown               Unknown Unknown
XLTRC2.exe         01A49ACB Unknown               Unknown Unknown
XLTRC2.exe         0192F5BB Unknown               Unknown Unknown
XLTRC2.exe         01859F6B Unknown               Unknown Unknown
XLTRC2.exe         0146B8DE _DNSIMP                   238 Arnoldi.f90
XLTRC2.exe         0146B8DE _DNSIMP                   238 Arnoldi.f90
XLTRC2.exe         01468035 _ARNOLDI_EIGS              60 Arnoldi.f90
XLTRC2.exe         00FC9E9F _GET_TRANSFORM_T3         260 Transf.f90
XLTRC2.exe         0161E5DF _REDUCE_MATRIX             20 ReduceMat.f90
XLTRC2.exe         01C201D3 Unknown               Unknown Unknown
XLTRC2.exe         01799DAF Unknown               Unknown Unknown
XLTRC2.exe         01799BDF Unknown               Unknown Unknown
kernel32.dll       76563677 Unknown               Unknown Unknown
ntdll.dll          77499D72 Unknown               Unknown Unknown
ntdll.dll          77499D45 Unknown               Unknown Unknown

Could it be that this problem

Brian_Murphy — Tue, 08 Mar 2016 14:51:54 GMT

Could it be that this problem is happening because I tried to use the visual studio 2012 .sln file in visual studio 2010?

It's a big project made by others over many years. If I were to recreate it from scratch in vs 2010, is there some recipe for doing that?

No, this has absolutely

Steven_L_Intel1 — Tue, 08 Mar 2016 15:16:13 GMT

No, this has absolutely nothing to do with your Visual Studio version.

The build log you attached shows only the link step - I wanted to see the compile.

What is LSAME? Is that one of your routines? Is it a callback you pass to IMSL? Who calls it? The error is coming from LSAME, complaining about how it was called.

LSAME is a Lapack routine --

mecej4 — Tue, 08 Mar 2016 15:25:00 GMT

LSAME is a Lapack routine -- see, e.g., http://www.netlib.org/lapack/explore-3.1.1-html/lsame.f.html . It takes two character arguments S1 and S2 of any length, and in essence returns .TRUE. if the first characters of S1 and S2 match, case ignored.

An easy fix would be to use the LSAME function available in MKL, instead of using a source version of LSAME with uncertain pedigree. See https://software.intel.com/en-us/node/522127 .

Ok - I see that LSAME takes a

Steven_L_Intel1 — Tue, 08 Mar 2016 15:50:36 GMT

Ok - I see that LSAME takes a CHARACTER*1 argument. Perhaps you're calling it incorrectly (such as not passing it a character.) IMSL is not involved.

I do not call LSAME anywhere

Brian_Murphy — Tue, 08 Mar 2016 16:07:34 GMT

I do not call LSAME anywhere in my code. Line 238 in Arnoldi.f90 is the statement with the overloaded operator.

However, this project also includes LAPACK source code. That came along with ARPACK when ARPACK was added to the project. But this project runs on the computer with visual studio 2012.

The ARPACK code does call LSAME in hundreds of places. I don't know what LSAME looks like in IMSL or MKL, but the one that came with ARPACK starts with this: Maybe somehow the project as compiled with vs2010 is doing things differently than when compiled with vs2012.

      LOGICAL          FUNCTION LSAME( CA, CB )
*
*  -- LAPACK auxiliary routine (version 2.0) --
*     Univ. of Tennessee, Univ. of California Berkeley, NAG Ltd.,
*     Courant Institute, Argonne National Lab, and Rice University
*     September 30, 1994
*
*     .. Scalar Arguments ..
      CHARACTER          CA, CB

By the way. I double checked that I'm running the code with a valid reproducible case.

Where did you get the LAPACK

Steven_L_Intel1 — Tue, 08 Mar 2016 16:18:48 GMT

Where did you get the LAPACK library. Did you build it yourself? The traceback shows a bunch of intermediate calls without traceback info. LSAME was compiled with /check:bounds. Maybe there's a bug in the compiler used to compile it, or maybe there's a bug in the call.

Another weird thing started

Brian_Murphy — Tue, 08 Mar 2016 16:25:07 GMT

Another weird thing started happening about the same time I did the intel fortran update. I have a breakpoint set at line 238 with the overloaded operator. Before, trying to step past that line would immediately trigger the LSAME error. Now, however, I also get prompted that there is no disk in the CD drive. Well, that was yesterday. Today I'm not getting that prompt, but I still get the LSAME error.

Boy, is this fun.

LAPACK came with ARPACK.

Brian_Murphy — Tue, 08 Mar 2016 16:34:31 GMT

LAPACK came with ARPACK.

I set a breakpoint on line 37 in my source code for LSAME, and execution did go there from the line 238. Right before the error happens at line 37, the call stack shows this:

> XLTRC2.exe!LSAME( , CHARACTER(1)  CA, CHARACTER(1)  CB,  .tmp..T5__V$7)  Line 37 Fortran
  XLTRC2.exe!_dgscon()  + 0x6f bytes C
  XLTRC2.exe!_c_fortran_dgssv()  + 0x76b bytes C
  XLTRC2.exe!_D_F95_COND()  + 0x5d9 bytes 
  XLTRC2.exe!_SPARSE_LINEAR_OPERATORS_mp_D_HBC_SPARSE_SOLVE_VECTOR.()  + 0x131f bytes 
  XLTRC2.exe!DNSIMP( , REAL(8)  D, REAL(8)  V, REAL(8)  RESID, INTEGER(4)  NX, INTEGER(4)  NEV, INTEGER(4)  NCV, INTEGER(4)  IERR, LOGICAL(4)  RVEC, TYPE(D_HBC_SPARSE)  A, TYPE(D_HBC_SPARSE)  M)  Line 238 + 0x432 bytes Fortran

I went back to my old

Brian_Murphy — Tue, 08 Mar 2016 17:01:43 GMT

I went back to my old computer with vs2012 and set a breakpoint on that same line in LSAME, and the code ran fine from start to finish without ever stopping there.

Does this mean the codes are getting built differently?