Issue with point distance operation

HARP
1

netcdf IASI_o3_subcolumn_IASI-B_20140826 {
dimensions:
time = 15 ;
latitude = 788 ;
longitude = 120 ;
vertical = 2 ;
spectral = 3 ;
variables:
double latitude(time, latitude, longitude) ;
latitude:units = “degree_north” ;
latitude:_FillValue = NaN ;
double longitude(time, latitude, longitude) ;
longitude:units = “degree_east” ;
longitude:_FillValue = NaN ;
int time(time, latitude, longitude) ;
time:units = “” ;
float ozone(time, latitude, longitude) ;
ozone:units = “DU” ;
ozone:_FillValue = NaNf ;
float sza(time, latitude, longitude) ;
sza:units = “” ;
sza:_FillValue = NaNf ;
float azim(time, latitude, longitude) ;
azim:units = “” ;
azim:_FillValue = NaNf ;
double surfpress(time, latitude, longitude) ;
surfpress:units = “Pa” ;
surfpress:_FillValue = NaN ;
float surftemp(time, latitude, longitude, vertical) ;
surftemp:units = “K” ;
surftemp:_FillValue = NaNf ;
double ctp(time, latitude, longitude, spectral) ;
ctp:units = “” ;
ctp:_FillValue = NaN ;
float clf(time, latitude, longitude, spectral) ;
clf:units = “%” ;
clf:_FillValue = NaNf ;

// global attributes:
:Conventions = “HARP-1.0” ;

Greetings Sander,

We are using Harp 1.23 to ingest the official EUMETSAT IASI L2 combined products. For each day of 14/15 orbits, we create a harp-compliant “daily” product. Its contents and dimensions, etc. are given above.

However, at a next step we wish to create overpass type files using the point_distance command. Even when setting the search radius at 2500km it does not find any data, which is well, impossible, since we are talking Total Ozone, the best species in the Continent.

I am guessing that the point_distance operation does not like the 3D/4D variables? any way to overcome this issue?

Thanks!
MariLiza

2

This will not work indeed. Also, HARP should not give you 0 results, it should complain when you are trying to perform a point_distance() operation that it could not derive variable 'latitude {time}'. The point_distance() operation only works on a one-dimensional time series, not on a time series of irregular lat/lon grids.

I am not even sure how you would envision a point distance filter to work on an irregular {time,latitude,longitude} grid anyway. The result can never be a lat/lon grid again.

I see two options. Or you go the gridded approach, but then you should probably regrid each orbit on a fixed lat/lon grid (bin_spatial()). And if you do that then you don’t need a point_distance filter, since you can pre-calculate which grid cells you would need.
Or, you drop the latitude/longitude dimensions, and treat everything as a flat time series. You can do this on the files you have with flatten(latitude);flatten(longitude);point_distance(..., ..., 2500 [km]).

1 Like
3

Thanks Sander, I was afraid of that. I was kind of hoping that it would miraculously read in the 2d lat/lon arrays and check each of the “time” dimension as a point/tuple in lat/lon. Of course, I would still be left with the issue of the (time,3D) arrays.
Anyways, I guess the answer is to do what we always did, collapse everything in the time dimension and just write out more variables, no trouble.
Many many thanks as always,
MariLiza