CDO

Your file contains no metadata describing a rotated coordinate system.

Hi Brandan,
Thanks for looking into this. I actually selected a 4 grid square section for 3 days only from a very large NetCDF file that has 20 years data at hourly time-step. The original file is 14GB in size so not possible to attach. Here is some more info if that would help. the objective to convert the un-regular curvilinear (rotated) grid to regular coordinate system.

amuh@MJ086:/mnt/h/Basin Operations/F_HYD/Ameer/Nelson-MIP/Raw_Forcing Data$ cdo sinfo RDRS_v2_A_PR0_SFC_2000_2017.nc
   File format : NetCDF4 zip
    -1 : Institut Source   T Steptype Levels Num    Points Num Dtype : Parameter ID
     1 : unknown  unknown  v instant       1   1     42147   1  F32z : -1
   Grid coordinates :
     1 : curvilinear              : points=42147 (223x189)
                              lon : -127.0499 to -87.86075 degrees_east
                              lat : 42.03678 to 62.11168 degrees_north
   Vertical coordinates :
     1 : surface                  : levels=1
   Time coordinate :  157800 steps
     RefTime =  2000-01-01 12:00:00  Units = hours  Calendar = standard

Welp, did you get this data from caspar or dd-meteo? They both have tonnes of docs on the formats.
Is it on a native ECCC model grid?

Yes, this is ECCC (GEM) data, available on CaSPr as well as from MSC data mart.

So, how do you know that it is on a rotated grid? Docs on caspar suggest they also offer the data is regular coordinates. An ncdump -h of the original file might help me. Plus, you could cdo seltimeidx,1 infile.nc outfile.nc and upload a single time slice for our perusal.

I don't think there is any seltimeidx command available in CDO? here the outcome of ncdump - h for the original file

amuh@MJ086:/mnt/h/Basin Operations/F_HYD/Ameer/Nelson-MIP/Raw_Forcing Data$ ncdump -h RDRS_v2_A_PR0_SFC_2000_2017.nc
netcdf RDRS_v2_A_PR0_SFC_2000_2017 {
dimensions:
        rlon = 223 ;
        rlat = 189 ;
        time = UNLIMITED ; // (157800 currently)
variables:
        float lon(rlat, rlon) ;
                lon:standard_name = "longitude" ;
                lon:long_name = "longitude" ;
                lon:units = "degrees_east" ;
                lon:_CoordinateAxisType = "Lon" ;
        float lat(rlat, rlon) ;
                lat:standard_name = "latitude" ;
                lat:long_name = "latitude" ;
                lat:units = "degrees_north" ;
                lat:_CoordinateAxisType = "Lat" ;
        double time(time) ;
                time:standard_name = "time" ;
                time:long_name = "time" ;
                time:units = "hours since 2000-1-1 12:00:00" ;
                time:calendar = "standard" ;
                time:axis = "T" ;
        float RDRS_v2_A_PR0_SFC(time, rlat, rlon) ;
                RDRS_v2_A_PR0_SFC:long_name = "Analysis: Quantity of precipitation" ;
                RDRS_v2_A_PR0_SFC:units = "m" ;
                RDRS_v2_A_PR0_SFC:coordinates = "lat lon" ;

My bad! I meant -seltimestep,1. There are so many commands.
There must be more metadata in that file.

Hi Ameer and Brendan,

may I weigh in here. There are many operators, absolutely right.

In Ameer's case the rlon and rlat are just indices used by the 2D-lon and lat coordinate variables. The names rlon and rlat are misdirecting to rotated coordinates and it would be better to name them x and y.

The following remapping would work for variables of type (time,rlat,rlon) as described above - but your variable is of type (time,rlon). You can't remap it to a lon/lat grid.

To remap data on a horizontal lon/lat grid to a 0.15x0.1 global regular grid, e.g. with remapbil:

cdo -remapbil,r2400x1800 mydata.nc out.nc

Then you can select a better fitting region with the sellonlatbox operator afterwards.

-Karin

Sorry, I had to edit the answer above after recognizing that the variable in mydata.nc is float RDRS_v2_A_PR0_SFC(time, rlon).

The rlon makes me think this file has already been translated from rotated to normal coordinates. The CF Metadata standard uses rlon and rlat in its examples for rotated coordinates. If Ameer plots the data this would verify. "Raw" GEM model output is provided in GRIB2 format and in projected, not rotated, coordinates. My knowledge on this might be stale. With GEM GRIB2 data the worry is proper rotation of vector fields since vector orientation is relative to the projection.