Problem - forcing time step drifts after a while

General scientific issues regarding ROMS

Moderators: arango, robertson

Post Reply
Message
Author
moritz.wandres
Posts: 21
Joined: Fri Mar 15, 2013 1:30 pm
Location: UWA Oceans Institute

Problem - forcing time step drifts after a while

#1 Unread post by moritz.wandres »

Hi,

I have a problem with the time step in my forcing files. I force my model with hourly wind stress data (amongst other parameters, but wind is the one I am having troubles with). I save the hourly output into a his file. Generally, this should look like this - it writes the history fields and then reads the wind data.

Code: Select all

37980    17 14:00:00  1.131793E-02  9.759933E+03  9.759945E+03  7.130870E+14
          (658,089,02)  6.483382E-03  6.013216E-02  8.986419E-02  1.737858E+00
      WRT_HIS   - wrote history  fields (Index=1,1) into time record = 0000062
    GET_2DFLD   - surface u-momentum stress,                 t =    17 15:00:00
                   (Rec=0000051, Index=2, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min = -6.20686378E-05 Max =  2.05079991E-05)
    GET_2DFLD   - surface v-momentum stress,                 t =    17 15:00:00
                   (Rec=0000051, Index=2, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min =  3.52449282E-06 Max =  1.80098321E-04)
  37981    17 14:00:40  1.131755E-02  9.759932E+03  9.759943E+03  7.130868E+14
          (658,089,02)  6.493260E-03  6.013627E-02  8.986523E-02  1.738505E+00
 
Now after a while, I noticed that the time step in the input data seems to drift - it reads the new wind data one time step before writing the history fields.

Code: Select all

 38159    17 15:59:20  1.121282E-02  9.759445E+03  9.759456E+03  7.130385E+14
          (658,089,02)  7.599435E-03  5.546764E-02  7.901981E-02  1.818735E+00
    GET_2DFLD   - surface u-momentum stress,                 t =    17 17:00:00
                   (Rec=0000053, Index=2, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min = -5.52865726E-05 Max =  3.50237938E-05)
    GET_2DFLD   - surface v-momentum stress,                 t =    17 17:00:00
                   (Rec=0000053, Index=2, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min =  9.49741635E-07 Max =  1.56484781E-04)
  38160    17 16:00:00  1.121220E-02  9.759441E+03  9.759452E+03  7.130381E+14
          (658,089,02)  7.605224E-03  5.541070E-02  7.889061E-02  1.819470E+00
      WRT_HIS   - wrote history  fields (Index=1,1) into time record = 0000064
  38161    17 16:00:40  1.121159E-02  9.759437E+03  9.759449E+03  7.130377E+14
          (658,089,02)  7.610932E-03  5.535294E-02  7.875988E-02  1.820202E+00
  

I force the model with multiple wind files, the first one ends at 15.5 days and the second one starts at 15.5 days and 1 hour, the switch between writing and reading happens after 17 days and 15 hours. I also noticed that before the switch occurs, some time steps read 1 second less than what it should be

Code: Select all

38070    17 15:00:00  1.127038E-02  9.759732E+03  9.759743E+03  7.130677E+14
          (658,089,02)  7.065296E-03  5.917806E-02  8.663790E-02  1.771234E+00
      WRT_HIS   - wrote history  fields (Index=1,1) into time record = 0000063
    GET_2DFLD   - surface u-momentum stress,                 t =    17 15:59:59
                   (Rec=0000052, Index=1, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min = -6.01463465E-05 Max =  2.65203679E-05)
    GET_2DFLD   - surface v-momentum stress,                 t =    17 15:59:59
                   (Rec=0000052, Index=1, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min =  2.61984313E-06 Max =  1.63034716E-04)
    GET_2DFLD   - surface air pressure,                      t =    17 18:00:00
                   (Rec=0000143, Index=1, File: slp_660_1.nc)
                   (Tmin=          0.0000 Tmax=        120.0000)
                   (Min =  1.01034822E+03 Max =  1.02795589E+03)
  38071    17 15:00:40  1.126974E-02  9.759729E+03  9.759741E+03  7.130675E+14
          (658,089,02)  7.074547E-03  5.915217E-02  8.658294E-02  1.771600E+00
It should be t= 17 16:00:00 instead of 17 15:59:59.

First I assumed it was a rounding error somewhere in the code so I changed sms_time from days to seconds. It didn't help. In both runs the change between reading and writing occurs at the same time. When I use 3-hourly wind fields this problem does not occur.

Here is the ncdump of my wind file

Code: Select all

nc{'sms_time'} = ncdouble('sms_time'); %% 372 elements.
nc{'sms_time'}.units = ncchar(''seconds since 2011-01-01 00:00:00'');
nc{'sms_time'}.cycle_length = ncdouble(1);
nc{'sms_time'}.long_name = ncchar(''surface momentum stress time'');
nc{'sms_time'}.field = ncchar(''time, scaler, series'');
 
nc{'sustr'} = ncdouble('sms_time', 'eta_u', 'xi_u'); %% 161797680 elements.
nc{'sustr'}.long_name = ncchar(''surface u-momentum stress'');
nc{'sustr'}.units = ncchar(''Newton meter-2'');
nc{'sustr'}.field = ncchar(''time, scaler, series'');
 
