- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using IMSL routine "DGVCRG" before passing on variables to this routine. I perform some calculations. One simple calculation involves division of two double precision number. When the new number is passed on to this routine it fails giving error
"error 1 from DGVCRG. The iteration for an eigenvalue failed to converge. "
But instead of performing that division, if I insert a number there, which is suppose to come out of that division, it runs fine and I get results
But why it does it mess it up when I have that division.
It goes like this
Run which fails --------------------------------------------
variable1 = variable2 / variable3
variable4 = f (variable1, variable..,........ ) Function of variables
DGVCRG(variable4, ...........)
Run which goes through --------------------------------------------
variable1 = 1.235689 !(which is same as variable2 / variable3)
variable4 = f (variable1, variable..,........ ) Function of variables
DGVCRG(variable4, ...........)
Thanks
Prashant Sondkar
"error 1 from DGVCRG. The iteration for an eigenvalue failed to converge. "
But instead of performing that division, if I insert a number there, which is suppose to come out of that division, it runs fine and I get results
But why it does it mess it up when I have that division.
It goes like this
Run which fails --------------------------------------------
variable1 = variable2 / variable3
variable4 = f (variable1, variable..,........ ) Function of variables
DGVCRG(variable4, ...........)
Run which goes through --------------------------------------------
variable1 = 1.235689 !(which is same as variable2 / variable3)
variable4 = f (variable1, variable..,........ ) Function of variables
DGVCRG(variable4, ...........)
Thanks
Prashant Sondkar
Link Copied
15 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We don't have general knowledge of the IMSL library internals here. Yours is a good question to ask in the IMSL forum at http://forums.vni.com/forumdisplay.php?f=8
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>I am using IMSL routine "DGVCRG" before passing on variables to this routine. I perform some calculations.
The misplaced punctuation completely changed the meaning of what you probably intended to say.
>it runs fine and I get results
Did you check those results?
The IMSL routine DGVCRG does not take any scalar real arguments. All of its arguments are either integer, or double precision real/complex arrays.
No help can be given when the problem description is incomplete and/or misleading.
We need to see the declarations of the arguments passed to DGVCRG. We need to know which version of IMSL you used, and particulars of the compiler, compiler switches, OS version,...
It would be best for you to make up a small example that shows the problematic behavior that you mentioned and to post the complete source code for the example using the Syntax Highlighting tool (the slanted yellow pen/pencil).
The misplaced punctuation completely changed the meaning of what you probably intended to say.
>it runs fine and I get results
Did you check those results?
The IMSL routine DGVCRG does not take any scalar real arguments. All of its arguments are either integer, or double precision real/complex arrays.
No help can be given when the problem description is incomplete and/or misleading.
We need to see the declarations of the arguments passed to DGVCRG. We need to know which version of IMSL you used, and particulars of the compiler, compiler switches, OS version,...
It would be best for you to make up a small example that shows the problematic behavior that you mentioned and to post the complete source code for the example using the Syntax Highlighting tool (the slanted yellow pen/pencil).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[fxfortran]REAL*8 ratio1, test, rbs, rbp ! rbs and rbp are user defined for this example their values are ! rbs = 0.07326, rbp = 0.06678 ratio1 = rbs/(rbp) test = 1.09703504043127 OmegaS = (OmegaSN * 2 * PI)/60 ! takes values from user OmegaSN is defined by user OmegaP=(ratio1)*OmegaS Ggr(4,5)= OmegaS * EMSD ! EMSD is user defined ! Here Ggr forms the part of array EK2 and EM2 , rest of the variables N2P, ALPHA, BETAV, EVEC2 are defined CALL DGVCRG (N2P,EK2,N2P, EM2,N2P, ALPHA, BETAV, EVEC2,N2P)[/fxfortran]
Comments
If I use ratio1 program fails
but if I use test instead of ratio1 it goes through
Intel Compiler 10.1
IMSL version 6.0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have not provided enough information. There is nothing in the code fragment to indicate that any of the arguments to DGVCRG are related to the variables ratio1, test and OmegaP. You may be well-intentioned in not showing us too much detail, but lack of relevant detail remains a roadblock.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
soon I will provide you with simplified code , because if I post entire code it will fill up pages
Thanks
Prashant
Thanks
Prashant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For long source code files, it is better to use these instructions and attach the files, rather than placing them in line:
Attaching or including files in a post
The procedure has two steps: first, you upload your file(s) as a .zip or .tgz file to the Intel server using the instructions, and then place a link to the uploaded file in a post in this forum.
Attaching or including files in a post
The procedure has two steps: first, you upload your file(s) as a .zip or .tgz file to the Intel server using the instructions, and then place a link to the uploaded file in a post in this forum.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
uploaded_intel_forum.zip
Here are all files of my code. There is INTEL project file also, so you can open it directly.
Now in the file named : DH_FRORCED_VIB_Model_1
if you search for variables ratio and ratio1 you will find following entries
Here are these lines
ratio1 = rbs/(rbp)
ratio = 1.09703504043127
Now 3 lines below you will find
OmegaP=(ratio)*OmegaS
Here if I use ratio, run will go through, but if I use ratio1 it will fail
Both ratio and ratio1 have same values, only thing is rbs and rbp are user input
Hope this will clear my problem
Thanks
Prashant
Here are all files of my code. There is INTEL project file also, so you can open it directly.
Now in the file named : DH_FRORCED_VIB_Model_1
if you search for variables ratio and ratio1 you will find following entries
Here are these lines
ratio1 = rbs/(rbp)
ratio = 1.09703504043127
Now 3 lines below you will find
OmegaP=(ratio)*OmegaS
Here if I use ratio, run will go through, but if I use ratio1 it will fail
Both ratio and ratio1 have same values, only thing is rbs and rbp are user input
Hope this will clear my problem
Thanks
Prashant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I cannot try out your combination of compiler and IMSL versions.
You have the statement
ratio = 1.09703504043127
in which the constant is of type REAL*4, rather than the intended REAL*8. Replace it by
ratio = 1.09703504043127D0
which matches the statement
ratio = rbs/rbp
better, since both rbs and rbp are REAL*8.
The questions
i) why are the eigenvalue calculations are so sensitive to this ratio?
ii) how to fix the problem?
iii) given the sensitiveness, do the input data have sufficient precision?
need to be addressed by you or someone versed in the application area.
You have the statement
ratio = 1.09703504043127
in which the constant is of type REAL*4, rather than the intended REAL*8. Replace it by
ratio = 1.09703504043127D0
which matches the statement
ratio = rbs/rbp
better, since both rbs and rbp are REAL*8.
The questions
i) why are the eigenvalue calculations are so sensitive to this ratio?
ii) how to fix the problem?
iii) given the sensitiveness, do the input data have sufficient precision?
need to be addressed by you or someone versed in the application area.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
YOu are suggesting changing the constant type, but run goes through with
ratio = 1.09703504043127
and fails with
ratio = rbs/rbp
lets say run goes through by entering the value of rbs/rbp but fails when calculations are perfomed by fortran
ratio = rbs/rbp (fails)
ratio = 1.09703504043127 (goes through)
is it possible while doing this calculation it changes data type.
ratio = 1.09703504043127
and fails with
ratio = rbs/rbp
lets say run goes through by entering the value of rbs/rbp but fails when calculations are perfomed by fortran
ratio = rbs/rbp (fails)
ratio = 1.09703504043127 (goes through)
is it possible while doing this calculation it changes data type.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are drawing unfounded conclusions. Whether the calculation "goes through" or not is irrelevant at this point.
The rules of Fortran are quite explicit as to assignment statements. The right hand side expression is evaluated using mixed mode rules, the result is converted if necessary to the type of the variable on the left hand side.
In this case, the expression on the right has type REAL*4, regardless of how many digits you typed in for the constant. The variable on the left is REAL*8. To convince yourself, print the value of the variable to, say, 15 digits:
ratio = 1.09703504043127
write(*,'(1x,1p,D20.14)') ratio
You will see the printed value as
1.09703505039215D+00
You have another statement in the same file which is waiting to give you trouble:
PISI(i)=(i-1)*(360/Nplanets)
If Nplanets is, for example, 7, and i = 2, the value assigned will be 50.0D0
The rules of Fortran are quite explicit as to assignment statements. The right hand side expression is evaluated using mixed mode rules, the result is converted if necessary to the type of the variable on the left hand side.
In this case, the expression on the right has type REAL*4, regardless of how many digits you typed in for the constant. The variable on the left is REAL*8. To convince yourself, print the value of the variable to, say, 15 digits:
ratio = 1.09703504043127
write(*,'(1x,1p,D20.14)') ratio
You will see the printed value as
1.09703505039215D+00
You have another statement in the same file which is waiting to give you trouble:
PISI(i)=(i-1)*(360/Nplanets)
If Nplanets is, for example, 7, and i = 2, the value assigned will be 50.0D0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No NPlanets always assume value of 5, even though user has control over it, it is limited to 5, somehow told to user through separate intructions
So what shall I do, just to make it work with using ratio1 =rbs/rbp
Thanks
Prashant
So what shall I do, just to make it work with using ratio1 =rbs/rbp
Thanks
Prashant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Given the difficulty with others being able to match your combination of Fortran compiler and IMSL versions, here is a suggestion.
If you use IMSL only for the call to DGVCRG, you can set IMSL aside and use MKL instead (if your Intel Fortran came with it or you obtained it separately).
1. Remove all references to IMSL modules, include files and libraries.
2. In dh_frorced_vib_model_1.f, add the following before any declarations:
use mkl95_lapack
3. Instead of allocating the complex array ALPHA, allocate REAL*8 arrays ALPHAR and ALPHAI.
4. Instead of calling DGVCRG, do
call ggev(EK2, EM2, alphar, alphai, betav)
EVAL = cmplx(ALPHAR,alphaI) / BETAV
5. If your compiler version allows a /Qmkl switch, do
ifort /Qmkl *.f mkl_lapack95.lib
If not, read your MKL user's guide to see how to compile and link to MKL.
I have tried this and it works fine with Intel Composer XE 12.0.4 and the accompanying MKL 10.3.
If you use IMSL only for the call to DGVCRG, you can set IMSL aside and use MKL instead (if your Intel Fortran came with it or you obtained it separately).
1. Remove all references to IMSL modules, include files and libraries.
2. In dh_frorced_vib_model_1.f, add the following before any declarations:
use mkl95_lapack
3. Instead of allocating the complex array ALPHA, allocate REAL*8 arrays ALPHAR and ALPHAI.
4. Instead of calling DGVCRG, do
call ggev(EK2, EM2, alphar, alphai, betav)
EVAL = cmplx(ALPHAR,alphaI) / BETAV
5. If your compiler version allows a /Qmkl switch, do
ifort /Qmkl *.f mkl_lapack95.lib
If not, read your MKL user's guide to see how to compile and link to MKL.
I have tried this and it works fine with Intel Composer XE 12.0.4 and the accompanying MKL 10.3.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am getting this error
Error 1 Error: Error in opening the compiled module file. Check INCLUDE paths. [MKL_LAPACK]
Header lines from code are,
Error 1 Error: Error in opening the compiled module file. Check INCLUDE paths. [MKL_LAPACK]
Header lines from code are,
[fxfortran] PROGRAM DHFORVIB C USE imsl_libraries C C INCLUDE 'link_fnl_static.h' C! INCLUDE 'link_fnl_shared.h' C C !DEC$ OBJCOMMENT LIB:'libiomp5md.lib' USE MKL_LAPACK C INCLUDE 'link_fnl_shared_hpc.h'[/fxfortran]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
use mkl95_lapack
Check whether you have Lapack95. If not, you may need to build it from sources (provided with MKL). Alternatively, you can make a call to the F77 routine DGGEV -- see the MKL documentation.
Check whether you have Lapack95. If not, you may need to build it from sources (provided with MKL). Alternatively, you can make a call to the F77 routine DGGEV -- see the MKL documentation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello prashantsondkar,
In order the use statement to work you must go to your Project Properties>Linker>Input>Additional Dependencies and add "mkl_lapack95.lib" if you are compiling in 32bit or "mkl_lapack95_lp64.lib" if you are compiling in 64bit. You should also verify that you have activated MKL. Just go to your project properties>Fortran>Libraries>Use Intel Math Kernel and select either Parallel or Sequential.
Pedro
In order the use statement to work you must go to your Project Properties>Linker>Input>Additional Dependencies and add "mkl_lapack95.lib" if you are compiling in 32bit or "mkl_lapack95_lp64.lib" if you are compiling in 64bit. You should also verify that you have activated MKL. Just go to your project properties>Fortran>Libraries>Use Intel Math Kernel and select either Parallel or Sequential.
Pedro

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