The Great Verification Puzzle

So, there is a problem with the verification code. It produces incorrect results over a region with certain values for transmitter heights or terrain profiles. On a flat piece of terrain, this only happens when the transmitter is at or above the clutter height specified within the itwom file, which leads me to look closely at those pieces of code that use both the transmitter height and the clutter height.

In my attempts to debug, I've taken the OpenCL code and run it through the GCC C++ compiler to see what happens if you run the OpenCL code as 'normal' code. The same discrepancies exist on both this version of the code and the OpenCL version of the code. Therefore, I'm sure that the discrepancy is caused by some translation error on my part.

The upshot of doing this is that I have print-style debugging available to me on the host side, that I don't have on the device side. This allows me to narrow down the issue to a specific function by printing out that function's return value before returning and comparing it to the return value on the initial ITWOM code.

This is the command with the parameters that cause the issue: pathtest -v -d 10 -f 900.2 -t 22.51 -n 1000 > foo.out

I have determined that the following functions are clear by return value (not counting side effects):

• adiff2
• saalos
• initadiff2 (which was added by my modifications, may be the cause of discrepancies in adiff2)

I have determined the following functions are suspect and must be cleared:

The following functions have known discrepancies:

• alos2

Now, I've tracked (at least part) of the discrepancy in alos2 to a discrepancy in the prop_zgnd variable, which is set from components of the prop struct that is passed in as a pointer. Working up the calling tree, I now believe the mistake is in the qlrps() function and it's handling of the zgnd complex numbers. I suspect it has something to do with the function I copied to take the square root of complex numbers.

I think my suspicion was correct, but there may be other issues. I'm examining other parts operations I've done with complex numbers in alos2.

Fixing the complex number functions seems to have fixed this issue. But, I've found another issue. I'm going to put that on another page.