- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
new_flux(isol) = . d1_curr*h*(d0*(temp_res-temperature(istage,ifluid))-sume)/ . (d0*d1_curr + h*(d1_curr*sqrt(delt_loc) + d0*delt_loc))
Is the line too complex? Why only now after happily executing it hundreds of times before?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Better alternatives to -Op and -fltconsistency are coming.
If my guesses above are off the mark, please give some of the missing information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Check all your function declarations carefully. Try building with /gen_interfaces /warn:interfaces and see if the compiler alerts you to a mismatch.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
Iadded /gen_interfaces /warn:interfaces to the compilation flags. It compiles a few files, then get stuck on one file. On checking Task Manager, I see fortcom.exe is taking up 99% of the CPU time.
Adrian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So you're back to checking the declarations manually. You could always compile with /warn:declarations that forces you to explicitly declare everything.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Fortran DLL it is stopping in, is being called from a new C DLL. Is it possible the cause could be in the C DLL? or do I need to look in the Fortran DLL. The reason I ask is that the C DLL is new, and the FTN code has been running fine without it.
Adrian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you rebuild the C DLL and link against the C debug libraries? They have a feature for detecting this as it happens.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The X87 floating point unit has an internal stack where values get pushed on and then popped off as operations are done. As long as the pushes and pops match, you're fine. If you try to pop something and the stack is empty, you get a FP stack check.
When you call a function that returns a float, the return value is left on the stack when the function returns. The caller is supposed to pop it off. If you call a function where the caller thinks the function is REAL but the function itself is INTEGER (hence nothing on the FP stack), error. You can also get an error later if a value is left hanging on the FP stack.
Resolving the type inconsistencies is the only fix.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For the record, I fixed this eventually. As I thought, it was in the C code which calls the Fortran DLL. I found that if I called a certain function in C, it failed in the FTN code after the 11th time calling the C function. And if I didnt call the function, it never failed in the FTN code.
On diagnosing that C function, I tracked it down to the use of the sqrt() function. Should be innocuous, but
I included math.h, and all works just fine.
Adrian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not including math.h would not cause the linker to fail. The #include directive is a preprocessor directive. The math.h header defines data structure and function prototypes for the math routines (like sqrt, sin, etc). Without that header, the compiler would have assumed that sqrt returns an int and takes an arbitrary number of arguments.
Message Edited by jamesd42 on 02-15-2006 06:05 PM
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page