- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The DGGEV routine works fine if noeigenvectors required, howeverwhen I request the left or righteigenvectors to be computed, the errors come up for any ALLOCATE orDEALLOCATE in the nextcommands. Such as:
"Windows has triggered a breakpoint in DGGEV.exe.
This may be due to a corruption of the heap, which indicates a bug in DGGEV.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while DGGEV.exe has focus.
The output window may have more diagnostic information."
If I press continue, another error message comes up:
"Unhandled exception at 0x77b635e3 in DGGEV.exe: 0xC0000374: A heap has been corrupted"
Message at call stack window: [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]ntdll.dll!77b635e3()
Attached is the sample code. Anyone know solution for this please advise.
System: Windows 7, MVS2010,Composer XE 2011 SP1
[bash] INCLUDE 'link_fnl_static.h' !DEC$ OBJCOMMENT LIB:'libiomp5md.lib' USE IMSL_LIBRARIES USE MKL95_LAPACK IMPLICIT NONE INTEGER N, LWORK, INFO PARAMETER (N=4) ! DOUBLE PRECISION A(N,N), B(N,N), WORK_TMP(N), ALPHAR(N), ALPHAI(N), BETAR(N), VCL(N,N), VCR(N,N), EVAL(N) INTEGER, ALLOCATABLE, DIMENSION(:) :: WORKR, TEST ! ! Define values of A and B: ! A = ( 0.24 0.39 0.42 0 ) ! ( 0.39 -0.11 0.39 0.63 ) ! ( 0.42 0.39 -0.25 0.48 ) ! ( 0 0.63 0.48 -0.03 ) ! ! B = ( 2.07 0.95 0 0 ) ! ( 0.95 1.69 -0.29 0 ) ! ( 0 -0.29 0.65 -0.33 ) ! ( 0 0 -0.33 1.17 ) ! ! Declare variables DATA A/0.240D0,0.390D0,0.420D0,00D0, 0.390D0,-0.110D0,0.390D0,0.630D0, 0.420D0,0.390D0,-0.250D0,0.480D0, 00D0,0.630D0,0.480D0,-0.030D0/ DATA B/2.070D0,0.950D0,00D0,00D0, 0.950D0,1.690D0,-0.290D0,00D0, 00D0,-0.290D0,0.650D0,-0.330D0, 00D0,00D0,-0.330D0,1.170D0/ ! Compute eigenvalues CALL DGGEV("N", "N", N, A, N, B, N, ALPHAR, ALPHAI, BETAR, VCL, N, VCR, N, WORK_TMP,-1, INFO) LWORK = WORK_TMP(1) ALLOCATE(WORKR(LWORK)) ! CALL DGGEV("N", "N", N, A, N, B, N, ALPHAR, ALPHAI, BETAR, VCL, N, VCR, N, WORKR, LWORK, INFO) !Work with this. Both "N" CALL DGGEV("N", "V", N, A, N, B, N, ALPHAR, ALPHAI, BETAR, VCL, N, VCR, N, WORKR, LWORK, INFO) !Not work when change to "V" to get right generalized eigenvectors EVAL = (ALPHAR+ALPHAI)/BETAR ALLOCATE(TEST(N)) DEALLOCATE(TEST) END[/bash]
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The work array WORKR is required to be of type DOUBLE PRECISION. In effect, then, you allocated only 1/2 the required work space.
It is wrong to assume that querying for the required size for the 'N','N' case with -1 in place of LWORK will give the correct size required for calling with 'V,'V'. The latter case asks for more results (eigenvectors) and, presumably, could be expected to need more workspace.
Once the call to Lapack is made with too small a work array, the program will be in a corrupted state and any later runtime errors will be off the mark.
If you want to use the F77 calls to MKL/LAPACK, you do not need the USE MKL ... statement(s). Likewise, since your example does not need IMSL, the INCLUDE and USE statements for IMSL are not needed.
The F95 call would be much simpler, since you would not need to do allocate the work space:
CALL GGEV(A,B,ALPHAR,ALPHAI,BETAR,VCL,VCR)
It is wrong to assume that querying for the required size for the 'N','N' case with -1 in place of LWORK will give the correct size required for calling with 'V,'V'. The latter case asks for more results (eigenvectors) and, presumably, could be expected to need more workspace.
Once the call to Lapack is made with too small a work array, the program will be in a corrupted state and any later runtime errors will be off the mark.
If you want to use the F77 calls to MKL/LAPACK, you do not need the USE MKL ... statement(s). Likewise, since your example does not need IMSL, the INCLUDE and USE statements for IMSL are not needed.
The F95 call would be much simpler, since you would not need to do allocate the work space:
CALL GGEV(A,B,ALPHAR,ALPHAI,BETAR,VCL,VCR)
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The work array WORKR is required to be of type DOUBLE PRECISION. In effect, then, you allocated only 1/2 the required work space.
It is wrong to assume that querying for the required size for the 'N','N' case with -1 in place of LWORK will give the correct size required for calling with 'V,'V'. The latter case asks for more results (eigenvectors) and, presumably, could be expected to need more workspace.
Once the call to Lapack is made with too small a work array, the program will be in a corrupted state and any later runtime errors will be off the mark.
If you want to use the F77 calls to MKL/LAPACK, you do not need the USE MKL ... statement(s). Likewise, since your example does not need IMSL, the INCLUDE and USE statements for IMSL are not needed.
The F95 call would be much simpler, since you would not need to do allocate the work space:
CALL GGEV(A,B,ALPHAR,ALPHAI,BETAR,VCL,VCR)
It is wrong to assume that querying for the required size for the 'N','N' case with -1 in place of LWORK will give the correct size required for calling with 'V,'V'. The latter case asks for more results (eigenvectors) and, presumably, could be expected to need more workspace.
Once the call to Lapack is made with too small a work array, the program will be in a corrupted state and any later runtime errors will be off the mark.
If you want to use the F77 calls to MKL/LAPACK, you do not need the USE MKL ... statement(s). Likewise, since your example does not need IMSL, the INCLUDE and USE statements for IMSL are not needed.
The F95 call would be much simpler, since you would not need to do allocate the work space:
CALL GGEV(A,B,ALPHAR,ALPHAI,BETAR,VCL,VCR)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some USE MKL.. IMSL.. remained there as I used the same file to try different solvers sometime.
I got the interface checking option turned on but the compiler does not pick the real problem in this case. I remember in some cases I met before the compiler could pick up if there is any inconsitent in type ofarguments.
Thanks for pointing out the problem and the F95 caller as well.
Great help mecej4..
Cheers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The compiler would not be able to pick up this error without a little help from you. The interface checking does not do the job since it has no access to the MKL source code.
The MKL interfaces for use in Fortran 77 callers are in the include file mkl_lapack.fi. However, that file is in Fortran fixed format, so to include it successfully in your free-format source, you have to do the following:
The MKL interfaces for use in Fortran 77 callers are in the include file mkl_lapack.fi. However, that file is in Fortran fixed format, so to include it successfully in your free-format source, you have to do the following:
[fxfortran] !DEC$NOFREEFORM !DEC$FIXEDFORMLINESIZE:132 IMPLICIT NONE ! <=== you have this already include 'mkl_lapack.fi' !DEC$FREEFORM [/fxfortran]With these changes, the compiler gives this error:
[bash]xdggev.f90(43): error #6633: The type of the actual argument differs from the type of the dummy argument. [W ORKR] CALL DGGEV("N", "V", N, A, N, B, N, ALPHAR, ALPHAI, BETAR, VCL, N, VCR, N, WORKR, LWORK, INFO) !Not w ork when change to "V" to get right generalized eigenvectors -----------------------------------------------------------------------------------^ compilation aborted for xdggev.f90 (code 1) [/bash]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's exactly the type of error message I mentioned to.
Thanks for the tips. That's cool..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi mecej4,
When I triedthe F95 call for GGEV as you suggested, it worked fine on the computer with Windows 7 32 bits. However when I run the same source on the other computer which run Windows 7 64bits, it comes with error:
Error 2 error #6285: There is no matching specific subroutine for this generic subroutine call. [GGEV]
All the project properties for the paths of Include and Library changed accordingly to suit with 64bit system, as well as used Link Avisor.. but I could not get any success.
Please advise if you have any hints on this.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page