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.
Confusion about time units in forcing file
Re: Confusion about time units in forcing file
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":I have:
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.
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
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" ;
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.
Re: Confusion about time units in forcing file
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.
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.
Re: Confusion about time units in forcing file
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:
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 ...
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.
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:
This initial day is day "4900" in ROMS' mind.NLM: GET_STATE - Read state initial conditions, t = 4900 00:00:00
(Grid 01, File: CBOFS2_ini_synoptic_do.nc, Rec=0001, Index=1)
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 ...
... ROMS indicates it believes the time span in the forcing file isMy 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
so forcing times start at zero, not 4900.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
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
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu
Re: Confusion about time units in forcing file
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
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
Re: Confusion about time units in forcing file
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.
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.