Create utility for vertical interpolation of wrfout files

[logi]

This needs to support what LÍ wants to do with RÁV, so:

• [x] Interpolating arbitrary variables to configurable height above ground.
• [x] Rotating wind vectors and speed from model directon to ground direction (see cosalpha, sinalpha)
• [x] Combining U and V to make wind direction and wind speed at configured heights.

[logi]

Landsvirkjun's specific requirements are, according to @olafurrognvaldsson:

Landsvirkjun vill að við eftirvinnum RÁV2 reikniröðina fyrir sig. 
Nánar tiltekið þá vilja þau að við útbúum netCDF skrár með:
 - Austur-vestur þætti vindhraða (í jarðhnitum)
 - Norður-suður þætti vindhraða (í jarðhnitum)
 - Vindstyrk
 - Vindátt
 - Eðlismassa
 - Hita
 - Kviku (þ.e. TKE_PBL breytuna)
í 10, 50, 80, 100 og 150m hæð yfir jörðu.

[logi]

@olafurrognvaldsson What is the difference between TKE_PBL and TKE?

[logi]

@olafurrognvaldsson Can you make available a smallis digit-dropped RÁV2 output file for me to test agains?

[logi]

@olafurrognvaldsson Do we want to rename the U and V variables after we've rotated them to earth co-ordinates, do avoid confusion? I've seen U_true and V_true used.

Do we have canonical names for wind-direction and wind-speed? We have used wind_dir and wind_speed elsewhere, in lower-case.

Perhaps a good convention is that model variables are upper case and derived values are lower case (unless they are mimicking model variables)

[logi]

@olafurrognvaldsson Is there a standard variable name for density? It seems to be 1/ALT, but do I write it out as density or is there a standard wrf variable name for it?

[olafurrognvaldsson]

1) The difference between TKE and TKE_PBL is that the latter is only defined within the Planetary Boundary Layer - PBL. Also, it depends on the PBL scheme being used whether TKE or TKE_PBL is a model output. When using the MYJ PBL scheme (like we do in the majority of model configurations) the TKE_PBL is written, but not TKE. 2) You can find small (i.e. <1GB) wrfout_d01 files under /sleggjan/shared/output/RAV2/2015-16 on sleggjan 3) Yes, it would be good to re-name the U and V variables. Also wind_speed and wind_dir are pretty describing names. 4) I'm not aware of the standard name for density (it is 1/ALT), I suggest you write it out as density to prevent any confusion

[logi]

OK, that's all pretty clear. I'll make a fairly general mechanism for reading WRF variables and which can create additional ones that it knows about, based on the code from wod/truthy/PointForecastGenerator. This can then be used in DropDigits as well, so when archiving files we can replace low-level WRF parameters (U,V) with derived ones (wind_dir, wind_speed) in one pass if we want to.

[logi]

Does it make sense to define tke which is either TKE_PBL or TKE depending on which is present in the input file?

[olafurrognvaldsson]

No, let's keep the two different variable names, i.e. TKE and TKE_PBL. I'm not 100% sure if they are even derived in the same manner, so there may be more difference between them than just how far from the ground they are.

[logi]

Multiple questions:

• Should I simply destagger all planar variables before use? The alternative is to stagger z and generate planar-staggered interpolation constants , for 2³ possible sets of constants.
• I can create separate interpolation constants for bottom_top and bottom_top_stag variables. Is that preferable to vertically destaggering variables before use?
• Actually, because PH and PHB are staggered, we've got z_stag natively and z is the destaggered value and interpolating against that means we can't go below the first sigma level without extrapolating for variables on the non-staggered bottom_top dimension.
• Right now I'm filling with NaN wherever the interpolation weights go outside [0..1] meaning that it is extrapolating instead of interpolating. Is it OK to extrapolate e.g. T down to 10 metres?

On the positive side, the interpolation is fast.

[olafurrognvaldsson]

• Is variable w not the only variable that is on non-staggered sigma levels (i.e. it is defined on full-sigma levels)? As for horizontal staggering, than it is only U and V that are on staggered grid. So, my suggestion would be (and I think I've read/heard this suggestion from the "community") to de-stagger and then interpolate.
• If we want to interpolate T to 10m above ground (i.e. to height level that is lower than the lowest half-sigma) could we not use T2 instead of extrapolating? Same could be done for U, V, Q and perhaps other variables
• Also, linked to this, would it make sense to limit the height levels the user can interpolate to? E.g. it does not make much sense to interpolate to levels below 10 meters above ground level.

[logi]

It seems that most variables are on non-staggered sigma-levels. The poblem is that PH and PHB are on staggered sigma levels, which means that the height-of-sigma-level variable z is on bottom_top_stag so most variables can't be directly interpolated.

We would have to stagger variables to interpolate natively rather than de-stagger.

(DropDigits) logi@saxi:~/belgingur.is/wrf_utils.git/DropDigits$ ncdump -h wrfout-ráv2.nc | grep bottom_top[^_]
        bottom_top = 64 ;
        short U(Time, bottom_top, south_north, west_east_stag) ;
        short V(Time, bottom_top, south_north_stag, west_east) ;
        int T(Time, bottom_top, south_north, west_east) ;
        ubyte TKE(Time, bottom_top, south_north, west_east) ;
        int P(Time, bottom_top, south_north, west_east) ;
        ushort ALT(Time, bottom_top, south_north, west_east) ;
        uint PB(Time, bottom_top, south_north, west_east) ;
        ubyte RELHUM(Time, bottom_top, south_north, west_east) ;
        int QVAPOR(Time, bottom_top, south_north, west_east) ;
        int QNICE(Time, bottom_top, south_north, west_east) ;
        int QNSNOW(Time, bottom_top, south_north, west_east) ;
        int QNRAIN(Time, bottom_top, south_north, west_east) ;
        int QNGRAUPEL(Time, bottom_top, south_north, west_east) ;

vs

(DropDigits) logi@saxi:~/belgingur.is/wrf_utils.git/DropDigits$ ncdump -h wrfout-ráv2.nc | grep bottom_top_stag
        bottom_top_stag = 65 ;
        short W(Time, bottom_top_stag, south_north, west_east) ;
        int PH(Time, bottom_top_stag, south_north, west_east) ;
        int PHB(Time, bottom_top_stag, south_north, west_east) ;
        ushort TKE_PBL(Time, bottom_top_stag, south_north, west_east) ;

[logi]

Nother thing is that the RÁV2 files do not contain XLATS, XLONS or HGT variables. I'll code in support for getting static dimensional variables from a second file if not present in the first file.

[olafurrognvaldsson]

Some of the RÁV2 files do contain these variables, but the first batch I post-processed do unfortunately not. So it would indeed be great to handle an extra file, containing static data, in an automatic manner