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. 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 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?
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 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?
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.
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 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.
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 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 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 -- 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 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 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 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 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.
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 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?