Selection with regard to ECMWF ERA datasets

[tony1230]

Hi ROMS friends

I have been using forcing conditions from ECMWF ERA dataset. I am using the matlab script that Hernan and John provide (i.e. d_ecmwf2roms.m) all the time, but with the STEP selection with "3 6 9 12" and without "0" step. And recently, i found that there are differences between the STEP selection with or without the "zero/0" step. I see if the "0" was included, the dataset will be one more time record than that without "0". Attached is a time-dependent single point U-component wind velocity, as you can see clearly that distinct differences exit. So i have confused what exactly the reasonable selection should be Even though there is illumination in the matlab script, but still should be clarified.

Two doubts

1. with "0" step, why merely one more record to the time-series? I would think that there are "0" steps everyday

2. if really "one more record", why so big difference between them.


thanks in advance and i need you help.

-shou

[mashinde]

HI,

It is better to read data FAQ from ECMWF.

http://old.ecmwf.int/products/data/arch ... a_faq.html

[hbzong]

When 0 is selected, analyzed data are available. When 3,6,9 and 12 is selected, forecast data are available.
If you follow the parameters in d_ecmwf2roms.m, both analyzed and forecast fields are available. And the time array in the netCDF file is look like this: analyzed data time + forecast data time. For example, if this is netCDF file including two days data, time array is 0 12 24 36 48 3 6 9 15 18 21 27 30 33 39 42 45.

[uranoscopus]

For example, if this is netCDF file including two days data, time array is 0 12 24 36 48 3 6 9 15 18 21 27 30 33 39 42 45.

Thank you very much to hbzong. I was struggling from a while with internal times of ERA-interim netcdf's extracted from the data portal and now finally I have understood.
For a while I thought that there could be a problem with the d_ecmwf2roms.m script, but it is not the case.

For what I have understood, the issue is that you can have 3-hourly ERA-interim forcing ONLY if you select steps 3 6 9 12 (and NOT 0). If you select also 0, as suggested internally in the script, you will have a file with time index (and vars) firstly related to the analyses (which can be at most 6-hourly and that will be 12-hourly following the 00 12 time selection suggested in the script) while fcst vars and time index is written after analyses fields (0 step). So when you'll feed your model with netcdfs containing such a mix of analyses+fcst you will actually force only with analyses (6 or 12 hourly) as they are written in the top of the netcdf files.
FCST records (the 3 hourly forcing) simply will NOT be read by the model.

I think this could be of interest for many implementations using ERA-interim forcing. In my case for example I was sure that I was forcing with 3-hourly forcing while I was actually forcing with 12-hourly fields!!!

Cheers,
Antonio

[mjfconan]

For example, if this is netCDF file including two days data, time array is 0 12 24 36 48 3 6 9 15 18 21 27 30 33 39 42 45.

Thank you very much to hbzong. I was struggling from a while with internal times of ERA-interim netcdf's extracted from the data portal and now finally I have understood.
For a while I thought that there could be a problem with the d_ecmwf2roms.m script, but it is not the case.

For what I have understood, the issue is that you can have 3-hourly ERA-interim forcing ONLY if you select steps 3 6 9 12 (and NOT 0). If you select also 0, as suggested internally in the script, you will have a file with time index (and vars) firstly related to the analyses (which can be at most 6-hourly and that will be 12-hourly following the 00 12 time selection suggested in the script) while fcst vars and time index is written after analyses fields (0 step). So when you'll feed your model with netcdfs containing such a mix of analyses+fcst you will actually force only with analyses (6 or 12 hourly) as they are written in the top of the netcdf files.
FCST records (the 3 hourly forcing) simply will NOT be read by the model.

I think this could be of interest for many implementations using ERA-interim forcing. In my case for example I was sure that I was forcing with 3-hourly forcing while I was actually forcing with 12-hourly fields!!!

Cheers,
Antonio

Because this script processes data record one by one, it's easy to modify its order before output. And maybe we should be careful of those cumulative flux data.