id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
178	Should ascending occulations be non-optional in ROPP netCDF?	Dave Offiler	Huw Lewis	"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!)"	task	closed	normal	4.0	ropp_io	3.0	fixed	Profile, order, ascending, descending, netCDF	Huw Lewis