Dear all,
I am struggling a bit with the timing of my meteorological data. I have to add that this is my first contact with grib, arl and forecast/reanalysis data so maybe I'm asking questions which are obvious for everybody else.
I am working with CFSR forecast (6hr) and analysis data and calculating trajectories. I'm dealing with both forecast and analysis, since not all fields (for example the 10m winds) are available in the analysis.
I don't understand how the timing is set up in the grib and arl files, since depending how I look at the data, I get different answers:
For example in the arl-header under "Greenwich date/time for which data valid" is this the time for which the forecast is valid or is it the time where the forecast was initiated? I.e. which time is used later in the trajectory calculations, the time indicated here or this time + "Forecast"?
Same thing when looking at the grib data with wgrib or grib_ls, which time is shown?
So basically do I need to shift the Forecast data manually by 6hr to compare Forecast and Analysis at the same moment or is that already taken care off automatically?
I am using MeteoInfo to convert from grib2 to arl and as it looks the midnight grib2 data in some cases is identical to the 6am arl data, so I think something is going wrong somewhere and I need to better understand how this timevariable is dealt with.
Thanks for your input on that question,
Martina
time variable in arl files
-
- Posts: 451
- Joined: November 9th, 2012, 4:23 pm
- Registered HYSPLIT User: Yes
Re: time variable in arl files
The arl header in HYSPLIT meteorology files begins with values giving YYMMDDHHFF
YY=year
MM=month
DD=date
HH=hour
FF= forecast hour
YYMMDDHH is the "Greenwich date/time for which data valid". This applies whether it's a forecast or analysis.
FF is the associated forecast hour of that data
Example with 0-h forecast:
13121812 0 - data valid 12UTC 18 Dec 2013, forecast initialization is the same since the forecast hour is 0
Example with 12-h forecast:
1312181212 - data valid 12UTC 18 Dec 2013, forecast initialization 12 hours earlier, or 00UTC 18 Dec 2013
I thought wgrib inventories are labeled as to whether it is the valid time or forecast initialization time plus X forecast hours.
I'm not familiar with MeteoInfo.
YY=year
MM=month
DD=date
HH=hour
FF= forecast hour
YYMMDDHH is the "Greenwich date/time for which data valid". This applies whether it's a forecast or analysis.
FF is the associated forecast hour of that data
Example with 0-h forecast:
13121812 0 - data valid 12UTC 18 Dec 2013, forecast initialization is the same since the forecast hour is 0
Example with 12-h forecast:
1312181212 - data valid 12UTC 18 Dec 2013, forecast initialization 12 hours earlier, or 00UTC 18 Dec 2013
I thought wgrib inventories are labeled as to whether it is the valid time or forecast initialization time plus X forecast hours.
I'm not familiar with MeteoInfo.
Re: time variable in arl files
Thanks Barbara, for detailing the ARL convention. That helps me a bit to find my error!
Martina
Martina
Re: time variable in arl files
Hi Yaqiang,
I realize only now that I never saw your post here - either I completly overlooked it or maybe it was only approved after I had written my answer to Barbara?
Anyhow, I'm back now since a long time to the question and I think I have understood (and solved) the problem in the meanwhile.
The conversion is going fine under the condition that the grib file contains forecast and analysis variables for exactly the same timesteps, what was not my case as I downloaded them.
If I have in my grib file 20 timesteps starting from 6.1.2010, 0:00 for the analysis data, but 20 timesteps starting from 6.1.2010, 6:00 for the forecasting data; my final arl file contains still 20 timesteps and starting from 6.1.2010, 6:00. But the dataset from 6.1.2010 6:00 contains the first dataset for forecast and for analysis data, i.e. the 0:00 valaues from some and 6:00 values from some others.
Also if my initial grib files contains a different amount of datasets for analysis and forecast, I'm ending in a seg.fault since the variable tNum (see your conversion script in another post) is greater than the amount of data available for some of the variables.
So as I see it, the graphical output and everything else takes correctly into account this 6hours forecasting time, however tNum loops simply over the "available" timesteps in the files without choosing necessarily the correct ones.
I have no rearranged my initial grib-files so that they contain exactly the datasets needed for the final arl files and exactly the same for analysis and now it does look ok.
Sorry for the confusing message ... but these two different time variables are a bit confusing
.
Martina
I realize only now that I never saw your post here - either I completly overlooked it or maybe it was only approved after I had written my answer to Barbara?
Anyhow, I'm back now since a long time to the question and I think I have understood (and solved) the problem in the meanwhile.
The conversion is going fine under the condition that the grib file contains forecast and analysis variables for exactly the same timesteps, what was not my case as I downloaded them.
If I have in my grib file 20 timesteps starting from 6.1.2010, 0:00 for the analysis data, but 20 timesteps starting from 6.1.2010, 6:00 for the forecasting data; my final arl file contains still 20 timesteps and starting from 6.1.2010, 6:00. But the dataset from 6.1.2010 6:00 contains the first dataset for forecast and for analysis data, i.e. the 0:00 valaues from some and 6:00 values from some others.
Also if my initial grib files contains a different amount of datasets for analysis and forecast, I'm ending in a seg.fault since the variable tNum (see your conversion script in another post) is greater than the amount of data available for some of the variables.
So as I see it, the graphical output and everything else takes correctly into account this 6hours forecasting time, however tNum loops simply over the "available" timesteps in the files without choosing necessarily the correct ones.
I have no rearranged my initial grib-files so that they contain exactly the datasets needed for the final arl files and exactly the same for analysis and now it does look ok.
Sorry for the confusing message ... but these two different time variables are a bit confusing

Martina
Re: time variable in arl files
Hi Yaqiang,
I had tried to reply to your message, but somehow it didn't go through, sorry ... and earlier I somehow I had completly overlooked your message and only seen Barbara's answer.
I have understood and solved the problem with the MeteoInfo conversion:
The grib-file needs to contain the forecast and analysis variables for exactly the same times. In the beginning I had grib files which contained either one additional forecast timestep or forecast for timesteps 2 to n+1 and analysis from 1 to n. This leads to wrong timing in the arl files. Now I'm first rearranging my grib files to have 1 to n for both forecast and analysis.
So there is no problem at all with this timeshift between forecast and analysis, it's all correctly dealt with, it's just that the tNum loop (see your example conversion script) simply loops over all availalbe timesteps, but does not necessarily look for the correct one.
Martina
I had tried to reply to your message, but somehow it didn't go through, sorry ... and earlier I somehow I had completly overlooked your message and only seen Barbara's answer.
I have understood and solved the problem with the MeteoInfo conversion:
The grib-file needs to contain the forecast and analysis variables for exactly the same times. In the beginning I had grib files which contained either one additional forecast timestep or forecast for timesteps 2 to n+1 and analysis from 1 to n. This leads to wrong timing in the arl files. Now I'm first rearranging my grib files to have 1 to n for both forecast and analysis.
So there is no problem at all with this timeshift between forecast and analysis, it's all correctly dealt with, it's just that the tNum loop (see your example conversion script) simply loops over all availalbe timesteps, but does not necessarily look for the correct one.
Martina