Possible (minor?) bug in wrt_ini.F

Bug reports, work arounds and fixes

Moderators: arango, robertson

Post Reply
Message
Author
stef
Posts: 175
Joined: Tue Mar 13, 2007 6:38 pm
Location: Independent researcher
Contact:

Possible (minor?) bug in wrt_ini.F

#1 Unread post by stef »

I have been using ocean_time units of

Code: Select all

'days since 1970...'
for some time now in the initial conditions netcdf. This worked (even though in varinfo.yaml the units are s). However it does not seem to work when using 4dvar, because the updated initial conditions are always written in seconds (I think at line 205 wrt_ini.F in git version 441de0de146 a.k.a. src:ticket:918).

User avatar
arango
Site Admin
Posts: 1347
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Possible (minor?) bug in wrt_ini.F

#2 Unread post by arango »

Never in the history of ROMS ocean_time had units of days, It is always seconds because ROMS state has MKS units. That said, the procedure netcdf_get_time in mod_netcdf.F is smart enough to make a conversion if the units attribute is correctly specified in the NetCDF file.

The initial ROMS NetCDF file for all the ROMS kernels must always be in seconds. It is not a bug! It is a matter of precision.

stef
Posts: 175
Joined: Tue Mar 13, 2007 6:38 pm
Location: Independent researcher
Contact:

Re: Possible (minor?) bug in wrt_ini.F

#3 Unread post by stef »

So this is intended behaviour: The units of ocean_time in the ini files can be 'days' when doing forward runs, but *must* be 'seconds' when doing 4dvar runs, otherwise the program will error at runtime (after multiple timesteps have already been performed).

Okay, thanks for the clarification!

Post Reply