recycle of forcing for climatological runs

[longmtm]

Dear all,

I'm trying to run ROMS3.0 with a case for the Chesapeake Bay with climatological forcing. I set TIME_REF=-1 so that the model will take 360 day with 12 30-day months as a year.

I have forcings (river, wind, OBC etc) prepared from day -10 to day 368 or so, with days [-10,0] and [360,368] cyclically taken from [350,360] and [0,8] such that the forcings are precisely periodic of 360 days, Yet I want to run the model for multiple years to investigate the climatology of results inside the domain. As a try-out, I ran it for 2 years, and from the screen output, it seems that the model is reading forcings from day 0 to day 368, and after that, I expected the model to read forcings again back from day 0, but it actually seems to have stopped reading forcings cyclically. Question is: is this a problem? Do I need to do some special to make the model read forcings cyclically? Or I have to generate multiple years of forcing even for climatological runs?

To help you understand and assess my Q, here is part the output file :

http://131.118.211.30/chesroms/internal ... cleout.txt

where at line 228, time stepping is restarted, and model starts to read water level BC at line 233 for day t=0.125 (day), At line 773, model has run to the end of the first year (day 360), and reading river forcing for that day. This all seems fine until line 2868, where the last day of available forcing is reached. After that point, I don't see any GET_NGFLD any more and I assume the model is not reading forcing anymore (yet I want the model to cyclically read it back from day 0 for the second year)

Somebody out there to help me out?

Thanks a bunch,

Wen

[jacopo]

add in the forcing netcdf file the attribute 'cycle_length':

for example:

double sms_time(sms_time) ;
sms_time:long_name = "surface momentum stress time" ;
sms_time:units = "day" ;
sms_time:field = "sms_time, scalar, series" ;
sms_time:cycle_length = 360.0 ;

This generates a 360 days perpetual cycling.

J.-

[longmtm]

J, Thanks a lot. I will try it out and report.

Wen

[longmtm]

Folks, I still need your help on this.

Now I have set all time variables in forcing files with an attribute cycle_length= 360, and the model is reading that correctly.

Yet the model complains about the time interpolation.

To rephrase the problem: I'm trying to run ROMS for chesapeake bay for multiple years, yet with only one year of forcing to investigate its climatology. I have set TIME_REF=-1 so that a year is perfectly 360 days. Forcings include tides, river, surface and open boundary on the east side of the grids.

Tides periods changed to make sure tides beat exactly on 360 day cycles, all river, surface and open boundary forcings have time variables with cycle_length=360.

I ran the model now on an SGI machine with 64bit architecture.

Problem being that: my forcing files, for example surface forcing (Qair, Tair, press, etc), I have data from -3 (days ) to 367.8750 (days), the preiodicity of hte data is 360 days precisely, meaning that data within [-3 0] is the same as [357 360], data within [360 367.8750] is the same as [0 7.8750]. That is to say the [Tmin, Tmax] exceeds the cycle_length, and I'm not sure whether this trigures the problem of interpolation. You may want to ask why I have [Tmin, Tmax]=[-3 367.8750] in data cover [0 360], This is because I fear that if I do not have data outside of [0, 360], the model may not be able to find data to start from day 0.

For river forcing, the [Tmin and Tmax] is [-3, 367] also covering [0, cycle_length]=[0, 360]

The model runs fine for the first year, until it hits the end of the forcing 367.8750. To be more specific, I have posted the screen output as following:

http://131.118.211.30/chesroms/internal ... chknew.txt

starting at line 4774, the model starts to complain that model time is exceeding river data time, which of cause it will. Problem being interpolation coefficients fac1 and fac2 are of opposite sign due to TINTRP2 < TINTRP1. At line 4729, the model did read river data at t=-3 days, i.e. the model did wrap around to read data from the first record, but some how TINTRP2 is not correct.

