A little bug in get_cycle.F of src 884 and the fixing

[yang]

In the version of svn 884, when i run the model with the climatology forcing data, i get an error as follows:
Found Error: ** Line: 2240 Source: ROMS/Modules/mod_netcdf.F, netcdf_get_fvar

NETCDF_GET_FVAR_0D - error while reading variable: river_time
in input file: ../00_ECS_SCS/ECS_SCS_riv_clim.nc
call from: ROMS/Utility/get_cycle.F
Found Error: 02 Line: 182 Source: ROMS/Utility/get_ngfld.F

GET_NGFLD - error while reading variable: river_time at TIME index = 0
Found Error: 02 Line: 99 Source: ROMS/Nonlinear/get_data.F
Found Error: 02 Line: 767 Source: ROMS/Nonlinear/initial.F
Found Error: 02 Line: 188 Source: ROMS/Drivers/nl_ocean.h

In the lines 240 to 256 of get_cycle.F, Tstr and Tindex are not defined when UpperBound is true.
If we define these values as following after line 252, the error disappears.
ELSE IF (LowerBound) THEN
Tstr=Tmax
Tindex=ntime
ELSE IF (UpperBound) THEN
Tstr=Tmax
Tindex=ntime

[arango]

Something is weird here. It doesn't make sense to me. Notice that the logic in get_cycle.F that set the switches is:

Code: Select all

!
!  Is the model time inside the data time range? If not, check if the
!  data just has the LOWER- or the UPPER-snapshot interpolant.
!
      IF ((Tmin.le.mday).and.(mday.le.Tmax)) THEN
        Linside=.TRUE.
      ELSE IF (mday.ge.Tmax) THEN
        LowerBound=.TRUE.
      ELSE IF (mday.le.Tmin) THEN
        UpperBound=.TRUE.
      END IF

That is, the model time in days is within the minimum and maximum time in the data (Linside=TRUE), is greater than the maximum value of the data (LowerBound=TRUE), or is less than the minimum value of the data (UpperBound=TRUE). Notice that I am using .le. and .ge. for peculiar logic when running the adjoint model backward in time. The Linside switch is the first conditional and includes the Tmin and Tmax values because of the less and equal operator (.le.). When running the nonlinear model (job.gt.0), which is your case, we are time-stepping forward in time, and only the Linside and LowerBound switch are possible. You added logic for UpperBound indicating that the current model time is less than the minimum range of your river time data. You don't need to change ROMS, but provide the river data that include the time range of your simulation.

Is you river data included in several NetCDF files? or does the river_time NetCDF variables includes the cycle_length attribute indicating perpetual forcing data?

In the past, I have the river forcing as part of atmospheric structure FRC. Nowadays, it has its own SSF structure. I need to check the river data file(s) in check_multifile.F, so it is clear at initialization if data is available for the simulation time window. I need to update that routine to do the checking of river data file(s).

[yang]

My case is that the river_time is at the middle date of each month, for example [15, 45, 75, 105, 135, 165, 195, 225, 255, 285, 315, 345], and the river_time has a cycle_length attribute(cycle_length=360 days).
Thus, when we start to run the model from 0.0 day, we need the river discharges at 0.0 day. To get the river discharges at the 0.0 day, we need the discharges at the 15th and 345th(Tstr=nitime)days to do the linear interpolation because of cycle_length =360.
Thus,
ELSE IF (mday.le.Tmin) THEN
UpperBound=.TRUE.
Then, we need to add the following statement after line 252,
ELSE IF (UpperBound) THEN
Tstr=Tmax
Tindex=ntime

In the earlier versions, for example src 873, it works well for my case, because the code reads as follows
IF ((mday.lt.Tmin).or.(mday.ge.Tmax)) THEN
Tindex=ntime
Tstr=Tmax

[kate]

I'm having the same problem and will watch it more in the debugger on Monday. Meanwhile, I reverted to a prior code to get back to running.

What I do know is that in the good code, I'm reading the variable at ifield 219 while the bad code has variable 220. The Iinfo and friends are correct for variable 219, but not variable 220.

[arango]

Do you have the cycle_length attribute in the time variable?

For the forward time-stepping, we can also have the following logic in get_cycle.F:

Code: Select all

        IF (job.gt.0) THEN     ! forward:   Tval(i) =< mday =< Tval(i+1)
          IF (Linside) THEN
            tstart=Tmin
            DO i=2,ntime
              IF ((tstart.le.mday).and.(mday.le.Tval(i))) THEN
                Tstr=tstart
                Tindex=i-1     ! one is added when processing
                EXIT
              END IF
              tstart=Tval(i)
            END DO
          ELSE
            Tstr=Tmax
            Tindex=ntime
          END IF
        ELSE                   ! backward:  Tval(i) =< mday =< Tval(i+1)
          ...
        END IF
      END IF

That is, we can have the ELSE conditional that works for multi files and time cycling. The other logic doesn't matter unless that you run the adjoint model. In the nonlinear model (forward time-stepping), we always need to read the LowerBound and then the UpperBound interpolant regardless of multifile data or not. If this is the case, the time interpolation weights (fac1 and fact2) are always positive. If not, something is wrong with the logic or the monotonicity of the data time coordinate.

[yang]

Yes, i have the cycle_length attribute in the time variable (river_time). I agree with you that

we can have the ELSE conditional that works for multi files and time cycling

.