OIFS outputs fields iterate forward in time only, but not in date. For example, in ICMSH<expid>_t I get (with grib_ls):
2 ecmf hybrid 60 20240201 18 fc t spectral_complex sh
[...]
2 ecmf hybrid 60 20240201 24 fc t spectral_complex sh
[...]
2 ecmf hybrid 60 20240201 30 fc t spectral_complex sh
Whereas I would like
2 ecmf hybrid 60 20240201 18 fc t spectral_complex sh
[...]
2 ecmf hybrid 60 20240202 00 fc t spectral_complex sh
[...]
2 ecmf hybrid 60 20240202 06 fc t spectral_complex sh
The purpose is to create relaxation files for longer than a single month. Splitting up grib files with the correct dates is much easier than translating hours into dates with grib_filter…
Hi Jordan,
I am not sure if you are asking a question. But your description seems to be largely correct: In a forecast run (i.e. fc type experiment) the dataDate remains consistent as a reference point for the start of the forecast. The time increment is shown for instance in the stepRange parameter which is given in units of hours. For instance, a stepRange of 30 means that the valid time for the data is 30 hours since the start of the forecast.
This is the normal format of fc output for the IFS (and therefore OpenIFS). Are you looking to change this? I am not sure if this can be changed, but it should be possible to replace the value in the grib files using the command line grib tools, such as grib_filter as you describe, in a post-processing step. Does this cause problems?
Best,
Marcus
Hi Marcus,
Thank you for your reply. I was indeed hoping that the output could be formatted into a date, rather than only iterating the hours.
Currently, I use the following grib_split_rule which I run with grib_filter:
#Prepare output file for use as relaxation file (nudging)
#print “Starting”;
#print “levelType: [levelType]”;
#print “date=[date]”;
set date=date+stepRange/24;
set time=stepRange%24;
set time=time*100;
set stepRange=0;
#print “date=[date] time=[time]”;
write “rlx_files_out/rlx[levelType][gridType][date][time]”;
This works fine until the date reaches the end of a month. I then need to iterate the month, and for longer integrations, the year. I’m not very familiar with grib_filter and so I’m not sure how to take into account the varying durations of each month (especially given leap years) in a grib_filter script.
Is there a command of grib_filter or another command line script to facilitate this?
Thank you in advance for the help.
Best regards, Jordan
Hello Jordan,
Marcus asked me to take a look at this for you.
Unfortunately, the grib_filter rules file does not provide a full-blown programming language so it can’t be used to make the sort of date manipulation that you are interested in.
However, rather than looking at the dataDate, dataTime and step keys, I think you’ll find that the validityDate and validityTime keys provide what you’re looking for. Try:
grib_ls -n time ICMSH<expid>_t
and you should see all of the time-related keys you can use. If validityDate and validityTime increment in the way you are looking for, then you can do simply:
grib_copy ICMSH<expid>_t "rlx_files_out/rlx[levelType][gridType][validityDate][validityTime]"
But note that the metadata (the dataDate, datatime and step, etc) will be unchanged from the original input file. If you don’t want this then you’ll need do some further manipulation.
I hope this helps.
Best regards
Paul
1 Like