bug concerning: "starting time for variable X is greater..."

[jpm]

This is a bug concerning the current version of ROMS (Version 396 2009-09-11 18:53:38Z) but it also affects earlier versions at least dating back to September 1st.

The error I get when trying to run ROMS is:

GET_CYCLE - starting time for variable: river
is greater than current model time.
TMIN = 1.0000 TDAYS = 0.0000

It seems like for the variable 'river' ROMS finds TMIN = 1 even though river_time in my netcdf file goes all the way from -1096 to 933 and the model start date lies somewhere in the middle. I've checked my varinfo.dat and river forcing files which are correct (and are working with older versions of ROMS).

So I opened the debugger and started to investigate. I think the following problem occurs:

(1) ROMS reads the varinfo.dat, containing

Code: Select all

'river_Xposition'                                  ! Input
  'river runoff  XI-positions at RHO-points'
  'nondimensional'                                 ! [nondimensional]
  'river_Xposition, scalar'
  'river'
  'idRxpo'
  'nulvar'
  1.0d0

where (in line 5) 'river' is specified as the variable's dimension. This corresponds to the info in my netcdf river file:

Code: Select all

        double river_Xposition(river) ;
                river_Xposition:long_name = "river XI-position at RHO-points" ;
                river_Xposition:units = "nondimensional" ;
                river_Xposition:valid_min = 1. ;
                river_Xposition:valid_max = 159. ;
                river_Xposition:field = "river_Xposition, scalar" ;

'river' is indeed the dimension of river_Xposition but it is important to note that 'river' is not a time dimension (the rivers' positions are static), instead it is the "river runoff identification number". The values for river in my netcdf file are

Code: Select all

 river = 1, 2, 3, 4, 5, 6, 7 ;

for the 7 rivers in that specific domain (ESPRESSO).

(2) ROMS calls the subroutine get_ngfld (ROMS/Utility/get_ngfld.F) with the index (ifield) corresponding to the variable 'river_Xposition'. Within that routine the dimension of 'river_Xposition' is queried and falsely assumed to be a time dimension. The name of that dimension, 'river', is copied into into the variable Tname:

ROMS/Utility/get_ngfld.F (line 158 ff)

Code: Select all

          IF (foundit) THEN
            IF (LEN_TRIM(Vname(5,ifield)).gt.0) THEN
              Tname(ifield)=TRIM(Vname(5,ifield))
              ...

Then get_cycle is called from within get_ngfld, where the values for 'river' are queried from the netcdf file. The minimum and maximum "time" variables Tmin and Tmax in get_cycle are set to 1 and 7 respecively, which corresponds to the river entries in the netcdf file. Finally Tmin is compared to the current model time (smday) which is 0 and the error is thrown.

ROMS/Utility/get_cycle.F (line 174 ff)

Code: Select all

      IF (INDEX(TRIM(TvarName),'period').eq.0) THEN
         IF (.not.cycle.and.(ntime.gt.1)) THEN
           IF (smday.lt.Tmin) THEN
             IF (Master) WRITE (stdout,20) TRIM(TvarName), Tmin, smday
             exit_flag=2
             RETURN
           END IF
         END IF
       END IF

In summary, 'river' is falsely believed to be a time dimension and its values (river runoff identification numbers) are compared to the current model time.

NOTE: the same error would have occurred earlier with the variable 'tide_period' but there is a safeguard in the above code that prevents variables containing the name 'period' to throw that error.

PS: No, I have not tried to rename my variable to 'river_period' yet.

[kate]

Wow, good one. Sorry, I'm not using the rivers in my current application.

[arango]

Yes, let me look at this problem. I will try to find a solution. By the way, do you have a river_time variable in the NetCDF file.

[jpm]

Yes, there is a river_time variable in the river file. Like I mentioned, it runs from -1096 to 933 and the appropriate variables are river_time dependent.

[arango]

I added the timeless logic in get_cycle.F to include the variables with the river dimension. Check the following trac ticket for more details. Please update your code and thank you for reporting this problem.

[jpm]

In the new version the error has disappeared. Thanks for the quick fix!