const -> star found in bad slot

[aamemiya]

Hi.

I have just installed MET and tested if it works on my NetCDF files which are in CF-1.6 convention, but I could not run any of them.
The error massages I got was mostly about specifying the level. For example, when I tried to run plot_data_plane for a 4-d variable QHYD(x,y,z,time), the error was like the following. It is baseically the same when I choose other variables or set level="(,,0,0)", "(0,,,0)" or any other possible combinations.
Is there anything wrong with the level configuration or the data format?
If needed I will upload the sample data.

Thanks.

> plot_data_plane -v 5 test_fcst.nc out.ps 'name = "QHYD"; level= "(0,0,*,*)"; '
DEBUG 1: Opening data file: test_fcst.nc
DEBUG 4: Met2dDataFileFactory::new_met_2d_data_file() -> created new Met2dDataFile object of type "FileType_NcCF".
DEBUG 4: NcCfFile::open() -> parsing units for the time variable "seconds since 2021-02-20 00:00:00"
DEBUG 4: parse_cf_time_string() -> parsed NetCDF CF convention time unit string "seconds since 2021-02-20 00:00:00"
DEBUG 4:                 as a reference time of 20210220_000000 and 1 second(s) per time step.
DEBUG 3: NcCfFile::open() -> read time from the bounds variable "time_bnds"
DEBUG 4: NcCfFile::open() -> could not extract init time from the "forecast_reference_time" variable.
DEBUG 4: NcCfFile::open() -> could not extract init time from file name.
DEBUG 4: VarInfoFactory::new_var_info() -> created new VarInfo object of type "FileType_NcCF".
ERROR  :
ERROR  : NcCfFile::getData(NcVar *, const LongArray &, DataPlane &) const -> star found in bad slot
ERROR  :

[j-opatz]

Hello,

And thank you for your question.

I think this may be quicker to troubleshoot if you shared the sample data with us. Please follow these directions for using our FTP server and let me know when and where you've uploaded the file. We'll get you up and running with MET once we have the sample data.

[aamemiya]

Thank you for the response. I placed the file test_fcst.nc in the ftp site.

[j-opatz]

Can you please provide the path name that you placed the data under? I've looked under incoming/irap/met_help/amemiya_data, but the directory is empty.

If you had originally loaded the data to that directory, you may need to reupload your data since it didn't not occur correctly.

[aamemiya]

I am sorry for the trouble. I have uploaded the data again.

[j-opatz]

Thank you for the reupload of data, everything was available this second time and I was able to take a quick look at the file.

From what I can see inside the file, we're missing critical data in order for MET's plot-data-plane to work. Let's take the QHYD variable as an example.

From the printout for this variable, we see it's defined:

float QHYD(time, z, y, x) ;

For MET to know where to plot this data on a grid, 2 of these dimensions need to be evenly spaced grid information, which we indicated to MET via the * character. But from the dimensions of the array variables:

z = 36 ;
x = 15 ;
y = 20;
time = UNLIMITED ; // (21 currently)

We can see there's nothing to let MET know where on a grid to place the QHYD field. When you use the *, MET expects that grabbing those fields will describe the dimensions of the gridded field. But a dump of the x and y fields (which is what you tried to pass to MET) shows that no such information is available:

data: x = 9000, 27000, 45000, 63000, 81000, 99000, 117000, 135000, 153000, 171000, 189000, 207000, 225000, 243000, 261000 ;

data: y = 9000, 27000, 45000, 63000, 81000, 99000, 117000, 135000, 153000, 171000, 189000, 207000, 225000, 243000, 261000, 279000, 297000, 315000, 333000, 351000 ;

Likewise, the z and time variables did not have the information necessary to plot on a map.
Ideally you'll have two variables, one with your latitudes and one with your longitudes, fully defined in even spaced. As an example,

float Latitude(Y, X) ; Latitude:standard_name = "latitude" ; Latitude:units = "degrees_north" ;
float Longitude(Y, X) ; Longitude:standard_name = "longitude" ; Longitude:units = "degrees_east" ; Longitude:modulo = "360 degrees" ;

Where Y and X can be whatever resolution your grid is at.

If these data will act more like point information than a grid, it may be more useful to use the plot-point-obs tool instead. That will require running this data through a preprocessor (like PB2NC or a Python script) to get the netCDF style that MET can accept, but it will allow you to have irregular point data rather than relying on a grid.

I hope this helps you understand a bit more about what MET needs from a dataset to plot correctly. Please let us know if you have more questions on this, or if you feel this has answered your question, please select this as your answer.

[aamemiya]

