forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Floating point co-processor fault

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mali28



Joined: 09 Feb 2017
Posts: 11

PostPosted: Tue May 02, 2017 11:27 am    Post subject: Floating point co-processor fault Reply with quote

I am getting the following error:

Unknown floating point exception 90a1

Floating point co-processor fault at address 00418b50 in file.... at line number ...


This is the function I am using:

!****+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
FUNCTION Sh_calc(Re,Sc)
!****+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
USE nrtype
USE ProgramOptions,ONLY:TimerOn
USE Timing,ONLY:Sh_calc_timer
USE DerivedTypes,ONLY:timer
! Dummy Variables
REAL(DP),INTENT(IN) :: Re,Sc
REAL(DP) :: Sh_calc
!----+-----------------------------------------------------------------+
! TIMING
IF(TimerOn) CALL CPU_TIME(Sh_calc_timer%t1)
!----+-----------------------------------------------------------------+
! Calculate Sherwood number from the Ranz-Marshall correlation
Sh_calc = 2d0+6d-1*SQRT(Re)*Sc**33d-2
!----+-----------------------------------------------------------------+
! TIMING
IF(TimerOn)THEN
Sh_calc_timer%calls=Sh_calc_timer%calls+1
CALL CPU_TIME(Sh_calc_timer%t2)
Sh_calc_timer%tot_time=Sh_calc_timer%tot_time+&
(Sh_calc_timer%t2-Sh_calc_timer%t1)
END IF
!****+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
END FUNCTION Sh_calc
!****+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+


I am not sure what is causing this error. Is it because something inside square root is getting negative?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Tue May 02, 2017 2:10 pm    Post subject: Reply with quote

If you are uncertain if the problem is that either Re or Sc could be zero or negative, why not test for the possibility ? Certainly the function value would be undefined (or complex) if this was the case.

I am also puzzled by the coding approach as I see two problems with it.

1) the use of CPU_TIME is unlikely to give a useful or informative result, as this timer only updates it's outcome 64 cycles per second. It is not suitable to time such a short calculation. I would recommend REAL(KIND=3) FUNCTION CPU_CLOCK@() (REAL*10) for 32 bit or INTEGER(KIND=4) FUNCTION RDTSC_VAL@() for 64 bit (integer*8) as these functions give a much more accurate elapsed time report for short calculations.

2) The precision of the calculation "Sh_calc = 2d0+6d-1*SQRT(Re)*Sc**33d-2 " looks unusual and could be improved.
What is "**33d-2" for ? Is this to get the cubed root ? It is certainly a strange mix of precisions. 33d-2 is 0.33d0 which is not a third.

You could define
real*8, parameter :: third = 1.0d0 / 3.0d0
then use:
if ( Re > 0 .and. Sc > 0 ) then
Sh_calc = 2.d0 + 0.6d0 * SQRT(Re) * Sc**third
else
Sh_calc = huge (Re) ! or some other invalid response
end if

or is it "Sh_calc = 2.d0 + 6.d0 - 1.d0*SQRT(Re)*Sc**0.33d0" ?

Definitely use better constants and some spaces.
Back to top
View user's profile Send private message
mali28



Joined: 09 Feb 2017
Posts: 11

PostPosted: Tue May 02, 2017 2:51 pm    Post subject: Reply with quote

Thank you for your input. It was a negative value used inside the square root causing the error. The error is gone, but now I am getting the following run time error:

Access Violation

The instruction at address 0041c833 attempted to write to location 9f31e053 in file transport_process.f90 at line 326

NR!NR - in file transport_process.f90 at line 326 [+10b3]

The code I have on line 326 is below:

IF(BT.eq.BT) BTolder=BT


BT is a real double precision defined as REAL(DP) :: BT
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed May 03, 2017 3:26 am    Post subject: Reply with quote

If the particulars that you reported are correct, scanty as they are, the only possibility is the BTOLDER is not writeable.

Beyond that, there is very little that anyone can tell you about your code without seeing the code. At a minimum, what are the attributes of BTOLDER? Is it a named constant? Is it an INTENT(IN) argument to a subroutine? Is it a scalar or an array? Has it even been declared? The less specific detail that you provide, the more numerous are the possible causes, and I certainly would not want to describe all those possibilities in a forum post.

If you are unwilling or unable to provide more complete bug reports, there is little probability of anyone being able to help you. You will be better off by yourself if you recompile and link with /check or /checkmate and learn to use the SDBG debugger.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed May 03, 2017 12:17 pm    Post subject: Reply with quote

>FTN95 yourcode.f95 /checkmate
>sdbg yourcode.exe

and in 30 seconds your problems are gone.

BTW, I usually do not read manuals, the most useful help is here:

>FTN95 /? >ReadAndTryFirst
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed May 03, 2017 2:54 pm    Post subject: Re: Reply with quote

DanRRight wrote:
>FTN95 yourcode.f95 /checkmate
>sdbg yourcode.exe
and in 30 seconds your problems are gone.

I wish that were true for me. It usually takes me that much time just to resize the various panes in the debugger and arrange them in a convenient layout before I can even start the program.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed May 03, 2017 3:50 pm    Post subject: Reply with quote

The positions of the panes can be saved for next time by clicking on the system menu icon (top left corner) in every pane. See "Fix Window Shift F9". As I recall you have to do it separately for each pane but I am not sure about this.

This works for the 32 bit debugger but maybe not yet for the 64 bit debugger.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed May 03, 2017 4:09 pm    Post subject: Reply with quote

Even with the 32-bit SDBG debugger, on Windows 10-64 and a 1920 X 1080 display, the windows are slightly different in size and location after I do SHIFT+F9 in each pane, single step in the program, exit, and restart SDBG. I like my panes to fit on the canvas, with no gaps or overlaps. SDBG-32 does not oblige in this regard.

Perhaps the unit of measurement used for saving the window coordinates is too coarse.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed May 03, 2017 8:53 pm    Post subject: Reply with quote

SDBG is ultimately simple, intuitive and efficient. Nothing to learn about using it, all must use it everyday as a default compilation setup. To my surprize it looks like actually almost no one use it including -- what a shame -- this compiler developers themselves. This explains very bad its aesthetics and still existing little defect mecej4 mentioned which I confirm, though small windows mispositioning are less annoying on large 4k monitors I recommend to anyone as they became dirty cheap (size must be minimum 48-50" and be 4.4.4 chroma at 60 Hz capable TVs and videocards like NVIDIA 900+ capable for that chroma and Hz. Latest videocards are extremely fast with FTN95 OpenGL. Make sure also that input lag is below 30ms in game mode, my Samsung 7100 is 26ms, look at Rtings dot com for that). Usually I adjusted windows position ones per month but now I'm switching to 64 bit debugger (which so far is hard coded to not allow any adjustments Smile )

As to SDBG64 - being in its early stage it needs more work. All literally must use debugger, then its own bugs and problems will be solved in no time. Time to upgrade also processor of you feel the debugger is slowing down the code too much. Intel 7700k is overclockable to 5 GHz on liquid cooling. And AMD Zen has 8 cores for 300 bucks

I'm curious why people ignore debugger...I suspect this also could be because of inconvenience of Windows Command Prompt if use it instead of Plato. I use not one but 6 simultaneously opened file managers like Total Commander (of different color for convenience) and with them the conditional compilation with BAT files with very long talking names is very fast with just clicking and one-two letter typing. This is #1 program Windows is missing hard.

USE DEBUGGERS !
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group