New time format fails on negative times

[m.hadfield]

I've discovered a (minor) problem with the new "days hh:mm:ss" format for printing out times. It fails when time is negative. For example, here is what GET_NGFLD reports when reading data with a time stamp of -47.5325 days

Code: Select all

    GET_NGFLD   - free-surface western boundary condition,   t =   -47 **:**:**
                   (File: roms_bry.nc, Rec=0001, Index=2)
                   (Tmin=        -47.5325 Tmax=       1143.2825)
                   (Min =  5.09364419E-02 Max =  8.56075361E-02)

With some compilers this sort of thing could lead to a run-time error, though it didn't in this case.

Question: what should it read? Or, take the simpler value of -47.5 days, should this be written as "-47 12:00:00" (12 hours before -47 days) or as "-48 12:00:00" (12 hours after -48 days)? I think the latter is more intuitive.

[arango]

Yes, good point. I didn't considered negative times.

Question: what should it read? Or, take the simpler value of -47.5 days, should this be written as "-47 12:00:00" (12 hours before -47 days) or as "-48 12:00:00" (12 hours after -48 days)? I think the latter is more intuitive.

I agree that -48 12:00:00 is more intuitive. You picked up an easy number. I was wondering about -47.25, do you get -48 06:00:00 or -48 18:00:00 ?

If I run the upwelling test starting at day -1 (DSTART=-1.0), I get:

Code: Select all

   STEP   Day HH:MM:SS  KINETIC_ENRG   POTEN_ENRG    TOTAL_ENRG    NET_VOLUME

      0    -2 00:00:00  0.000000E+00  6.579497E+02  6.579497E+02  3.884376E+11
      1    -1 23:55:00  3.268255E-13  6.579497E+02  6.579497E+02  3.884376E+11
      2    -1 23:50:00  6.503587E-12  6.579497E+02  6.579497E+02  3.884376E+11
      3    -1 23:45:00  4.592307E-11  6.579497E+02  6.579497E+02  3.884376E+11
      4    -1 23:40:00  1.649634E-10  6.579497E+02  6.579497E+02  3.884376E+11

...

    286    -1 00:10:00  5.268840E-04  6.579497E+02  6.579502E+02  3.884376E+11
    287    -1 00:05:00  5.325626E-04  6.579497E+02  6.579502E+02  3.884376E+11
    288     0 00:00:00  5.382882E-04  6.579497E+02  6.579503E+02  3.884376E+11
    289     0 00:05:00  5.440612E-04  6.579497E+02  6.579503E+02  3.884376E+11
    290     0 00:10:00  5.498816E-04  6.579497E+02  6.579503E+02  3.884376E+11
    291     0 00:15:00  5.557496E-04  6.579497E+02  6.579503E+02  3.884376E+11
    292     0 00:20:00  5.616654E-04  6.579497E+02  6.579503E+02  3.884376E+11

Notice that I don't get a smooth transition at day zero. The above numbers are obtained when I introduced the following change to subroutine time_string:

Code: Select all

      iday=INT(time/86400.0_r8)
      IF (time.lt.0.0_r8) THEN
        isec=INT(iday*86400.0_r8-time)
        iday=iday-1
      ELSE
        isec=INT(time-iday*86400.0_r8)
      END IF
      ihour=isec/3600
      minute=MOD(isec,3600)/60
      isec=MOD(isec,60)
!
      WRITE (text,10) iday, ihour, minute, isec
 10   FORMAT (i5,1x,i2.2,':',i2.2,':',i2.2)
      time_code=text

I need to think more about this. So the option -48 12:00:00 is kind of problematic.