cycle_length for non-360days/yr monthly forcing files?
-
- Posts: 12
- Joined: Mon May 15, 2006 1:18 pm
- Location: Scripps Institution of Oceanography
cycle_length for non-360days/yr monthly forcing files?
Hi,
I'm trying to run a simulation with monthly NCEP winds and monthly boundary conditions for the time period 1980/1/1 - 1990/12/31. Since the actual year, month and day is important, I thought it might be best to use TIME_REF=-2 and DSTART=2444240 (Julian day for Jan. 1, 1980).
For the initial file, ocean_time=2444240.
As for the forcing and boundary files, sms_time = bry_time = 2444254, 2444285, 2444314, ......, 2448211, 2448241 which is the Julian day for the 15th of each month from Jan. 1980 to Dec. 1990.
I can't figure out the cycle_length to use since this is not strictly 360days/year or 365.25days/year, but that it is generally 365days/year and 366days/year for leap years. Can anyone suggest what I could do with the cycle_length, or even changes beforehand to match the times?
Thank you so much in advance for your time and suggestions.
Cheers,
Dian Putrasahan
I'm trying to run a simulation with monthly NCEP winds and monthly boundary conditions for the time period 1980/1/1 - 1990/12/31. Since the actual year, month and day is important, I thought it might be best to use TIME_REF=-2 and DSTART=2444240 (Julian day for Jan. 1, 1980).
For the initial file, ocean_time=2444240.
As for the forcing and boundary files, sms_time = bry_time = 2444254, 2444285, 2444314, ......, 2448211, 2448241 which is the Julian day for the 15th of each month from Jan. 1980 to Dec. 1990.
I can't figure out the cycle_length to use since this is not strictly 360days/year or 365.25days/year, but that it is generally 365days/year and 366days/year for leap years. Can anyone suggest what I could do with the cycle_length, or even changes beforehand to match the times?
Thank you so much in advance for your time and suggestions.
Cheers,
Dian Putrasahan
Re: cycle_length for non-360days/yr monthly forcing files?
When you say monthly, do you mean you have each individual month or do you have a generic January that is for all Januaries? If it's the first, you don't want to set cycle_length at all. If it's the second, I don't see that 365.25 is going to be so very terrible. It's not like you are picking up the individual storms on their specific dates.
-
- Posts: 12
- Joined: Mon May 15, 2006 1:18 pm
- Location: Scripps Institution of Oceanography
Re: cycle_length for non-360days/yr monthly forcing files?
Hi Kate,
Thank you for replying. I do have the fields for each individual months, it's not generic. So would ROMS automatically interpolate between each relevant two months to provide the forcing and boundary conditions that is appropriate for each day? Thanks.
Cheers,
Dian
Thank you for replying. I do have the fields for each individual months, it's not generic. So would ROMS automatically interpolate between each relevant two months to provide the forcing and boundary conditions that is appropriate for each day? Thanks.
Cheers,
Dian
Re: cycle_length for non-360days/yr monthly forcing files?
Yes, that's what ROMS does. It reads in all the times in your forcing/boundary files during the initialization and uses the appropriate records from those files.
-
- Posts: 12
- Joined: Mon May 15, 2006 1:18 pm
- Location: Scripps Institution of Oceanography
Re: cycle_length for non-360days/yr monthly forcing files?
Fantastic. Thank you so much.
Cheers,
Dian
Cheers,
Dian
- m.hadfield
- Posts: 521
- Joined: Tue Jul 01, 2003 4:12 am
- Location: NIWA
Re: cycle_length for non-360days/yr monthly forcing files?
You're going to need some data before 1980-01-15 and after 1990-12-15 to run your simulation right through, because when cycle_length is not set, ROMS only interpolates in time, it doesn't extrapolate. The simplest solution is to provide data for Dec 1979 and Jan 1991 as well.dputrasahan wrote:I'm trying to run a simulation with monthly NCEP winds and monthly boundary conditions for the time period 1980/1/1 - 1990/12/31. Since the actual year, month and day is important, I thought it might be best to use TIME_REF=-2 and DSTART=2444240 (Julian day for Jan. 1, 1980).
For the initial file, ocean_time=2444240.
As for the forcing and boundary files, sms_time = bry_time = 2444254, 2444285, 2444314, ......, 2448211, 2448241 which is the Julian day for the 15th of each month from Jan. 1980 to Dec. 1990.
(Added later): apropos of which...
viewtopic.php?t=887
Re: cycle_length for non-360days/yr monthly forcing files?
If you have 10 years of data, you can make cycle_length = 3652.5 and ROMS will cycle the times and all data if it starts before 1980/1/1 or runs beyond 1990/12/31.
We did this with 2 years of met data that we wanted to cycle over for a long 5 year run of the EAC model (published in Wilkin, J., and W. Zhang, (2006), Modes of mesoscale sea surface height and temperature variability in the East Australian Current, Journal of Geophysical Research, 112, C01013, doi:10.1029/2006JC003590.)
We did this with 2 years of met data that we wanted to cycle over for a long 5 year run of the EAC model (published in Wilkin, J., and W. Zhang, (2006), Modes of mesoscale sea surface height and temperature variability in the East Australian Current, Journal of Geophysical Research, 112, C01013, doi:10.1029/2006JC003590.)
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
-
- Posts: 12
- Joined: Mon May 15, 2006 1:18 pm
- Location: Scripps Institution of Oceanography
Re: cycle_length for non-360days/yr monthly forcing files?
Thank you for pointing out that ROMS only interpolate in time and not extrapolate it. That would really help me prevent an error there.
Another quick question, as I set up the forcing files, I realize that while I have individual monthly files for winds and SST, I only have monthly climatological files for shflux, swflux, swrad, and SSS. I suppose having cycle_length =365.25 days wouldn't be terrible, but since TIME_REF=-2, how should I assign shf_time, swf_time, srf_time and sss_time?
Could I just use [15.21875 : 30.4375 : 15.21875+30.4375*11]? Or does it have to be in Julian days? Say [2444254 : 30.4375 : 2444589] (this represents Jan.15 to Dec.15 of the year 1980). Or would it be something else? Thank you so much for all your help.
Cheers,
Dian
Another quick question, as I set up the forcing files, I realize that while I have individual monthly files for winds and SST, I only have monthly climatological files for shflux, swflux, swrad, and SSS. I suppose having cycle_length =365.25 days wouldn't be terrible, but since TIME_REF=-2, how should I assign shf_time, swf_time, srf_time and sss_time?
Could I just use [15.21875 : 30.4375 : 15.21875+30.4375*11]? Or does it have to be in Julian days? Say [2444254 : 30.4375 : 2444589] (this represents Jan.15 to Dec.15 of the year 1980). Or would it be something else? Thank you so much for all your help.
Cheers,
Dian
- m.hadfield
- Posts: 521
- Joined: Tue Jul 01, 2003 4:12 am
- Location: NIWA
Re: cycle_length for non-360days/yr monthly forcing files?
What I have done in this situation, and what I recommend you do, is set
DSTART = 0.0d0 ! days
TIME_REF = 19800101.0d0 ! yyyymmdd.dd
then express the times for SST & wind in days since 1980-01-01 and the times for shflux, swflux, swrad, and SSS relative to the start of a generic year, which as you say would be [15.21875 : 30.4375 : 15.21875+30.4375*11] for monthly data.
BTW: as an aid to memory you can set the units attribute for the SST and wind variables to "days since 1980-01-01". However ROMS will ignore the "since 1980-01-01" bit so you have to make sure your set TIME_REF & DSTART properly. And once you've got ROMS going, have a good look at the output to see that forcing data are being loaded when you expect.
BTW2: I prefer to use a separate file for each forcing variable
DSTART = 0.0d0 ! days
TIME_REF = 19800101.0d0 ! yyyymmdd.dd
then express the times for SST & wind in days since 1980-01-01 and the times for shflux, swflux, swrad, and SSS relative to the start of a generic year, which as you say would be [15.21875 : 30.4375 : 15.21875+30.4375*11] for monthly data.
BTW: as an aid to memory you can set the units attribute for the SST and wind variables to "days since 1980-01-01". However ROMS will ignore the "since 1980-01-01" bit so you have to make sure your set TIME_REF & DSTART properly. And once you've got ROMS going, have a good look at the output to see that forcing data are being loaded when you expect.
BTW2: I prefer to use a separate file for each forcing variable
-
- Posts: 34
- Joined: Sat Sep 08, 2012 2:15 pm
- Location: Ocean University Of Cina
Re: cycle_length for non-360days/yr monthly forcing files?
Hi Kate,If I have a generic January that is for all Januaries ,the cycle_length you say that 365.25 won't be so terrible ?kate wrote:When you say monthly, do you mean you have each individual month or do you have a generic January that is for all Januaries? If it's the first, you don't want to set cycle_length at all. If it's the second, I don't see that 365.25 is going to be so very terrible. It's not like you are picking up the individual storms on their specific dates.
I have a application that applied dalily boundary conditions,But I only have 366 days of 2012.
I set
Code: Select all
DSTART = 0.0d0 ! days
TIDE_START = 0.0d0 ! days
TIME_REF = 20120101.00d0 ! yyyymmdd.dd
Code: Select all
BRYNAME == /public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_01_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_02_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_03_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_04_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_05_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_06_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_07_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_08_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_09_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_10_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_11_bry.nc |
/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_12_bry.nc
I want to model 10 years and use a generic day boundary condiation. But the model stop after one year 366 days. It seems that ROMS can't read
again and I have the log output/public/home/ych/meng/Projects/bhd3/boundary/bhd_2012_01_bry.nc |
.NETCDF_OPEN - unable to open existing NetCDF file:
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@À°<91>^D^@^@^@^@^@^@^@^@ RSTNAME == out3/bhd_rst.nc A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@±<91>^D^@^@^@^@^@^@^@^@^@^@^@^@NAME == out3/bhd_rst.nc A^@^@^@^@^@^@^@ð°<91>^D^@^@^@^@@±<91>^D^@^@^@^@^@^@^@^@^@^@^@^@ ^Q^O^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80>±<91>^D^@^@^@^@E^@^@^@ÿÿÿÿF^@^@^@G^@^@^@
call from: inquire.F
I think this may be the cycle_length attribute problem ?
I nndump the bry.nc and find
It seems that I have set the cycle_length to 366 day. But ROMS can't cycle to read the daily condiations. What may be the problem ? Thank you for reply !double salt_time(salt_time) ;
salt_time:long_name = "time for salinity climatology" ;
salt_time:units = "day since 2012.01.01" ;
salt_time:calendar = "366.0 days in every year" ;
salt_time:cycle_length = 366. ;
double temp_time(temp_time) ;
temp_time:long_name = "time for temperature climatology" ;
temp_time:units = "day" ;
temp_time:calendar = "366.0 days in every year" ;
temp_time:cycle_length = 366. ;
double zeta_time(zeta_time) ;
zeta_time:long_name = "time for sea surface height" ;
zeta_time:units = "day" ;
zeta_time:calendar = "366.0 days in every year" ;
zeta_time:cycle_length = 366. ;
double v3d_time(v3d_time) ;
v3d_time:long_name = "time for 3D velocity climatology" ;
v3d_time:units = "day" ;
v3d_time:calendar = "366.0 days in every year" ;
v3d_time:cycle_length = 366. ;
double v2d_time(v2d_time) ;
v2d_time:long_name = "time for 2D velocity climatology" ;
v2d_time:units = "day" ;
v2d_time:calendar = "366.0 days in every year" ;
v2d_time:cycle_length = 366. ;