forcing the ROMS with ERA interim

[mashinde]

Dear Friends,

I am getting problem in finding 6 hourly data for radiation fluxes and rainfall for ERA Interim. Is there anyone who already use 6hourly data from ERA Interim, then kindly suggest/give idea how to obtain these data ?

Thanking you

[julian.kuhlmann]

Have you tried this site?
http://data-portal.ecmwf.int/data/d/int ... vtype=sfc/

[mashinde]

Dear Julian,

Yes, I tried this data. But I am not getting total rainfall and radiation fluxes data at every 6 hours.
Do you have any idea/suggestion how to get it ?

Thanks

[johnluick]

I don't think they make six-hour data available. But you're asking in the wrong place. You should ask ECMWF via that website. If you want six-hour data you could go with NCEP. I think that you would then lose some spatial resolution however.

Some of those ERA 12 hour fields are not instantaneous; they integrations over 12 hours. Seems like that would be fine for an ocean model. After all, the ocean does a pretty good job of integrating energy and mass fluxes over a similar time scale. An exception to this may be wind forcing. If your area has strong diurnal sea breeze and you need to resolve it then you may need to go to six hours.

[arango]

I have been able to get the ERA-interine every three hours. You have two control menus in the order form:

• Select Time: [00:00:00, 06:00:00, 12:00:00, 18:00:00]. This is the analysis time.
• Select Step: [0, 3, 6, 9, 12]. This is the forecast time.

If the analysis is every 6-hours, I would select step 0, 3, and 6. You need to read the documentation at ECMWF.

[mashinde]

Dear Prof. Arango,

Thank you for kind suggestion. I am unable to get rainfall and radiation fields at every 6hrs. Other fields except rainfall and radiation are available at every 6hr for analysis time [00,06,12,18] and at every step for forecasting time [0,3,6,9,12]. So I extracted these fields(except rainfall and radiation) for every 6hrs having step 00. This may considered as analysis fields.

But, rainfall and radiation fields are not available at above time and steps. They are at analysis time [00,12] and [3,6,9,12] at forecasting time. So in this case I am trying to extract 12hrs fields for step 6 and then converting them into 6hr data using cdo tool. I am not sure this is correct way of doing this conversion ?

Thanking you.

[kate]

As long as each field is in its own file, ROMS is perfectly capable of interpolating from one record to the next, each at its own frequency. I have rainfall at monthly intervals in one forcing set.

That said, radiation can be tricky if you're talking about incoming shortwave radiation. We used to get that daily, then add our own day-night cycle to it. How accurate do you need that day-night cycle to be?

[m567tej]

Dear all,
I have also this problem for converting factor for my data sets. I get ECMWF ERA interim data set e.g. precipitation by choosing analysis time: 06:00 and 12:00 and select step: 6 and 12; I don't know what is the converting factor to convert data unit into ROMS unit (3*3600 or 6*3600)?

[redhat007]

dear
i am using ecmwf in 6 hr interval. i have changed all 3*3600 to 6*3600 in d_ecmwf2roms.m. but about lines 489 to 500 i am not sure about how i should change them.

Code: Select all

if (F(n).scale < 0),
        step = rem(frc_time,0.5)*24;
        if step == 3
          fieldfinal = field;
        else
          fieldfinal = field - field_previous; 
        end                                    
        frc_time = frc_time - 1.5/24;	      
                                                
        field_previous = field;    

would you please tell me that following changes are correct and enough ?

Code: Select all

if (F(n).scale < 0),
        step = rem(frc_time,0.5)*24;
        if step ==6
          fieldfinal = field;
        else
          fieldfinal = field - field_previous; 
        end                                    
        frc_time = frc_time - 3/24;	      
                                                
        field_previous = field;    

thanks for any reply
redhat

[redhat007]

Dear freinds
i can not fine my last post answer . i am worried with those changes in d_ecmwf2roms.m (last post) creaed force data damaged.
i become grateful to receive your experience
cheers
redhat

[arango]

We are busy people and sometimes don't have time to answer everybody's questions. The ECMWF website has a lot of documentation for this dataset including FAQ page. You can spend some time reading that information.

No, you cannot do that change in the d_ecmwf2roms.m script. The ERA dataset for those fields are the cumulative values for every three hours and not six hours.

We always get this dataset for the 3-hour intervals to capture the daily cycle. You cannot resolve the net shortwave radiation flux with 4 values per day (i.e., every six hours). The factor 3*3600 is to convert 3 hour interval to seconds.

[redhat007]

