M6201 runtine error (DOMAIN)

[TommyCee]

I have a rather large F77 program that I have carefully converted to F90. To further move it to F90, I am tediously removing each of a number of COMMON blocks. I have successfully dismantled 4 of them, and am working on a 5th. At each stage, I verify output vs. the original test case to ensure numerical fidelity.

In general, when I remove a COMMON block, I add its variables to the Declaration section up in the Module of the program, and then, for each subroutine that had that used that COMMON block, I add 'use ModuleName'. This has worked fine.

I'm using, btw, the CVF v6.6C compiler w/ Windows XP Pro.

In the latest case, I removed the 5th COMMON block and it compiled fine. However, during execution, the program choked on a certain line in one of its many subroutines- a line which involved SQRT. 3 key lines are as follows (real U is passed in as an argument; real array Y of 8 elements is set in an other subroutine and also passed in as an argument):

W = Y(2)/Y(1)
sum = (w**2 + u**2)
V = SQRT(W**2+U**2)

I traced the problem to this point and added some diagnostic writes just below this choke point. Strangely,
(1) real array Y is not even in the COMMON block I removed.
(2) the subroutine is executed 128,646 times before any problem arises, at which time the values are as follows:

Y(2) = Infinity Y(1) = Infinity w = NaN u = 3.5 Sum = NaN

When Y(2) & Y(1) go to infinity, their quotient is NaN, and SQRT(NaN) is BUST!

Mind you , in the version before I removed the 5th COMMON block, this sub. is executed 473,351 times. So the program only went to ~27% completion before crashing.

FWIW: Y is used in a couple subs. and always passed in or out via ARGs (never via COMMON or any other way).

I realize that most of you will have a difficult time deciphering this w/o the code, which I can't provide b/c it's lengthy & proprietary. But I'm looking for general Fortran principles. Why would a variable (array Y) that worked fine before suddenly begin taking on values that reach infinity, thereby crashing the intrinsic SQRT function? Can I try any declaration tricks to "stabilize" Y? Any thoughts or suggestions are appreciated.

 

[xwb]

Not sure if you can do this - I only have PS4 the predecessor to CVF5 and IVF7 - the successor to CVF6.

Under the project properties, in the diagnostics section, switch on all run time error checking. It is possible that a block data which initializes arrays has been missed out.

 

[gummibaer]

I am using CVF 6.6 and to my experience if you find any variable as 'infinity' this indicates a problem in an expression setting this variable, like division by zero, arcsine of a value exceeding 1.0 or such. So the target should be the other subroutine where Y is evaluated. The common block might have created a problem there.

As you use CVF 6, then you have a powerful debugger available. If you are not allready employing it, familiarize yourself with it and check the data that contribute to the value of Y.

Norbert


The optimist believes we live in the best of all possible worlds - the pessimist fears this might be true.

 

[xwb]

You can set conditional breakpoints with the debugger so if you know the range of Y(1)
[ul]
[li]set a breakpoint on W[/li]
[li]right click on the breakpoint and select Breakpoint Properties.[/li]
[li]select Condition....[/li]
[li]Say the range of Y(1) is 1.0 to 100.0. You could put Y(1) .ge. 1.0 .and. Y(1) .le. 100.0. You can also use the C/C++ syntax but the Fortran syntax works.[/li]
[/ul]

 

[salgerman]

As careful as you are being about those common blocks...remember that common blocks are "position-based" and not "name-based"...in other words, you can't simply take the variables listed in a common block, put them in a module, share them globally and expect the program to work...this is NOT guaranteed. A common block with the same name could very well list local names for all the variables in the common block...or maybe just one!

Before I replaced common blocks, I make sure they 'look' the same, the break lines at the same variables, etc and THEN I highlight one instance and do a search of it over and over and over and make sure I hit all instances of the common block...if one does not get hit, it is because one of the variables has a different name.

my 2 cents.

 

[TommyCee]

Thank you one and all for your fine postings and helpful spirit. I meant to post back on Sunday but the day got day from me. As many things in Fortran do, it came to me in in my sleep Sat. night that it may not matter that the Y-array is not contained in the COMMON block I removed. Rather, I surmised, it might be that the Y-array is dependent somehow on something passed via that COMMON block. I knew that the Y-array was in another sub. and imagined that that sub. had once used the COMMON block I removed. Sure enough, I checked and that was exactly the case. But it remained for me to soup up my debugger to trace the actual choke point. I added another switch (/fpe:0) to Project|Settings|Fortran Project Settings: which added a lot of horsepower. At runtime, the choke point was actually trapped upstream in the earlier subroutine where Y() was set, and instead of a SQRT problem, it was a Divide by zero problem - Error (73). A gas constant value cot corrupted (details spared here) and was, shall we say, not really constant. This trace enabled me to fix the problem.

Your point about the pitfalls of COMMON block removal is well taken, Salgerman. Cautious & incremental is the way ...

XWB, you had a very interesting suggestion I wish I had known about how to enhance the breakpoint. However, when I right-click on the line, I get Properties but no "Condition" as you describe.

Thanks again for all the help & suggestions.

 

[xwb]

Which visual studio are you using - 5, 6, 2003 or 2005