Should ascending occulations be non-optional in ROPP netCDF?

[Dave Offiler]

If the ropp_io_ascend() routine finds the profile(s) to be descending and (if not explicitly skipped), it reverses the arrays to be ascending profiles. From ROPP-3, it also outputs a comprehensive warning message.

UCAR's netCDF profiles can be descending, and converting to ROPP netCDF with ucar2ropp preserves this order (unless explicitly thinning which isn't normally needed). Using another ROPP tool on this file (e.g. ropp2bufr) then generates the warning messages. This is in fact a normal (and required) operation for the thinner pre-sort step, and such warnings should not be issued in this case. The current warning messages are also confusing because they refer to 1dvar.

At a wider view, this suggests that:

• such warnings should be issued by the application, not the low-level routine (e.g. by passing a code back to the caller to ignore or issue an app-dependent message)
• the converter tools ucar2ropp, gfz2ropp etc should perform the array ordering so that output in ROPP netCDF always be ascending (or at least by default)
• as the thinner pre-sort requires ascending profiles (even if the thinner itself can deal with either), warning messages are inappropriate
• ditto the 1dvar

At a generic level, this would be a good time to review the policy of - although ascending is standard in ROPP netCDF files - descending is allowed by having (in e.g. ropp2ropp) a user-option to leave the profile 'as-is'.

The proposal is to remove this user-option and to always convert descending to ascending on ROPP netCDF read and write, and not to issue any warning, since this would be documented to happen.

Alternatively, leave the option in the code for power users (if there is a justified reason to require mixed profile ordering), but do not document the option. Note that this would equally apply to background profiles (e.g. ECMWF) as well as to observed occultations.

Obviously the requirement for the option needs to be reviewed within the GRAS SAF Team (including Chris & Axel) with all users before any change.

(NB when thinning by any interpolation method, the output is always in the same order as the input set of 247 levels (ascending in the distro files), even if the command line 'leave alone' option is present and the full input profile is descending. Similarly, the 1dvar output will always be ascending, so there are operations where there is no user choice to preserve the order. Having ropp2ropp generate multi-files with mixed profile ordering is asking for trouble too!)

[Dave Offiler]

The man page for ucar2ropp is clear that the intention is that sorting to ascending is the default action if the original UCAR netCDF is in descending order. The existing code was incompatible with that statement, as sorting was only implicitly done if one of the interpolation thinning options was required. Sorting would not be done for no (default) or SAMPLE thinning.

ucar2ropp code modified to call ropp_io_ascend() (and rop_io_thin()) unless the -u switch is present. Tested & committed as part of [2222].

Note that the warning messages from ropp_io_ascend() are unchanged, but I think these messages should only be issued when the -d (diagnostic) option is present.

Leaving this ticket open, as there are wider issues to be debated.

[Huw Lewis]

Note that the warning messages functionality has been reviewed and updated. See #149. Any warnings related to ascending/descending profiles are only output when the -d option is specified (msg_ROPP = VerboseMode), otherwise the reordering is done 'silently' as default.

Leaving ticket open.

[Huw Lewis]

Issue raised at GRAS SAF Project Meeting. No objections to general idea that occultations should be in descending order as default. Maintain '-u' option for 'super-users'.

Ticket closed as fixed.