Dear
one_year_long force files (2008-Jan-1 to 2008_Dec_31) have been created by ECMWF in 3 hourly time step (which all downloaded files start at 03:00:00 O'clock). As you know some variables in created force files start from 03:00:00 o'clock ( such as could, tair, etc) and some of them start from 01:30:00 o'clock (such as rain). Therefore would you please tell me that initial condition and climatology files should be started from which time?

Many thanks
redhat

[mengqingjun]

Hi redhat,I think if you are running a climatology case, you can use a cycle_length attribute, if you are running a real-time case, you can start your model from 2008-01-01_01:30:00. Whatever,try and see,good luck!

[wilkin]

I think those changes you propose:

Code: Select all

if (F(n).scale < 0),
        step = rem(frc_time,0.5)*24;
        if step ==6
          fieldfinal = field;
        else
          fieldfinal = field - field_previous;
        end                                   
        frc_time = frc_time - 3/24;                     
        field_previous = field;   

would indeed work provided you downloaded data at 6-hour intervals and changed the scale factors as you claim, e.g.:

Code: Select all

F( 8).Vname  = {'lwrad', 'str'};
F( 8).Tname  = {'lrf_time',  'time'};
F( 8).input  = 'ecmwf_era_heat_';
F( 8).output = ...
F( 8).scale  = -1.0/(6*3600.0);

Your code snippet omitted the comments in the original code we distributed which explain the logic. So for the benefit of others here is the original code in d_ecmwf2roms.m:

Code: Select all

% If the scale F(n).scale is set to negative, the input ECMWF data is a
% cumulative integral in forecast cycle from hour zero. For steps at 6, 
% 9 and 12 hours we must separate last 3 hours of integration from 
% previous accumulation. At 3 hour step don't change anything
      if (F(n).scale < 0),
        step = rem(frc_time,0.5)*24;
        if step == 3
          fieldfinal = field;
        else
          fieldfinal = field - field_previous;  % At other steps subtract
        end                                     % the previous accumulation
        frc_time = frc_time - 1.5/24;	        % Center forcing time on the
                                                % accumulation interval
        field_previous = field;                 % Save this accumulation
                                                % to use on the next step
      end

This code was written to work with 3-hour interval data downloaded from
http://apps.ecmwf.int/datasets/data/interim_full_daily

While the site allows a user to extract fields at only some of the 3-hour intervals in the analysis cycle (say only 6, 12) the code above assumes the data were at 3-hourly intervals for the 00Z and 12:00Z cycles. This is noted in the preamble comments:

Code: Select all

% The following parameters are used to extract ERA-Interim fields:
% Select time:   00:00:00     12:00:00
% Select step:   0  3  6  9  12

though the comments should probably NOT include hour 0. That said, what you will find when you build a query is that if you select the variable you want FIRST, e.g. surface solar radiation downwards you will see that the options under Select Step change and the 0-hour is greyed out and in italics indicating is it unavailable. This is because the variables that are accumulated over time are undefined at the 0-hour: the accumulation has not begun and the integral of anything from 0 to t when t=0 is zero, trivially.

In your case, if you select cycles 00:00:00 and 12:00:00 download only steps 6 and 12, then you will have data that are the integral from hours 0 to 6 and from hours 0 to 12. So when ...

Code: Select all

rem(frc_time,0.5)*24 == 6

is true, those data need to be scaled by 1/(6*3600) (as you indicate you do) and saved (in field_previous) so that on the next pass through the integral from hours 0 to 6 can be subtracted from the 0 to 12 integral (as it appears you do) and also scaled appropriately.

If I were you I would check with a small subset of data the result of running the code as provided with 3-hourly data to see that you get roughly same results. Your values on the 6 and 12 hour times will be reported at hours 3 and 9 because they have different averaging intervals, but the range of values should resemble a smoothed version of the 3-hour downloads and processing code we provide.

As Hernan Arango pointed out in his post, for solar radiation you are not going to resolve the diurnal cycle very well with 6-hour interval shortwave radiation. ROMS includes an option #define DIURNAL_SRFLUX to apply an analytical diurnal cycle to daily average data (but not 6-hourly average data). You might want to configure your ECMWF preprocessing to use that option.

[MJiang]

as of today, it seems the script has a typo on the shortwave radiation scale,

F( 5).scale = 1.0/(3*3600.0);

which should be negative.

[uranoscopus]

I found another typo in the d_ecmwf2roms.m script, here:

Code: Select all

F( 6).Vname  = {'Uwind', 'v10v'};

and

Code: Select all

F( 7).Vname  = {'Vwind', 'v10u'};

U and V are inverted.
Further v10u and v10v are no (longer?) the exact names of variables as downloaded from ERA website in netcdf files, while the names are u10 and v10.

So these two lines should be:

Code: Select all

F( 6).Vname  = {'Uwind', 'u10'};

and

Code: Select all

F( 7).Vname  = {'Vwind', 'v10'};

Typos also present in the comments of the m file.

[poppai]

Why can not anyone answer uranoscopus'question?

[kate]

I don't see that he/she has a question. Rather, the post is useful advice for anyone using that script. Hopefully the maintainer of the script saw it and fixed it, but that isn't me.