SECNDS()

[jayb]

The Intel Fortran portability function SECNDS() seems to have a bug in version 16.1, at least on Red Hat Enterprise Linux 6.

SECNDS() is supposed to return the elapsed seconds since midnight, minus the argument.  If you begin a program before midnight and invoke SECNDS(0.0) one or more times, then invoke SECNDS(0.0) after midnight, all calls after midnight return the value of the last call before midnight.

Code to re-produce this is trivial; the hard part is executing it at the right time.  Having root privileges to change system time helps!

I do not recall seeing this in version 15, but could be mistaken.  And if there is a bug, it might not be in Intel Fortran.  A workaround is as good as a fix.

Jay

[Steven_L_Intel1]

SECNDS hasn't changed in almost a decade, and I don't see any code that "remembers" a previous call. It does have code to adjust the result if the argument is from a time before midnight.

I might suggest using the standard intrinsic procedures SYSTEM_CLOCK or DATE_AND_TIME rather than SECNDS.

[jayb]

I agree that more standard intrinsic functions would be better.  The problem is that this 35-year-old application that came from VMS assumes, in many places, that real-world time in expressed as seconds since midnight, and was using SECNDS() decades before I became involved.  I'm not surprised that the function has not changed, but I'm just reporting what I saw.  Maybe we're the first application that uses it to run overnight.

I will look into a more standard solution.

[TimP]

If you switch to SYSTEM_CLOCK, you should take advantage of the feature of allowing INT(INT64) (or, recently, floating point data types), so it doesn't over-run.31-bit differences.  INT64 also improves resolution of SYSTEM_CLOCK (except under ifort Windows).

VMS Fortran adopted a subset of DATE_AND_TIME in 1999 since the pre-standard date functions couldn't support Y2K readiness.  We added it to g77 then as well, and changed the timer functions in all of my employer's applications.  So having an application still running on VAX didn't require use of unsatisfactory time/date.

[Steven_L_Intel1]

It would be interesting to see a test case that calls both SECNDS and DATE_AND_TIME at intervals and shows the output across the midnight boundary. Looking at the code for SECNDS I can't see how it could return anything from a previous call.

[jayb]

Just finishing up my work trip to a classified facility. I will try this next week.  Thanks.

[jayb]

Just got back to work, and the first thing I wanted to do is verify my findings.  I also heard from another developer that he saw this bug with ifort v15 update 2 on Red Hat 5.  

Consider the following trivial test program:

program sec
use ifport
implicit none
do
   print *, secnds(0.0)
   call sleepqq(2000)
end do
end

I compiled the file, sec.f90, and linked the program with no special options.  Than, as root, I entered:

# date --set="Mon Dec 14 23:59:45 PST 2015"
# hwclock --systohc

Here is the program output:

   86388.73    

   86390.73    

   86392.73    

   86394.73    

   86396.73    

   86398.73    

   86398.73    

   86398.73    

   86398.73    

and so ad infinitum.  Once we reach 86400.00 seconds past midnight, the result never changes.

I will look at alternatives, unless a workaround to "re-set" SECNDS() can be offered.

Jay

[jayb]

Note:  The spaces between the output lines was a cut-and-paste issue.
j

[Steven_L_Intel1]

Ok, thanks. We'll check into this.

[jayb]

fwiw, the DATE_AND_TIME solution "cycles back" as expected -- but the code is more involved, of course, as I have to use the last 4 elements of the system time to compute real seconds since midnight.  Not a problem; I'll go with DATE_AND_TIME, which is already used elsewhere in the application.

j

[Steven_L_Intel1]

I would recommend SYSTEM_CLOCK for timing. Very similar logic to SECNDS without worrying about midnight.

[Steven_L_Intel1]

I can reproduce this on both Linux and Windows, and have escalated the problem to development as issue DPD200379912.

On further investigation I find that the code for SECNDS was significantly rewritten for the 15.0 release (I think). There is conditional code that implements "long interval" support that appears to "remember" past calls. The comments suggest this is disabled, but maybe not. In my view, such an enhancement actually breaks the documented behavior of SECNDS, but I am sure that this change was prompted by some other customer asking for such support. (I think the code is incorrect for the stated purpose, though I am not certain of this.)

Thanks for letting us know about the bug. I do recommend using SYSTEM_CLOCK instead of SECNDS. It isn't difficult to swap this in for where you had SECNDS if you are timing things. (If you really do want to know time since midnight, you can use DATE_AND_TIME's VALUES argument for that, though it's not as simple.)

[jayb]

Glad to contribute!

The application really does want to know the integer milliseconds since midnight (it's even documented in the code that had been calling SECNDS), so I implemented a solution using DATE_AND_TIME.  It wasn't really that difficult; in fact, other places in the app were already calling it for the CHARACTER data.  So now we're using the last 4 elements of the integer array, and doing a little multiplication and division.

Jay

[Steven_L_Intel1]

I expect the SECNDS problem to be fixed in 16.0.2, planned for February. While the "long interval" code I found had indeed been disabled, the remaining code did not correctly take into account spanning midnight and was more complex than necessary. It has been simplified and corrected.