WRF output and times

[Piyush Jain]

Hi,

I'm trying to load the netcdf output file from a WRF run and I can't access the times variable.

In particular here is my code:

data = iris.load_cube(filename, iris.Constraint('T2'))
lon = data.coord('longitude').points
lat = data.coord('latitude').points

temp = data[-1] # last time point

print data returns:

T2 / (K)                            (-- : 73; -- : 24; -- : 24)
     Auxiliary coordinates:
          latitude                      x        x        x
          longitude                     x        x        x
     Attributes:
          AER_ANGEXP_OPT: 1
          AER_ANGEXP_VAL: 1.3
          AER_AOD550_OPT: 1
          AER_AOD550_VAL: 0.12
etc...

Where is the time coordinate?

Also, why are latitude and longitude auxiliary and not dimension coordinates?

Thanks

[marqh]

please may you run
ncdump -h {filename}
at the command line and paste the results into this thread?

I would like to understand the metadata you are loading.

also, please run
iris.__version__
in a python session and report this

thank you
mark

[Andrew Dawson]

WRF output files, although they are netCDF, are formed in a particular way that WRF (and associated tools) understand using their own set of WRF conventions. This means that other software that reads plain CF-netCDF can't understand them properly without extra information. I'll try and explain this as best I can:

I'll start with lat/lon coordinates. The variable in the WRFOUT netcdf file will look something like this:

float T2(Time, south_north, west_east) ;
    T2:FieldType = 104 ;
    T2:MemoryOrder = "XY " ;
    T2:description = "TEMP at 2 M" ;
    T2:units = "K" ;
    T2:stagger = "" ;
    T2:coordinates = "XLONG XLAT" ;

The dimensions it has are "Time", "south_north" and "east_west". Neither of these is actually defined as a dimension variable (i.e. a vector of values) in the netcdf file, but are just integers which specify the size. You'll notice the T2 variable has a "coordinates" attribute with value "XLONG XLAT". This is something that Iris understands, that tells it that this variable should use the variables named "XLONG" and "XLAT" as coordinates. If you look for these in your WRFOUT netcdf file you'll see that they are 3D (Time, south_north, east_west) variables, not 1D dimension variables. Hence when you load T2 in Iris you get longitude and latitude as 3-dimensional auxiliary coordinates. This is the intended behaviour from the file, and Iris is doing the right thing.

As for the time dimension, there is absolutely no information in the file about how the dimension "Time" should correspond to time values, and therefore without extra WRFOUT-specific loading logic the time dimension cannot be inferred. Iris doesn't have any WRFOUT specific logic and hence you get an anonymous dimension. In order to get the time dimension you must load the variable "Times", which is a 2D array of characters shaped (Time, DateStrLen). Once loaded you need to convert the characters into proper times (i.e. offset from a reference date) which will leave you with a 1D array of floating point numbers, which you can then convert into a dimension coordinate and add this to your cube of T2.

In summary, WRFOUT files are really model-specific dump files that happen to be in netCDF, and probably need post-processing before analysis. Tools like NCL provide a lot of extra logic in order to be able to load WRFOUT netcdf files (WRF and NCL are both made by NCAR), but Iris doesn't, so the limitations in the construction of the file (i.e. they use their own set of WRF conventions) will mean Iris can only interpret it as far as netcdf and CF conventions allow it to.

I noticed one of the major proposed changes for the next version of WRF is CF-compliant output. This should mean loading WRFOUT netcdf files in Iris and other tools will become much easier in future. For the mean-time you will probably be best post-processing the raw model output in order to make it more accessible (including de-staggering the horizontal and vertical grids), I've used unipost in the past (quite complicated but good for operational systems) and NCL is probably a reasonable choice. There are also some Python tools for post-processing WRF output, I don't recall the names but I'm sure you'd be able to find them via internet search.

[Andreas Hilboll]

Wouldn't it be great if some user would provide a nice
"load_wrf_as_cube" function doing all this? It wouldn't need to live
within the official Iris repo, but as a user recipe (on the wiki?) this
would be great.

Cheers,
Andreas.

BTW: Is there a place for user-contributed code snippets?

On 16.04.2015 12:04, Andrew Dawson wrote:
> WRF output files, although they are netCDF, are formed in a particular
> way that WRF (and associated tools) understand using their own set of
> WRF conventions. This means that other software that reads plain
> CF-netCDF can't understand them properly without extra information. I'll
> try and explain this as best I can:
>
> I'll start with lat/lon coordinates. The variable in the WRFOUT netcdf
> file will look something like this:
>
> |
> floatT2(Time,south_north,west_east);
> T2:FieldType=104;

> T2:MemoryOrder="XY ";

> --
> You received this message because you are subscribed to the Google
> Groups "Iris" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scitools-iri...@googlegroups.com
> <mailto:scitools-iri...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.


--
-- Andreas.

[Piyush Jain]

Thanks everyone.

Following Andrew Dawson's advice, I got the time coordinate by making a second call to load_cube as follows:

times_cube = iris.load_cube(filename, iris.Constraint('Times'))
times = [''.join(t) for t in times_cube.data]

you can then parse the strings to datetime objects using the datetime module.

I'm sure there is a more efficient way of doing this, but it works!