Confusion about time units in forcing file

Bug reports, work arounds and fixes

Moderators: arango, robertson

Post Reply
Message
Author
lanerolle
Posts: 157
Joined: Mon Apr 28, 2003 5:12 pm
Location: NOAA

Confusion about time units in forcing file

#1 Unread post by lanerolle »

I have always assumed that the ROMS initialization file needs to give the initialization time in seconds relative to a base date and the times in the forcing files needs to be in days also relative to the same base date.

However, when I run ROMS svn 736 with multiple forcing files (a separate forcing file for Uwind, Vwind, Tair, Pair, Qair, SWrad, LWdown), I get the following error (before the model crashes):

NLM: GET_STATE - Read state initial conditions, t = 4900 00:00:00
(Grid 01, File: CBOFS2_ini_synoptic_do.nc, Rec=0001, Index=1)
- free-surface
(Min = 0.00000000E+00 Max = 0.00000000E+00)
- vertically integrated u-momentum component
(Min = 0.00000000E+00 Max = 0.00000000E+00)
- vertically integrated v-momentum component
(Min = 0.00000000E+00 Max = 0.00000000E+00)
- u-momentum component
(Min = 0.00000000E+00 Max = 0.00000000E+00)
- v-momentum component
(Min = 0.00000000E+00 Max = 0.00000000E+00)
- potential temperature
(Min = 1.04144697E+01 Max = 2.14165974E+01)
- salinity
(Min = 0.00000000E+00 Max = 3.36738510E+01)

CHECK_MULTIFILE - Error while checking input Forcing file:
Input/CBOFS2_forcing_surface_synoptic_Uwind.nc
last data time record available is for day: 0 01:35:23
but data is needed to finish run until day: 4901 00:00:00

My time vector in the forcing file Input/CBOFS2_forcing_surface_synoptic_Uwind.nc is in units of days and spans the values of [4900.000, 5723.000] inclusive. However, as you can see, ROMS assumes that 5723.000 is in units of seconds (thus giving 1 hour, 35 min. and 23 sec) and not days!

Am I doing something wrong or is this a bug in this version of ROMS? Is there a flag to tell ROMS that the times in the forcing files are in days? In the older versions of ROMS, it was assumed that only the initialization file had the time vector in seconds.

Thank you.

User avatar
kate
Posts: 4088
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

Re: Confusion about time units in forcing file

#2 Unread post by kate »

Hi Lyon,

We would need to see the metadata on your forcing file. ROMS searches for the "units" attribute and checks it for the string "second":

Code: Select all

          ELSE IF (TRIM(var_Aname(i)).eq.'units') THEN
            tunits=TRIM(var_Achar(i))
            IF (tunits(1:6).eq.'second') THEN
              Tscale=sec2day
            END IF
          END IF
I have:

Code: Select all

