Custom Query (986 matches)

• Updated Matlab script dayvec.m so it exactly as ROMS routine datevec in module dateclock.F. Mow, it returs more information fields to the output structure. For example:

  % dayvec(daynum(2000,2,28,23,58,45))
  
  ans = 
  
         daynum: 730483.999131944
      leap_year: 'true'
           yday: 59
           year: 2000
          month: 2
            day: 28
           hour: 23
        minutes: 58
        seconds: 45
         string: '2000-02-28 23:58:45.00'
  

• Added new function tround.m to round floating-point numbers using Fuzzy or Tolerant Floor function.

Corrected a bug in module dateclock.F, routine datevec. The date string failed after 2000-02-28 12:30:00:

        12 2000-02-28 12:30:00.00  1.288030E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  1.690266E-06  1.090592E-05  2.506269E-04  5.449963E-02
        13 1999-03-** 12:32:30.00  1.462197E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  1.966928E-06  1.180089E-05  2.717118E-04  5.675077E-02
        14 1999-03-** 12:35:00.00  1.632312E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  2.265510E-06  1.270431E-05  2.934621E-04  5.892863E-02

It looked like a Y2K bug but it was not a Y2K bug type problem. I have an error at the transition between the end of February (28 or 29) and Mar 1 which is the numerical start of esch uear in the Proleptic Calendaras coded in ROMS. Numerically, it is easier to start each year on March 1 and then adjust for leap year or not.

After the correction, I now get the correct date/clock string:

        12 2000-02-28 00:30:00.00  1.288030E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  1.690266E-06  1.090592E-05  2.506269E-04  5.449963E-02
        13 2000-02-28 00:32:30.00  1.462197E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  1.966928E-06  1.180089E-05  2.717118E-04  5.675077E-02
        14 2000-02-28 00:35:00.00  1.632312E-06  1.954312E+04  1.954312E+04  1.659839E+17
                      (001,06,01)  2.265510E-06  1.270431E-05  2.934621E-04  5.892863E-02 

Many thanks to Mark Hadfield for ​bringing this to my attention.

• A bug was corrected in routine obs_write.F to remove global reduction operation for BgThresh. The following statement:

            CALL mp_collect (ng, model, Ncollect, IniVal,                 &
  #    if defined WEAK_CONSTRAINT
       &                     BgThresh(Mstr:))
  #    else
       &                     BgThresh)
  #    endif
  

  is not needed since BgRhresh does no depend on tile partition. Actually, if we make this call its final values are target values times the number of MPI node used because of reduction summation.

Many thanks to Andy Moore for bringing this to my attention.

• I also fixed a typo in tl_pre_step3d.F and rp_pre_step3d.F in the commented nonlinear code.

• Added date string reporting in routines obs_read.F and ad_htobs.F.