Invalid coordinates in ucar2ropp

[Dave Offiler]

Helpdesk ID=165

Dear ROPP team,

I am a novice of ROPP, but I am probably going to do lots of work with it. So, thank you for the software, and apologies if I ask simple questions. A problem I have in ucar2ropp tool is that when I use it for converting ucar atmPhs data into ROPP format (so that I can use it in ropp_pp_occ_tool), everything is OK except LEO and GPS coordinates (r_LEO and r_GPS) which are all invalid (-99999000). I compared the ROPP occ data you provided online in the helpdesk inquiry No.143 with the occ file I produced by ucar2ropp. Everything is similar except the coordinates.

I would appreciate if you help me in this regard.

Sincerely yours, Salim Masoumi

[Dave Offiler]

Problem tracked to UCAR files containing POD in kilometers [kilometers/second] while the range-check limits are in metres [metres/second]. All unit conversions are performed just prior to writing the output ROPP-netCDF file, but the range-checking comes before this.

As a quick-fix for this Helpdesk item, a simple scaling (x1000) is applied within the low-level atmPhs read routine ropp_io_read_ucardata_atmPhs() in ropp_io/ropp/ropp_io_readnetcdf_get.f90. It is shown to work with ifort12 & pgf7.

This updated file has been provided to the user via email, with a request to test and confirm whether or not this fixes the problem. Assuming it does, this temporary fix can be included in v7.0.

However, this is a fundamental issue; all units in the UCAR atmPhs netCDF files are assumed, not actually read as attributes, so any change to the file units (say to m or m/s) would break this fix. Worse, it appears that even for ROPP netCDF files, there is no unit checking/conversion prior to range-checking (only after, just before writing). Hence a user emulating the ROPP netCDF content, but using non-standard (for ROPP) units could break the range-check.

Without going back to old ROPP version, I suspect that when udunits library was replaced by the ut_convert() system (ROPP-3/4?), the units conversion was moved from 'on read' to 'on write'. A correct solution would be to either unit convert all numeric parameters on read, or perform this task within the range-check routine. At the least, all UCAR netCDF parameter attributes should be read (as they are for ROPP-netCDF) and not assumed, to future-proof against arbitrary unit changes.

While straightforward, a proper treatment would not be trivial and would need to be thoroughly tested with special datasets with non-standard units, so is outside he scope for v7.0, so perhaps should be reviewed for v7.1.

[Dave Offiler]

Since this particular defect has been fixed to the satisfaction of the user who raised the problem, this ticket is hereby closed, and a new ticket (#369) raised a a more general issue.