- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is a puzzler.
I have a rather old code that gets all of its input from reading an input file and writes all output to a file.
I have compiled the code as a console program (i.e. EXE), and as a subroutine in a DLL. The only change to the fortran source is changing PROGRAM to SUBROUTINE. Visual Studio 2010 forces me to use a different project for each since it can't seem to build both an EXE and a DLL from the same project.
Upon execution, the two builds produce very different results from the same input file. Does anyone have any suggestions on what could cause that. The two Intel Fortran projects in Visual Studio were created entirely with default settings. The DLL seems to run correctly, but not the EXE. I tried the EXE from both Release and Debug builds, but got the same thing from each.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>Visual Studio 2010 forces me to use a different project for each since it can't seem to build both an EXE and a DLL from the same project.
True, but both can be in the same Solution.
>>Upon execution, the two builds produce very different results from the same input file.
>>The DLL seems to run correctly, but not the EXE.
Apparently your start point of writing the PROGRAM has errors.
This may be a case of uninitialized variable usage. Have you enabled the runtime checks for uninitialized variables?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the reply, Jim.
I set r/t error checking to ALL, and the EXE code built and ran with no change in output.
It turns out I may have been too quick in saying the DLL and EXE produce different output, because this morning I'm getting the same output! I need to redo it carefully. If they end up matching, then what I've got is a case of Intel Fortran giving different results than Compaq Fortran. The project was not "imported" into IVF, I made the projects from scratch.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Different results from different compilers is not at all unusual. Even changing versions of the same compiler can change results due to different instruction sequences. CVF didn't use SSE instructions for floating point where CVF did not, and this will definitely create small differences in floating point operations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>> this will definitely create small differences in floating point operations
and additionally, for poorly written convergence code, can result in either non-convergence or large divergence.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quantify "produce different output", are we talking small differences in real values or chalk instead of cheese?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The difference is one code says the answer is 8, and the other says 5. It'll be a week or so until I can spend any more time on it. I need to start over and make absolutely sure the difference is not from a screw up on my part.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Brian,
It may be beneficial to run two instances of Visual Studio debugger. One debugging the PROGRAM, and the other debugging the Test Program + DLL SUBROUTINE. You should be able to walk each versions with break points on same statements and then examine the input variables as used by computational sections.
If the iteration counts are too large to have this technique be effective, then insert diagnostic trace PRINT statements (same places same values). With appropriately constructed trace statements (file, line number, DO loop index, intermediary values, other...) you can capture the trace outputs into files, then run WinDiff or other difference program to locate the point where the programs diverge. Then you can re-run the debug sessions on both versions, with break points installed (break on iteration prior to divergence).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Brian Murphy wrote:
The difference is one code says the answer is 8, and the other says 5. It'll be a week or so until I can spend any more time on it. I need to start over and make absolutely sure the difference is not from a screw up on my part.
Sound like a coding error then. A Jim says normal debugging methods should get to the bottom of it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As it turns out, my problem was my own doing. When testing the DLL, I was switching between multiple versions. And the one I thought I was running was not the one loaded in memory, even though I thought it was. So in the end, the DLL and EXE made from the same code did in fact produce the same results.
Sorry for the false alarm.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page