pacman4 233% ncdump -h MERRA_Vwind_3hours_2012.nc
netcdf MERRA_Vwind_3hours_2012 {
dimensions:
	lon = 540 ;
	lat = 361 ;
	wind_time = UNLIMITED ; // (2928 currently)
variables:
	double lon(lon) ;
		lon:long_name = "longitude" ;
		lon:units = "degrees_east" ;
	double lat(lat) ;
		lat:long_name = "latitude" ;
		lat:units = "degrees_north" ;
	double wind_time(wind_time) ;
		wind_time:units = "days since 1900-01-01 00:00:00" ;
		wind_time:calendar = "LEAP" ;
It doesn't find the string "second" and therefore doesn't convert from seconds to days.

ETA: If you didn't change your forcing file, ROMS was probably always doing this conversion, just not checking for falling off the end of the forcing.

Also, we're only searching for "second", not for "sec" or "Sec" or "hour" or anything.

lanerolle
Posts: 157
Joined: Mon Apr 28, 2003 5:12 pm
Location: NOAA

Re: Confusion about time units in forcing file

#3 Unread post by lanerolle »

Here is the ncdump -h of the Uwind forcing file (where the first complaint from ROMS occurs):

netcdf CBOFS2_forcing_surface_synoptic_Uwind {
dimensions:
eta_surf = 91 ;
xi_surf = 179 ;
frc_time = UNLIMITED ; // (19753 currently)
variables:
float frc_time(frc_time) ;
frc_time:long_name = "Surface forcing time" ;
frc_time:units = "Days" ;
frc_time:startdate = "01-Jun-2003" ;
frc_time:enddate = "01-Sep-2005" ;
frc_time:field = "frc_time, scalar, series" ;
float lon_surf(eta_surf, xi_surf) ;
lon_surf:long_name = "Longitude location of surface forcing data points" ;
lon_surf:units = "degrees" ;
float lat_surf(eta_surf, xi_surf) ;
lat_surf:long_name = "Latitude location of surface forcing data points" ;
lat_surf:units = "degrees" ;
float Uwind(frc_time, eta_surf, xi_surf) ;
Uwind:long_name = "Surface u-wind component" ;
Uwind:units = "meter second-1" ;
Uwind:coordinates = "lon_surf lat_surf" ;
Uwind:field = "Uwind, scalar, series" ;
Uwind:time = "frc_time" ;

In addition to my time units being in "Days", I also the the "Uwind.coordinates" attribute because my met forcing is on another coarser grid whose extent is larger than that of the model grid and I get ROMS to do the re-gridding internally.

Lyon.

User avatar
wilkin
Posts: 879
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: Confusion about time units in forcing file

#4 Unread post by wilkin »

Lyon,

ROMS assumes times are expressed with respect to a common base time.

ROMS does not parse the "since ... " part of the netcdf time units attributes and make adjustments to a common time base - not for initial conditions, not for boundary conditions, not for surface forcing, and not for tides. Whatever convention you use in your own mind for time=0 must be common to all forcing files and initial conditions.

In your configuration, ROMS believes the initial conditions are for ocean_time defined thus:
NLM: GET_STATE - Read state initial conditions, t = 4900 00:00:00
(Grid 01, File: CBOFS2_ini_synoptic_do.nc, Rec=0001, Index=1)
This initial day is day "4900" in ROMS' mind.

ROMS does parse the first word of the units attribute ("days" or "seconds") and adjust accordingly, but the string following "since" is ignored on input.

Whilst you say that ...
My time vector in the forcing file Input/CBOFS2_forcing_surface_synoptic_Uwind.nc is in units of days and spans the values of [4900.000, 5723.000] inclusive
... ROMS indicates it believes the time span in the forcing file is
CHECK_MULTIFILE - Error while checking input Forcing file:
Input/CBOFS2_forcing_surface_synoptic_Uwind.nc last data time record available is for day: 0 01:35:23 but data is needed to finish run until day: 4901 00:00:00
so forcing times start at zero, not 4900.

Somehow you have fuddled the base dates of initial and forcing data. They are not consistent.

I notice you have used "Days" as your frc_time units. There is a slim chance that "Days" (capitalized) and "days" are not equivalent. But really a complete self-consistent metadata description should use units of "days since (some base date)" not simply "Days" because that is meaningless in any realistic application.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

User avatar
d.kobashi
Posts: 67
Joined: Tue Sep 28, 2010 11:59 pm
Location: Texas A&M University

Re: Confusion about time units in forcing file

#5 Unread post by d.kobashi »

What are DSTART and TIME_REF in ocean.in?

I had a similar situation recently for bry netcdf files. My problem was that I did not properly set time units in boundary netcdf files.
I set time units as "bry_time:units = days since 1970-01-01 00:00:00" and that did the trick. DSTART was consistent with time in the initial netcdf file.
As John said, "Days" could be "days", but I don't think Fortran cares about that.

For time units of initial netcdf file, I thought the unit depends on varinfo.dat? The default is 'second'. I may be wrong.

-John: it's good to know ROMS does not parse time attribute. I didn't know that. so we can put "days" in time units (or hours or seconds).

Cheers,

DJ

lanerolle
Posts: 157
Joined: Mon Apr 28, 2003 5:12 pm
Location: NOAA

Re: Confusion about time units in forcing file

#6 Unread post by lanerolle »

In my surface forcing NetCDF file(s), I simply changed:

frc_time:units = "Days" ;

to

frc_time:units = "days since 1990-01-01 00:00:00 " ;

and now everything works perfectly!!! I did not realize that ROMS svn 736 was so sensitive to the choice of words used in the units attribute of the forcing files. BTW my base date is indeed 1990/01/01 0000 hrs GMT.

Thanks for all your help,

Lyon.

Post Reply