Aborting due to internal error

Aborting due to internal error

imagem de Fang D.

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

Please help me out of here, thanks!

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
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.
imagem de mecej4

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.

imagem de Tim Prince

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

imagem de mecej4

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.

imagem de Steve Lionel (Intel)

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
imagem de Steve Lionel (Intel)

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
imagem de Fang D.

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.

imagem de Fang D.

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.

imagem de Fang D.

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!

Faça login para deixar um comentário.