- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello!
I have some troubles with my program. It doesn`t calculate variables, they are equal to NaN (not a number).
I wrote program using decomposition-paradigm. It`s a big computational program, which calc few days...
I have code like a:
\code
program main_prog
real :: x1, x2, y2
10 write(*,*) 'Goto 10... mark==.true.'
contains
subroutine function1(x1,x2)
real, intent(in) :: x1
real :: x2
logical :: mark
x2 = {expression, one function}
mark = isNaN(x2)
if (mark==.true.) goto 10
end subroutine function1
end program main_prog
\code
So, I wonder if I can jump from one subroutine to anover or to main program unit, using GOTO statement?
Maybe, I should declarate LABEL as a COMMON variable?
I hope, the special statement exists for this situation =)
My prgram is a simulation of physical sytem, and x2==NaN have a physical explanation.
.Oleg.
I have some troubles with my program. It doesn`t calculate variables, they are equal to NaN (not a number).
I wrote program using decomposition-paradigm. It`s a big computational program, which calc few days...
I have code like a:
\code
program main_prog
real :: x1, x2, y2
10 write(*,*) 'Goto 10... mark==.true.'
contains
subroutine function1(x1,x2)
real, intent(in) :: x1
real :: x2
logical :: mark
x2 = {expression, one function}
mark = isNaN(x2)
if (mark==.true.) goto 10
end subroutine function1
end program main_prog
\code
So, I wonder if I can jump from one subroutine to anover or to main program unit, using GOTO statement?
Maybe, I should declarate LABEL as a COMMON variable?
I hope, the special statement exists for this situation =)
My prgram is a simulation of physical sytem, and x2==NaN have a physical explanation.
.Oleg.
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oleg, try this
code
program main_prog
real :: x1, x2, y2
... your program here
end program main_prog
contains
subroutine foundNaN()
write(*,*) 'foundNaN' ! place breakpoint here
! continue using F10 (step) shuch that you can debug program
end subroutine foundNaN
subroutine function1(x1,x2)
real, intent(in) :: x1
real :: x2
logical :: mark
x2 = {expression, one function}
mark = isNaN(x2)
if (mark==.true.) call foundNaN
end subroutine function1
end program main_prog
code
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - jimdempseyatthecove
subroutine foundNaN()
write(*,*) 'foundNaN' ! place breakpoint here
! continue using F10 (step) shuch that you can debug program
end subroutine foundNaN
write(*,*) 'foundNaN' ! place breakpoint here
! continue using F10 (step) shuch that you can debug program
end subroutine foundNaN
It`s realy easy solution ))
But, to some degree appearence of NaN is random situation,`cause function x2 = {expression, one function} define in any region. In main-program I have a loop for Initial Condition, and program calc long string of numbers, and some of them give x2==NaN
So, debug can`t help me here.
.Oleg.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Typically NaN's are a result of using un-initialized data. Un-initialized data has "junk' and not 0.0. Some of the "junk" data will be NaN, other will be valid numbers but "junk" none the less. Consider yourself lucky if you see NaN (as this gives you an opportunity to correct the programming error). The compiler has an option for testing for un-initialized data during debug build. I suggest you use that.
The purpose of the test code I presented is for you to rewrite the subroutine such that it accepts a reference to a real, and/or real array, and inside it test for isNaN, and if NaN it enables you to enter a break point. And if break, you simply step out of the test routine to the caller, who's context containg the variable and location of the discovery of the NaN. From that location, you use the debugger to examine various variables in the context of the place of the discovery of the NaN.
At break, after examination of the various variables you might be able to determine the cause for the NaN.
When you are unable to determine the cause for the NaN, you will be able to insert the call for the test for NaN further up in the call list. Re-compile, rerun, reexamine state on break.
Eventually you will be able to discover what caused the NaN and make the correction.
Note, you can create multiple Debug configurations, one with all Debug options enabled, one with no runtime checks and fully optimized, and some with blends of features. You can debug your Release build too.
Jim Dempsey

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page