Can I see inside an IMSL routine to find source of error?

[sbj]

Hi,
I'm having trouble with an IMSL routine (PDE_1D_MG). I'm trying to replace a NAG routine with this one, and built a small test code which worked fine, replicated the results from the NAG routine, and so i went ahead and tried to put the IMSL routine into my main program.

For some reason, the main rogram falls over somewhere in this IMSL routine. I have set it up so that all the variables going into the routine are the same as my (working) testcode. Stepping through the external routines (the PDE definition subroutine) I can see the variables changing as the solver steps along the solution. Main program and testcode match for the first 11 steps, then one variable suddenly jumps away, and three steps later becomes NaN. Understandably, program crashes (see attached - right hand column of numbers should carry on increasing in steps of ~12.5).

The underlying array, which i assumed defined this variable, is till intact and OK, as expected, so why does this one variable suddenly get out of shape? Is there a way of steppingthrough the IMSL routine to find out why/how the error is introduced?

I'm using IVF compiler 11.1.051, VS 2005, XP Pro, very old Dell laptop with 0.5 GB memory (could this be the problem?)

I'm a relative novice, any help etc appreciated. I don't know if this is relevant but when I watch variables in the locals window they sometimes have a pink icon to their left and sometimes blue, often changing midway through execution.

stuart

[mecej4]

You can step through IMSL code only if you choose assembly mode, but that is not a useful thing to do. Even if you had the IMSL source code, it would not be a good idea to trace through it unless you suspect a bug in the IMSL routine.

You could recompile and run, with debug/traceback turned on, and pinpoint the routine where the fault occurs.

IMSL routines have almost no bugs, and problems such as what you have described are most likely caused by using improper or inconsistent arguments, improperly dimensioned arrays, or sometimes a problem with an unbounded solution.

We need to see array declarations, IMSL call lines and, possibly data. VNI has an active forum for IMSL at forums.vni.com .

[pbkenned1]

The suggestion to compile in Debug mode is a good one, that will help rule out compiler optimizations as a possible root cause.Debug modealso automatically asserts /traceback for Fortran projects in the Visual Studio* IDE.

Try trapping thesource of the NaN by enabling Floating Point exceptions and forcing the program to abort when the NaN generated (as opposed to letting it silently propagate through the computations). In the VS IDE for the Fortran project:

Project > Properties > Fortran > Floating Point

> Floating Point Exception Handling > Underflow gives 0.0; Abort on other IEEE exceptions
>Floating Point Model > Strict
> Reliable Floating Point Exceptions > Enable

Patrick Kennedy
Intel Developer Support

[sbj]

Thanks both.

I'm compiling in debug mode, and stepping through various breakpoints to follow the parameters that go into and out of the IMSL routine as it calls an external subroutine (coded by me) that defines the PDE.

I'm not suggesting the IMSL routine has a bug - I've used it in a test program and it was fine. The traceback info in the screenshot attached to my first post doesn't tell me much - should i be able to get more info from this? How?

I've set the floating point exceptions as suggested and this doesn't catch anything I wasn't already getting.

As the first reply suggested, I think it is likely to be an array shape or bound that doesn't match somewhere, I'll start hunting for it. The problem appears after the IMSL routine has thrown parameters back to my subroutine, though, and i figured if i could look into the source code i might see which array(s) were causing the problem. I'm puzzled as to why everything works perfectly for the first ten iterations , and then goes crazy.

Further suggestions welcomed, and I'll let you know if I uncover anything...

[mecej4]

The traceback info that you provided does not provide useful diagnostic information:

(i) since we do not know what part of the program (the part you wrote or an IMSL routine) wrote the list of numbers, what those numbers are, and whether those values are correct.

(ii) apparently the IMSL caller (the part you wrote) was not compiled with line number and debug information in the .exe, since only the PC (program counter) values are shown in the traceback, rather than routine names/line numbers. Compiling with /Zi and /traceback would make this information available.

If we could see the IMSL routine calls, and the declarations of the arguments passed, it might help locate the trouble.