Force a break when program ends

[Stuart_M_]

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!

[ZlamalJakub]

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

[Stuart_M_]

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?

[ZlamalJakub · Accepted solution]

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

[Steven_L_Intel1]

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.)

[Stuart_M_]

Thanks Quba - that helped a lot

[Martyn_C_Intel]

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.

[WSinc]

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.

[WSinc]

BTW, why does "close project" do nothing?

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

Is this intentional?

[WSinc]

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.