Floating point co-processor fault

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-1SQRT(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?

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@() (REAL10) for 32 bit or INTEGER(KIND=4) FUNCTION RDTSC_VAL@() for 64 bit (integer8) 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.

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

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.

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

Quoted from DanRRight

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.

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.

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.

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 😃 )

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 !