# Aborting due to internal error

## Aborting due to internal error

I use Intel visual Fortran 2013 + Microsoft Visual Studio 2008, when i run the code, i got the report "Aborting due to internal error"

The code is :

subroutine d_tauchen(y,pi,rho,sigma,n,cover_tauchen)

use imsl_libraries
use shared_types
implicit none

integer, intent(in) :: n

real(data_type), intent(in) :: rho, sigma, cover_tauchen
real(data_type), dimension (n,n), intent(out) :: pi
real(data_type), dimension (n), intent(out) :: y

integer :: yc, tc, tcc

real(data_type) :: sigy, mu, upp, low

! Define the discrete states of the Markov chain
! variance of shock
sigy = sigma/sqrt(1.0-rho**2)

! set upper bound and lower bound of shocks
y(n) = cover_tauchen*sigy !%(sqrt(n)/sqrt(2.0))*sigy ! good for 0.007, increase later
y(1) = -y(n)

do yc = 2, n-1

y(yc) = y(1)+(y(n)-y(1))*(yc-1.0)/(n-1.0)

end do

! Compute the transition matrix

do tc = 1,n

mu = rho*y(tc)
upp = (y(2)+y(1))/2.0
upp = (upp-mu)/sigma
pi(tc,1) = D_ANORDF(upp)
low = (y(n)+y(n-1))/2.0
low = (low-mu)/sigma
pi(tc,n) = 1.0-D_ANORDF(low)

do tcc = 2, n-1

low = (y(tcc-1)+y(tcc))/2.0
upp = (y(tcc+1)+y(tcc))/2.0
low = (low-mu)/sigma
upp = (upp-mu)/sigma
pi(tc,tcc) = D_ANORDF(upp)-D_ANORDF(low)

end do

end do

open(unit=98,file='Tauchen.txt')
write(98,*) 'rho, sigma, n'
write(98,*) rho, sigma, n
write(98,*) 'Income States'
write(98,*) y(1:n)
write(98,*) 'Transition Matrix'

do tc=1,n
write(98,*) pi(tc,:)
end do

close(98)

end subroutine

9 posts / 0 new
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

Assuming that data_type is the same as the intrinsic double precision type, I had no problem compiling the code using IFort 13.1.0.149 for IA32. The 64-bit compiler, on the other hand, ran into an ICE on the line shown in boldface in the posted source code, apparently because of an error in the catch-all module file imsl_libraries.mod that came with IMSL FNL7.

An easy work-around is to USE ANORDF_INT instead of USE IMSL_LIBRARIES. You should also change the specific name D_ANORDF to the generic name ANORDF throughout, so that if/when you wish to try a single-precision version of your program the changes required will be much less.

If there is more to the message than you have quoted, a fuller quotation would be helpful. If it comes from the IPO phase, a complete rebuild with /Qipo- might be worth trying.

There have been 3 releases of XE2013; if you are lucky, the latest may be better.

Internal error of course indicates a reportable bug.  As few of us have IMSL, you would have to wait for someone who has it to try your example.

Supposing that the case worked with the option /fp:source you could still get good optimization by replacing /2.0 by *0.5

Such problems occur if, for example, IMSL FNL7, is used with an Intel Fortran version more recent than the one used to compile the IMSL libraries (11.1). A workaround is to replace the catchall USE IMSL_LIBRARIES with USE ANORDF_INT.

Note that it would be better to use the generic name ANORDF instead of the specific name D_ANORDF when invoking the function, as using the generic name makes for better portability of your code.

First of all, we don't provide IMSL FNL7. If you have that, you got it from Rogue Wave. There is normally no problem using old modules with a newer compiler, but there was an issue with the Intel 64 11.1 FNL modules when used with a 12.0 or newer compiler. This was due to the modules being compiled with a beta 11.1 compiler. This is fixed in the IMSL provided with the 2011 and 2013 product releases.

The particular error cited tends to be all you see...

I will try the example code when I am back at work on Tuesday.

Steve

I also cannot reproduce this problem, but the symptom you describe is exactly what would have been seen using the 11.1 IMSL modules with a 12.0 or later compiler. Where did you get IMSL from? The particular problem occurs when using the LINEAR_OPERATORS module which is included in IMSL_LIBRARIES. If you use ANORDF_INT, instead, you can avoid the problem. If you bought IMSL from us, please use the IMSL that we provide for Fortran Composer XE 2013 (if your license permits). Otherwise contact Rogue Wave and ask for rebuilt modules.

I'll also comment that I don't recommend using the D_ and S_ forms of routine names. Please use the generic names instead (ANORDF instead of D_ANORDF).

Steve

Quote:

mecej4 wrote:

Assuming that data_type is the same as the intrinsic double precision type, I had no problem compiling the code using IFort 13.1.0.149 for IA32. The 64-bit compiler, on the other hand, ran into an ICE on the line shown in boldface in the posted source code, apparently because of an error in the catch-all module file imsl_libraries.mod that came with IMSL FNL7.

An easy work-around is to USE ANORDF_INT instead of USE IMSL_LIBRARIES. You should also change the specific name D_ANORDF to the generic name ANORDF throughout, so that if/when you wish to try a single-precision version of your program the changes required will be much less.

Thanks so much, it works after i change USE IMS_LIBRARIES to USE ANORDF_INT following your comments, last week i just change D_ANORDF to ANORDF, and it fails.

Quote:

TimP (Intel) wrote:

If there is more to the message than you have quoted, a fuller quotation would be helpful. If it comes from the IPO phase, a complete rebuild with /Qipo- might be worth trying.

There have been 3 releases of XE2013; if you are lucky, the latest may be better.

Internal error of course indicates a reportable bug.  As few of us have IMSL, you would have to wait for someone who has it to try your example.

Supposing that the case worked with the option /fp:source you could still get good optimization by replacing /2.0 by *0.5

Yes, i got the latest version, and someone help me find the mistake, thank you as well.

Quote:

Steve Lionel (Intel) wrote:

I also cannot reproduce this problem, but the symptom you describe is exactly what would have been seen using the 11.1 IMSL modules with a 12.0 or later compiler. Where did you get IMSL from? The particular problem occurs when using the LINEAR_OPERATORS module which is included in IMSL_LIBRARIES. If you use ANORDF_INT, instead, you can avoid the problem. If you bought IMSL from us, please use the IMSL that we provide for Fortran Composer XE 2013 (if your license permits). Otherwise contact Rogue Wave and ask for rebuilt modules.

I'll also comment that I don't recommend using the D_ and S_ forms of routine names. Please use the generic names instead (ANORDF instead of D_ANORDF).

Dear Steve,

It's exactly what you said, after i use ANORDF_INT, i have sucessfully avoid the problem, and i also use generic names instead as your suggestions. I am not quite sure where this IMSL comes from, i used the IVF on the computer in my office, i don't know who take care of this before.Thanks for your help!