nc{'svstr'} = ncdouble('sms_time', 'eta_v', 'xi_v'); %% 161797680 elements.
nc{'svstr'}.long_name = ncchar(''surface v-momentum stress'');
nc{'svstr'}.units = ncchar(''Newton meter-2'');
nc{'svstr'}.field = ncchar(''time, scaler, series'');
The model then stops at the end of the second wind file

Code: Select all

 66869    30 22:59:20  1.250382E-02  9.758100E+03  9.758113E+03  7.129026E+14
          (303,131,27)  3.552772E-02  4.469029E-02  4.346825E-03  1.761728E+00
    GET_2DFLD   - surface u-momentum stress,                 t =    31 00:00:00
                   (Rec=0000372, Index=1, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min = -1.28229279E-04 Max =  1.00735645E-07)
    GET_2DFLD   - surface v-momentum stress,                 t =    31 00:00:00
                   (Rec=0000372, Index=1, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min =  1.57125796E-08 Max =  1.50005876E-04)
  66870    30 23:00:00  1.250372E-02  9.758101E+03  9.758113E+03  7.129026E+14
          (303,131,27)  3.555137E-02  4.467106E-02  4.347965E-03  1.761094E+00
      WRT_HIS   - wrote history  fields (Index=1,1) into time record = 0000023
  66871    30 23:00:40  1.250363E-02  9.758101E+03  9.758114E+03  7.129027E+14
          (303,131,27)  3.557501E-02  4.465168E-02  4.348950E-03  1.760443E+00

...

66959    30 23:59:20  1.249512E-02  9.758175E+03  9.758188E+03  7.129111E+14
          (654,101,14)  1.133461E-02  7.481265E-03  6.876530E-02  1.653952E+00
    GET_2DFLD   - surface u-momentum stress,                 t =    15 13:00:00
                   (Rec=0000001, Index=2, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min = -1.37587066E-04 Max =  3.19810309E-06)
    GET_2DFLD   - surface v-momentum stress,                 t =    15 13:00:00
                   (Rec=0000001, Index=2, File: wind_660_hourly_2.nc)
                   (Tmin=         15.5417 Tmax=         31.0000)
                   (Min =  6.50465756E-07 Max =  2.35191210E-04)

 SET_2DFLD  - current model time exceeds ending value for variable: sustr
              TDAYS     =         31.0000
              Data Tmin =         15.5417  Data Tmax =         31.0000
              Data Tstr =         15.5000  Data Tend =         15.5417
              TINTRP1   =         31.0000  TINTRP2   =         16.5417
              FAC1      =        -14.4583  FAC2      =          0.0000

 Elapsed CPU time (seconds):

 Node   #  0 CPU:  240636.915

 ROMS/TOMS - Output NetCDF summary for Grid 01:
             number of time records written in HISTORY file = 00000023
             number of time records written in RESTART file = 00000002
             number of time records written in AVERAGE file = 00000030

 Analytical header files used:

 Node   #  1 CPU:  242843.089
 Node   # 11 CPU:  243082.092
 Node   # 20 CPU:  243248.110
 Node   # 21 CPU:  243311.202
 Node   # 12 CPU:  243087.696
 Node   #  3 CPU:  242938.395
 Node   #  4 CPU:  242823.280
 Node   #  5 CPU:  243146.420
 Node   #  6 CPU:  243165.121
 Node   #  7 CPU:  242816.411
 Node   # 16 CPU:  243138.767
 Node   # 18 CPU:  243328.923
 Node   # 22 CPU:  243183.510
 Node   # 10 CPU:  243001.091
 Node   # 23 CPU:  243193.583
 Node   # 15 CPU:  243058.018
 Node   # 17 CPU:  243341.240
 Node   # 19 CPU:  243368.746
 Node   #  8 CPU:  242778.929
 Node   #  9 CPU:  242838.724
 Node   # 14 CPU:  243012.967
 Node   #  2 CPU:  242821.871
 Node   # 13 CPU:  242905.345
     ROMS/Functionals/ana_btflux.h
     /home/mwandres/ROMS/Projects/sixsixty/ROMS/Run_07/ana_nudgcoef.h

 ROMS/TOMS - Input error ............. exit_flag:   2


 ERROR: Abnormal termination: NetCDF INPUT.
 REASON: No error                                                                        
Has anyone ever seen this problem or does anyone have any idea how to fix it? Thanks.

moritz.wandres
Posts: 21
Joined: Fri Mar 15, 2013 1:30 pm
Location: UWA Oceans Institute

Re: Problem - forcing time step drifts after a while

#2 Unread post by moritz.wandres »

So the reason why the model stops after the 2nd input file is because I defined the cycle length for some reason. Without cycle length = 1 the model should not stop. I'm still unsure about the drift though.

nacholibre
Posts: 81
Joined: Thu Dec 07, 2006 3:14 pm
Location: USGS
Contact:

Re: Problem - forcing time step drifts after a while

#3 Unread post by nacholibre »

I assume the "drift" that you mention is actually because the model needs to read the forcing files ahead of time in order to interpolate them on the computational time step (the time steps of forcing files are usually much larger than the computational time steps).
I also see the 1-sec difference in my log file like you do. I always took it as a round-off error in the output.
But I did not necessarily check the code for any of these assumptions...
Zafer

Post Reply