auxiliary output files missing xtime

Hello,

I am outputting certain variables at hourly time steps while the wrfout is 3 hourly. The data is all present and the "Times" character string is correct, but the variable xtime is missing. This is a problem for CDO to as it needs that variable to perform time operations. It's missing in every auxiliary output file (including the pressure level output). Is there any way to get xtime back into the data in the future? I can fix the data with CDO commands I believe but it would be nice to not have to.

Another quick question: The some of the auxiliary output files are in the format: sfc_vars_d01_2011-04-01_01\:00\:00.nc where it starts at hour 01 instead of hour 00. In this case, I have accumulated variables so it doesn't matter much, but I am curious how to get the output files to write out at the 00 hour instead of 01?

Thanks,

Gabe

Hi Gabe,
1) I'm not certain if this will work, but you could test it. If you used the Runtime I/O option to specifically output xtime in your aux output files, does that fix the problem?
2) Unfortunately there doesn't seem to be an option to output these files at the initial time. There is an option for outputting the history file at hour 0 when running a restart. I assume the code handling the aux output files may be behaving in a similar way as for restarts, but no exception was ever written in the code, as it was for restarts. The restart option is called "write_hist_at_0h_rst." You may be able to use that code to write something that would work for aux output too.

Hello,

Do you happen to know why my files dont have the time variable? Is it a bug in the model system? Not sure why lat and lon would be output and not the time coordinate. Unfortunately in my testing, it looks like it will be very expensive to add time to all the files, do you know of any workarounds that people use? Assuming im not the only one with this issue?

Thanks!

Gabe

Gabe,
Are you doing this on Cheyenne? If so, can you point me to your directory? Otherwise, can you issue an 'ncdump -h your-output-stream-file >& output.txt" and send me the output.txt? Thanks!

Hi Kelly,

The files are located at /glade/p/univ/umsb0001/model_runs/control_2011/sfc/ which are the surface variables I saved but the same problem exists with the pressure level data and the conv data (basically any file that isn't the wrfout files).

The namelist (and run directory) is located at /glade/scratch/gbromley/control_2011/wrf/run


Thanks,

Gabe

Gabe,

Let's look at this concern from two perspectives: why do we get this behavior, and what can we do with the existing model output.

First, what is causing the "xtime" behavior you see?

The Registry/Registry.EM_COMMON lists the following line that defines the "xtime" variable (I removed some unnecessary spaces):

To make a variable part of an output stream via the Registry, the "h" flag is set. In this line, the string is "rh". That means that this variable ("xtime") will be in the restart file (the "r") and in the standard history output file (wrfout_d01_YYYY-MM-DD_hh:mm:ss, the "h" part of the string).

By default, to include the variable "xtime" in any other output stream (let's assume we are using stream 5), the original "rh" string would need to be "rh05".

Let's contrast the variable "xtime" with the latitude array (again, some spaces removed):


Note that for this variable, the (much more busy) IO portion of that string is "i0123rh0156{22}{23}". We only care about the portion of the string starting with the "h" and ending before the "du". That gives us a string that has "h0156{22}{23}". This string tells the WRF model to output the latitude to streams 0 (the default wrfout file), and the following auxiliary streams: 1, 5, 6, 22, and 23.

You can modify the Registry/Registry.EM_COMMON so that all subsequent runs include the "xtime" variable in your specific streams. This does require you to do the "clean, configure, compile" steps to build a new executable. As Kelly mentioned, you can also add variables to your streams at run-time, with a few namelist edits. Take a look at http://www2.mmm.ucar.edu/wrf/users/tutorial/202001/gill_registry.pdf at Example 1. However, just like with the modifications to the Registry.EM_COMMON file, these changes only impact subsequent model simulations.

Second, what can you do to retrofit the xtime variable into the files from which it is missing.

There are examples of using NCL to add in a new variable to an existing netcdf file: https://www.ncl.ucar.edu/Support/talk_archives/2012/3335.html.

There is a python set of tools for WRF. Take a look at https://opensky.ucar.edu/islandora/object/conference:3173/datastream/PDF/wrf-python.readthedocs.io.

Both of these may provide you with information for how to proceed.