At line 4807, the complaint reoccurs, this time with TINTRP1 = 357.0000 TINTRP2 = 358.0000, which is wrong because I would expect them to be 7 and 8 due to model time TDAYS on line 4808 is 367.0014, i.e. the model should try to read river data from day 7 and day 8, yet the model actually read day -3 and day -2, which gave TINTRP1=357 and TINTRP2=358.

What do you think is the problem? Should I always make sure [Tmin Tmax] is within [0 cycle_length] instead of covering [0 cycle_length]? If I have to do this, I consider it something non-ideal.

Another thing, I'm running it on SGI, do I have to turn on #SGI ? I did not turn it on manually so far. Or I have to make sure whether the compiler/makefile turned it on automatically. I saw there is something like this in set_2dfld.F:

#if defined CRAY || defined SGI
fac1=ANINT(Tintrp(it2,ifield,ng)-time(ng))
fac2=ANINT(time(ng)-Tintrp(it1,ifield,ng))
#else
fac1=ANINT(Tintrp(it2,ifield,ng)-time(ng),r8)
fac2=ANINT(time(ng)-Tintrp(it1,ifield,ng),r8)
#endif

I guess SGI cpp is not required.


Thanks,

Wen

[kate]

I know that the last time I used the periodic forcing, I didn't have to include any times outside the 0..360 window. Specifically, I had monthly fields at days 15, 45... 345, that's it. It is certainly worth trying this to see if it will fix your problem. You can use NCO to extract the needed records from a NetCDF file. ROMS has to go through some fancy clock hoops for the cycling to work and it wouldn't surprise me at all if you've managed to break it by including values outside the range.

For your SGI question, if the model compiles without warnings, don't worry about it. The Cray real type is r8 by default so you don't need that extra optional argument. It probably doesn't hurt to include it though.

[longmtm]

Hi Kate,

Thanks a lot, after quite some poking around, I believe what you suggest is right. I should try not give something EXTRA than it's trying to find.

The clocking of Tmono is really fancy,,,

Wen

[longmtm]

Hi Kate and all ROMS experts,

You are right, once I restricted the forcing files to only contain data within time range [0 cycle_length) , the model reads forcing correctly and can run multiple years.

Yet there is another problem that I ran into:

I have succesfully run the model for 2 years straight with only one year of forcing [0, 360), but I want to run the model for 40 years, so I was trying to do it by restarting year by year. Yet problem shows up when I restart the model at exactly the end of the first year.

That is, I ran for one year precisely, save the restart file and history files, Then I set NRREC=-1 and replace the initial file to be the restart file,

The model reads the restart file OK. But it has trouble read forcing file again because somehow the model wants to read forcing at time=360 (days), but the forcing on contains from [0 360), Since 360 should is precisely a cycle after 0, I excluded data for t=360day in the forcing file as well so that there is no duplicated forcing since 0 and 360 are the same.

Here is the error message from the screen output:


http://131.118.211.30/chesroms/internal ... number.txt

At line 611, model tried to read forcing at time=360, but no forcing available, but it didn't try to wrap around back to 0. So I guess this is a bug that only shows up when you restart at precisely the end of a climatology cycle.

I also tried to restart using the history file of the end of 11'th month, i.e. day 330, it worked ran into the second year smoothly. If I stop it at the end of 23'th month i.e. 690 days and restart, I'm not sure whether if it will work.

I'm trying to include t=360day in the forcing as a first try to see if it will work.

Any clue on how to fix this is highly appreciated.



Wen

[longmtm]

I have tried to include t=360(days) in the forcing files as well, still doesn't work.

Anybody tried to use restart for climatological runs before? Thanks.

Wen

[longmtm]

> I also tried to restart using the history file of the end of 11'th month, i.e. >day 330, it worked ran into the second year smoothly. If I stop it at the end >of 23'th month i.e. 690 days and restart, I'm not sure whether if it will work.


Just to report, I did try to restart from 23'th month using history file, and it worked.

So restart works when the restart point is in the middle of a cycle, does not work at precisely the end of a cycle for climatology runs.

I'm still afraid that the history file may not contain all necessary info or not as complete as in restart file. So far it seems okay.


Wen