Error after optimization and showing of variable values in debug

[Wee_Beng_T_]

Hi,

I found that when I used optimization option -O3 instead of -O0 for one of my source code circle.f90, my program diverges. This happens both in the windows and linux version. However, they diverge at slightly different time step. Othewise, both give the same answer when -O0 is used

Any suggestion what is the best way to track down the error?

Also, I tried to debug in the windows ver of ifort in visual studio net. I have declared some variables as global and in the main program (main.f90), I'm able to see their values during debug in the "watch" column. However, when I jump to another source code file (e.g. circle.f90), the values become"Undefined variable ".

May I know how can I see their values? I used to be using CVF and I'm able to see all variables.

Thanks alot!

[Steven_L_Intel1]

It is not uncommon for floating point computations to diverge between unoptimized and optimized code. Are the optimized values wrong or just slightly different? You can try to improve the consistency by adding the option /fp:precise under Additional Options. This will somewhat reduce performance. Another thing to try which will increase performance is to specify Pentium 4 (or higher as your processor allows) for "require processor type".

I don't quite understand your debug question in regard to what you mean by "jump to another source code file". If you call a routine, the local variables of the caller are not shown unless you select that call level in the Call Stack panel. That is the same as CVF.

[Wee_Beng_T_]

Thanks for the reply Steve.

The difference between the optimizied and non-optimized code is very big for both OS. The optimized one's value explode after a while.

1st of all, my code is divided into 1 main source (main.f90), a global variable initialization source (global.F) and several other source files (circle.f90 etc) which contains subroutines. Like I said b4, I found that when I use -O3 for the circle.f90, the error occurs. On the other hand, if I use -O0 for circle.f90, there is no error. It seems that it doesn't matter whether -O3 or -O0 is used for the other source files. Does that means the error is definitely in circle.f90? I'm trying to pinpoint the error.

As for the debugging, I have declared global variables e.g. u(10,10). I can check their values when I am debugging in the main.f90 using watch1. However, when my program flows to a subroutine circle_mov in circle.f90, I can see the local variables for that subroutine. However, I am now not able to see the global variables e.g. u(10,10). It simply shows "Undefined variable u". So how can I check what is the value?

Thanks again

[Steven_L_Intel1]

It would be worthwhile adding code to dump intermediate computation values in circle.f90 to see where the results start to diverge. You may have an unstable algorithm or one that is sensitive to rounding differences. When I am working such an issue, I dump the values in hex and floating (to lots of places) to a file, along with some state information, run the program both ways and then look to see where results start to differ.

When you say "global variables" do you mean module variables? If so, try using the watch syntax modname::variablename. If you mean COMMON variables, nothing should be needed.

[Wee_Beng_T_]

Thanks Steve!

I added global_data::u(10,10) and the value finally showed. I'll try your mtd to debug my problems

[Wee_Beng_T_]

Hi,

after 2 days of debugging, I finally found the subroutine that's causing the problem. For the windows ver, I found that when I use -O3, the error occurs. However -O1 and -O2 give correct result.

For the linux ver, only -O0 gave the correct result.

However debugging in windows with visual studio net, I found that when -O1 is used, I can't see the local variables. It says:

Cannot view register variable

When -O3 is used, the msg is"Undefined variable". May I know how can I see the variables' values?

Lastly, if I used -O0 for 1 source file subroutine and used -O3 forall other source files (some has dependencies ontt file), how optimized is my code? In other words, if 1 or 2 source files are not optimized when the othersare, will the overall speed of my code be greatly reduced?

thanks alot!

[jimdempseyatthecove]

Quarkz,

To view a register variable you must view the register (after first determining which register the variable lies within). To do this, from the break point, open the Disassembly window. If this is your first time looking at disassembled code you may feel intimidated. It is not as bad as it first looks. Usually it is quite easy to see where (which registers) are used to store results. Depending on your settings in VS either the register values can be seen by hovering the cursor over the variable (register) name, right-click on it, or if all else fails, open the Registers window.

If your subroutine can be extracted from the application and placed into a simple demonstration program with data that will exhibit the problem then send the dummy application with problematic code and datto Premier Support for analysis.

>> In other words, if 1 or 2 source files are not optimized when the othersare, will the overall speed of my code be greatly reduced?<<

This depends on the portion of work that the subroutines perform. To find out, compile with options to make the code work. Then use a profiler. Intel has VTune for this purpose, but there are other profiler tools available. I use AMD's CodeAnalyst (CA) because my server has AMD Opteron processors. CA has limited functionality on Intel processors but timer based sampling can be used and should be more than suitable to find the hot spots within your application. I use CA on my P4 systems without problems.

Jim Dempsey