Problem with the time of the ECMWF files

[Scarlett]

Dear All,

I’ve been trying to create the atmospheric forcing inputs to ROMS with the d_ecmwf2roms.m, I followed the instructions that come at the beginning of the script:
---------------------------------------d_ecmwf2roms.m------------------------------------------
% This is a user modifiable script showing how to create ROMS forcing
% NetCDF files. The data source is the ECMWF's ERA-Interim Dataset
%
% http://apps.ecmwf.int/datasets/data/interim_full_daily/
%
% This global data is available from Jan 1, 1979 to the present. It is
% usually extracted to a regional grid from the ECMWF data server. No
% attempt is made to interpolate the forcing fields to a particular
% ROMS grid. ROMS has the capability to perform the spatial and
% temporal interpolation of 2D forcing fields.
%
% This is a template script showing how to create several NetCDF files
% (one per each atmospheric forcing field) using ROMS metadata structure,
% which follows the schema of "nc_inq" or native 'ncinfo" function.
%
% 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
% ERA Variables
%
% ecmwf_era_atms_2000.nc time, msl, tcc, v10u, v10u
% ecmwf_era_flux_2000.nc time, ewss, nsss, e, tp
% ecmwf_era_heat_2000.nc time, sshf, slhf, ssr, str
% ecmwf_era_temp_2000.nc time, v2t, v2d, strd, par
---------------------------------------------------------------------------------------------------
But I have a problem with the time of ecmwf_era_atms.nc and ecmwf_era_temp.nc. First the time record is 0,12,0,12,0,...,12 (for each day), followed by 0,3,6,9,3,6,9,12,3,6,...,12 (for each day).

On the other hand (the correct form), in the files ecmwf_era_flux.nc and ecmwf_era_heat.nc the time record is 0,3,6,9,12,0,3,6,9,12 (for each day).

I have written to ECMWF's advice and they explained to me why this happens.

-----------------------Anabelle Guillory (C3S User Support at ECMWF) message-----------------------------
In ERA-Interim, there are 2 types of parameters: the so-called instantaneous parameters (e.g. temperature) and the accumulated parameters (e.g. total precipitation). Accumulated parameters are only available in the forecast part of ERA-Interim, so when you retrieve the accumulated parameters (such as those in your era_flux file), all the data come from the forecast part of the dataset, on 3 hourly steps as per your specification.

Instantaneous parameters however are available from both the analysis and the forecast part. So I think that what is happening in your era_atms file for example is that the analysis data is first shown and then the forecast data. When I use Panoply to look at your file, the timing shows correctly in order.

I suspect that you will find the following Knowledge Base article of interest:

https://confluence.ecmwf.int/pages/view ... d=56658233
----------------------------------------------------------------------------------------------

But the problem is that I can not work with this files.
Has anyone else had this issue? How did you solve it?

Please find attached images showing the vector time.

Marmo.

[c.drinkorn]

Hi Scarlett,

I had sort of the same problem (my Pair time record had switched 12h and 18h steps - it was what the conversion from grib to netcdf resulted in while my grib file had both analytical and forecast). Since I didn't retrieve the data myself I wrote a workaround to fix the field myself (note: code is just a snippet and is modified compared the to original script):

Code: Select all

if strcmp(Vroms,'Pair')
        % The field of Pair appears to have switched records for 18 and 12
        % hour steps. Fix here:
        % Create array with irregular indices (1,2,4,3,5,6,8,7,...) 
        Rec_irr = NaN(1,EndRec);
        for i=1:EndRec
            k = (rem(i*(i+1),4)-2)/-2;
            Rec_irr(i)=i+(-1)^(i-1)*k;
        end
        % Loop through irregular indices switching 12h and 18h steps
        for Rec=Rec_irr
            MyRec(n) = MyRec(n) + 1;
      mydate = datestr(epoch+time(Rec),31);
      disp(['** Processing: ', Vroms, '  for  ',mydate,' **']);  
      frc_time = time(Rec) - ref_time;     
          field = nc_read(InpFile, Vecmwf, Rec);
          field = field.*scale;
          fieldfinal = field;
                if (FlipLat)
        fieldfinal  = fliplr(fieldfinal);
                end  
% Change order of longitude to -180 to 180 instead of 0 to -0
      fieldfinal = fieldfinal(ind_lon,:);
% Write out data.
      status = nc_write(OutFile, Troms, frc_time, MyRec(n)); %#ok<NASGU>
      status = nc_write(OutFile, Vroms, fieldfinal, MyRec(n));
        end
    else
    for Rec=StrRec:EndRec
    % Here goes the normal code of data processing...
    end

This fix doesn't apply to your problem, of course. But you could think of something similar. In your case you basically just need to cut of either of the fields (analytical or forecast, depending on which one you want to keep). It should be much easier, then. Just adjust the loop for the case of the variables in question...
I hope, this could lead you towards a solution!

[Kosa]

I had this issue in the past but I don't remember what I'm doing differently now so that I don't have the issue anymore. My work around: sort the time variable (so that time is strictly increasing) and then sort your other variables' time dimensions to match.