Stig's wishlist

[Ian Culverwell]

Stig made the following suggestions some time ago.

Sent: 10 November 2011 12:46
To: 'Stig Syndergaard'; Offiler, Dave; Burrows, Chris; Kent Baekgaard
Lauritsen; Kjartan Kinch; 'Hans Gleisner'; Johannes K. Nielsen; Hallgeir
Wilhelmsen; Kristian Rune Larsen; Frans Rubek
Cc: Culverwell, Ian
Subject: RE: A ROPP wish list....

Hi Stig,

Sorry for delay in replying.

1) No comment - Dave's already replied.

2) I agree there's some overlap between the codes.  Personally I regard merging them as "nice but not necessary".

3) Certainly, I think ropp_pp should handle missing data as consistently as the other modules. Higher priority than 2.

4) Personally, I favour a solution where the _actual_ values of the parameters used in a run are available. This would then show which of the params in the "config" file were overwritten at the command line, if we wish to retain that option.  If you don�t like all these parameters written to the global atts of the ncfile, then maybe we could hold them as a separate (ncdf?) file. Or bundle them all up as as a new (quite long) character variable, which consists of a set of strings like "param1 = 74.21", accessible to anyone with ncdump or ncks, in the existing ncfile?  I don�t know.

5) I like the idea of namelists.  I don't know why we don�t use them.  IMHO the DIY code parsers in ROPP are a pain, and something part of the Fortran standard (which they are at f90) would be better.  My fortran 90 notes advise caution, though, and say that "[namelist's] use is very restricted by the standard". They don't elaborate on this.  But I think it's worth trying. 

As for who is going to do all these things, when agreed - one for PT9?  I'd also like to raise the general subject of how ROPP developments are decided/agreed/managed, at PT9.

Regards,
Ian.


-----Original Message-----
From: Stig Syndergaard [mailto:ssy@dmi.dk]
Sent: 02 November 2011 16:16
To: Offiler, Dave; Culverwell, Ian; Burrows, Chris; Kent Baekgaard Lauritsen; Kjartan Kinch; 'Hans Gleisner'; Johannes K. Nielsen; Hallgeir Wilhelmsen; Kristian Rune Larsen; Frans Rubek
Subject: A ROPP wish list....

Hi Dave, Ian, Chris,

First of all, my apologies for yet another long email..... it's not anything urgent; take your time answering it.

Over the past few weeks I did some changes to ropp_pp, ropp_io and ropp_utils codes in the dmi_trunk. In the process I found a few general things that I thought could/should be different, but I want to hear your opinion on it.

1) Is there a reason why Makefile.in files are included in the repository? They seem to be generated automatically from makefile.am files when building, and the ones that are build in my environment are generally different from the ones in the repository. The problem I have/had is that when I want to see my diffs (using svn diff) in a given directory, those changes in Makefile.in comes rolling down the screen, whereas I wanted to get an overview of the changes that I made to actual source code in that directory. Consequently I deleted all Makefile.in from the dmi_trunk repository in those modules that I've been working in (ropp_pp, ropp_io and ropp_utils). This solves my problem, but is it a good idea in general to get those files out of the repository? I also deleted a few other automatically generated files (configure and
aclocal.m4 files). Are they needed in the repository?

2) Would it be an idea for a future ROPP version to merge ropp_pp_occ_tool.f90 and ropp_pp_invert_tool.f90 into one code. There are many similar things in the two codes and it would be much easier to maintain the codes if they are in one. I don't think it would be a problem to have one ropp_pp_tool that can both process from phases and from bending angles. It could be decided by a flag, and perhaps as default be based on what data levels are present in the input file.

3) As far as I understand, the ropp_pp tools are not geared to handle missing values, but missing values can be generated on input read because of the range-checking. I know that for output I can set the no-ranchk option, but I'd rather have range checks being fully optional on both input and output all over the ROPP codes. Certainly, in our operations, we need to handle missing values correctly or simply make sure that they are not there (and let processing terminate gracefully if there are some). Alternatively, instead of setting missing values on range checks the rangecheck could set the <variable>_qual values to 0 instead of 100. This way the _qual values would indicate which data points failed the range check. Would that be an idea?

4) As it is now, the ropp_pp tools take both a configuration file and other cmd line options. The command line options include parameters that have influence on how the data are processed and they can override the parameters in the config file. In my opinion it would be better/cleaner to have all parameters that have influence on the processing in the config file, and only a few other options (besides the config file name) which are not critical for the processing (such as output filename, output flags, and the -d options) on the command line. In our operational system we need to always be able to sort out exactly the parameters that were used to generate a particular file, and this could be most easily accomplished if such processing specific parameters are only in the config file. Also, I think it could be very useful if the config file name appears in the NetCDF output as a global attribute. One could then have different config file names (in a local setup) when running with different parameters, and always know from the output file which parameters were used.

5) I realized when looking in the codes that it takes several subroutines (four or five I think) to read a simple config file. Why not use the Fortran namelist feature? Is that something that has been considered?

Please let me know your opinions on these issues.

Best regards,
-Stig

[Stig Syndergaard]

Obsolete by newer tickets. Closing.