Thank you for the answer. It helps me improve my understanding.
The sample data has coordinate variables as follows (I have manually added "standard_name" and "positive" attributes). I thought this works but MET still returns the same error. Does this mean these variables or attributes are not sufficient for MET to detect the grid information?

        double lon(y, x) ;
                lon:long_name = "longitude" ;
                lon:units = "degrees_east" ;
                lon:standard_name = "longitude" ;
        double lat(y, x) ;
                lat:long_name = "latitude" ;
                lat:units = "degrees_north" ;
                lat:standard_name = "latitude" ;
        double height(z, y, x) ;
                height:long_name = "height above ground level" ;
                height:units = "m" ;
                height:positive = "up" ;
        double time(time) ;
                time:long_name = "time" ;
                time:units = "seconds since 2021-02-20 00:00:00" ;
                time:calendar = "gregorian" ;
                time:bounds = "time_bnds" ;

[j-opatz]

That's correct, MET doesn't know how to interpret those data, even with the additional attributes you provided. As I mentioned above, the real issue is that the MET tool plot-data-plane is expecting a regularly defined grid for your x and y definitions, but they are "nonsensical" to it:

data: x = 9000, 27000, 45000, 63000, 81000, 99000, 117000, 135000, 153000, 171000, 189000, 207000, 225000, 243000, 261000 ;

data: y = 9000, 27000, 45000, 63000, 81000, 99000, 117000, 135000, 153000, 171000, 189000, 207000, 225000, 243000, 261000, 279000, 297000, 315000, 333000, 351000 ;

plot-data-plane expects a grid boundary between -90.0 and 90.0 for latitude, and 0.0 to 360.0 (or -180.0 to 180.0) for longitude. So to get the data readable by this tool, you'd need to (for example) reset y to 1 degree increments between -90.0 and 90.0, and x to 1 degree increments between -180.0 and 180.0.

Because your x and y variables ultimately determine how lon and lat are defined in the netCDF, they are what plot-data-plane needs to produce a grid. And as far as MET knows, the first point in your lon variable, (9000, 9000), doesn't exist on a standard grid so it errors out.

For another description of how MET uses projections and map coordinates, I'm going to link to the projection section of our Users Guide. It might help you better understand what's expected of gridded data.

[aamemiya]

Thank you for the reply. But I am still confused about the grid definition. My netcdf file has both 1-d coordinate variables with dimension names (x,y) and 2-d projected coordinate varaibles (lon,lat). Does MET need both of them? Or does it try to read first (x,y) as (lon,lat) information even when the file contains variables "lon" and "lat" with proper long_name ane unit attirbutes?
Sorry to bother you again, but I appriciate if you show an example of a minimal set of variables in a netcdf file that can be properly processed by MET.

[j-opatz]

No problem, I'm happy to go over a basic example.

For plot-data-plane, the tool needs a 2 dimensional field for a given variable to properly display. Those 2 dimensions can be labeled however you like for the input file: x and y, lat and lon, apples and oranges. It just needs to exist within the bounds of -90.0 and 90.0 for the north-south orientation, 0.0 and 360.0 (or -180.0 and 180.0) for the east-west orientation, and be regularly spaced (so no unequal gridspacing like 0, 3, 7, 22, 24, ...).

So for example, a netCDF input file called example.nc needs 3 variables to work in plot-data-plane: a north-south regularly spaced variable (we'll call it Y), an east-west regularly spaced variable (we'll call it X), and whatever variable we'd like to plot (we'll call it Temp). An ncdump command on the file would show the following:

ncdump -h example.nc
dimensions:
Y = 181 ;
X = 360 ;
variables:
int Y(Y) ;
int X(X) ;
float Temp(Y, X) ;

As long as the Y array looked like:

Y = [-90.0, -89.0, -88.0, ... 88.0, 89.0, 90.0]

And the X array looked like:

X = [-180.0, -179.0, -178.0, ... 177.0, 178.0, 179.0]

or:

X = [0.0, 1.0, 2.0, ... 357.0, 358.0, 359.0]

The Temp variable could be accessed by plot-data-plane with

plot_data_plane example.nc Temp.ps 'name="Temp"; level="(*,*)";'

This is a very basic example, and you could easily get results from a variable that has more attributes, finer grid spacing, etc. But it all starts with a variable being being defined on a regular spaced grid within the bounds of the north-south, east-west definitions.

Again, the problem with your file's x and y dimensions is that they're beyond the bounds of what north-south, east-west is on a globe. Maybe think of it this way: if someone told you to plot on a map the coordinate (9000, 9000), where would you put that mark? Even knowing that the grid mapping system is lambert conformal conic, or that the variable being mapped is called QHYD, it's impossible. That's essentially what you ask plot-data-plane to do for the first datapoint of QHYD with (0,0,*,*): it doesn't know where that latitude-longitude pair exists on a globe, let alone any of the other combinations, (9000, 27000), (9000, 45000), etc. Once you provide your data in traditional lat-lon pairs, plot-data-plane should work.

[aamemiya]

Thank you very much! Now I finally see how I can modify my data to make it readable.