topic Force a break when program ends in Intel® Fortran Compiler

Force a break when program ends

Stuart_M_ — Tue, 16 Mar 2010 18:03:52 GMT

Hello fundis

I am working with a model that takes many hours to run, but stops unexpectedly before the end of the simulation period. I have no idea where or why in the simulation it stops, and though I can tell from the output at what time it does so that doesn't really help me pinpoint the problem.

I would love to hear that there is a way, perhaps in some sneaky project setting, to force the code to break before it ends, whether it ends with error or not...

Thanks!

Force a break when program ends

ZlamalJakub — Tue, 16 Mar 2010 18:12:31 GMT

If it is console application put PAUSE before end. Program will wait to key.

Another possibility is to run rogram like

program>logfile

and alloutput to screen will be orwarded to logfile where you can look at your debuging messages you pu to your code.

if it is win32 window application you can use pause too or MessagBox

Jakub

Force a break when program ends

Stuart_M_ — Tue, 16 Mar 2010 19:29:28 GMT

Unfortunately pause won't really work for me because I don't know where the program is exiting. It could be crashing, exiting normally after being redirected by some error condition, or exiting normally but earlier than I expect for some as-of-yet unknown reason.

I was just hoping that there might be a setting akin to, say, the Floating-Point Exception Handling in the Fortran Configuration Properties where one can specify that the code break for floating point exception errors rather than simply producing NaNs.

I'm interested in your "program>logfile" solution, however. Am I correct in assuming that you're implying I run the program via a batch file? I'm not very familiar with batch scripting but I have been running my model with the following batch file on occassion:

erase RESTART.122

erase GHBFLOWS.DAT

erase FTLBIN.DAT

Debug\FTLOADDS.exe < ftlrunfiles.txt

Can you suggest how I might incorporate the >logfile addition into this particular .bat?

Force a break when program ends

ZlamalJakub — Tue, 16 Mar 2010 19:52:08 GMT

Debug\FTLOADDS.exe < ftlrunfiles.txt >logfile

I am not familiar with using exceptions (my programs do not crash in that manner).

Put write(*,*) to certain palces in your program to watch where problem occurs.

Jakub

Force a break when program ends

Steven_L_Intel1 — Tue, 16 Mar 2010 20:00:17 GMT

If you run it from within the debugger, it should break on any error. You can also trigger a breakpoint by calling the Win32 API routine DebugBreak (USE KERNEL32.)

Force a break when program ends

Stuart_M_ — Wed, 17 Mar 2010 17:19:20 GMT

Thanks Quba - that helped a lot

Force a break when program ends

Martyn_C_Intel — Sat, 20 Mar 2010 00:45:18 GMT

Another useful trick, if you are not using the debugger, is to set /traceback.
In the IDE, go to project properties/Fortran/Run-time/Generate Traceback Information and set to yes.
Then go to project properties/Fortran/Floating-Point/Floating-Point Exception Handling
and select "Underflow gives 0.0; Abort on other IEEE exceptions (/fpe:0)"
Your program should then give a traceback, which should include routine names and source line numbers, for most errors, including for floating-point exceptions which would otherwise just have generated NaNs and continued.Your programwill still exit, but at least you'd know where.

Force a break when program ends

WSinc — Sun, 21 Mar 2010 16:35:03 GMT

Another really handy trick , if it's in a loop, is to
invoke "Break all" which will tell you where the program is
at the time you invoke it. You can then have it continue
execution from that point, and invoke it again as many
times as you need it.

Force a break when program ends

WSinc — Sun, 21 Mar 2010 16:42:23 GMT

BTW, why does "close project" do nothing?

To close a project you have to exit VS 2008, or open another one.

Is this intentional?

Force a break when program ends

WSinc — Sun, 21 Mar 2010 16:51:22 GMT

Unfortunately, that does NOT catch an integer overflow, which could be the cause of
your problem.

For example, if you multiply two integer(4) quantites together, even though they are
postive, you may get a negative result, and it is not trapped. The only way to catch that
is to test invidual computations, line by line.

It's not clear to me if the INTEL instruction set has a provision for detecting it in hardware.
Maybe later processors can do that.

So, is your program strictly floating point operations? One possible workaround is
to convert the F.P. variables to real(16). The range of those is really HUGE.