DWD - beta test report

[Dave Offiler]

Beta (v0.9) test report from Andreas Rhodin at DWD.

He notes what could be considered some defects in the current TOOLS & IO sub-packages, so I've assigned this a type of 'defect' (as worst case) for milestove v1.0. However, several points raised are more by way of enhancements (and not ncessarily for ROPP v1.0) and others are comments to be considered (but possibly not acted upon) for long-term future versions.

Andreas provided some modified code files. It's not appropriate to commit them to the current SVN repository as they are not tested, but merely 'candidates for potential change'. Should we have a new 'ropp_user' trunk to exchange such files? Should they be attached somehow to this Ticket? Just emailed to the development team? For internal access, these files are currently in ~frdo/packages/ropp_user.

I've assigned this ticket to myself to manage actions to the complete report, not that I plan to action every item myself! All ROPP developers should review and comment on Adreas' report.

Dear ROPP-Team,

Below find my feedback to the ropp 0.9 beta suite.  I recognized that
you fixed a couple of inconsistencies present in version 0.8 I was
just going to report when the 0.9 announcement came out.

----------------------------------------------------------------------

> Even if you've not done a great deal with the packages so far, 
> we would be pleased to hear of your experiences by answering the
> following questions:
> 
> 1) Have you downloaded the v0.9 Beta packages?

Yes

> - if yes, which ones?


   TOOLS            downloaded + installed        
   IO               downloaded + installed
   FM               downloaded
   1DVAR            downloaded
   Documentation    downloaded + read

  
> 2) What platform (operating system) and compiler(s) are
> you using, or intend to use, for the beta testing?


  Linux  / Intel ifort (currently Version 8  )
  Linux  / NAGf90      (currently Version 5.0)
  AIX    / XLF90       (currently Version 9.1.0.7)

 
> 3) What platform (operating system) and compiler(s) do you
> intend to use for an operational implementation ?


  We are currently using the TOOLS and IO libraries for diagnostic
  purposes (and data exchange within ROPIC). Up to now the code runs
  on the LINUX platform during the preprocessing. We intend to use
  it in the 3dvar under IBM/AIX as well.


> 4) Have you built/installed the downloaded packages?


  Yes, TOOLS and IO.


> - if no, was this because there were problems in the ROPP build
>   itself, or in installing 3rd party dependency packages?


  Up to now we did not use FM and 1DVAR because we are evaluating our
  own forward models using our 3dvar. Maybe we will evaluate FM later.


> - if yes, did it go smoothly, or did you have to modify anything?
>   (And if so, what did you do to correct the problem?)


  We had to modify some routines, cf. the detailed report below.


> 5) Have you run any of the test scripts supplied with the packages?
> If so, which ones, and with what result?

  No.

> 6) Have you reviewed how you would plan use the package an operational
> environment?
> 
> - using the package tools as they are? Which application tools do
>   you plan to use?
> 
> - porting (parts of) the code to use as callable subroutines
>   in your own applications? Which top-level routines would you
>   use?


  We link to the libraries FM and TOOLS using Datatype ROprof and
  NetCDF I/O routines acting thereon. ROprof has been extended to hold
  components required by the ray-tracing operator.


> 7) Is the documentation adequate to describe:
> 
> - the overview of the packages and their functions
> 
> - the build/install/test system and usage
> 
> - the code descriptions


  Yes


> 8) Do you have any other comments about the beta package?
> What areas need to be improved?


To my opinion the ROPP-I/O format and the underlying Fortran90 data
types (type ROprof) are very nicely designed in order to hold all data
relevant to radio occultations.  However I had some problems in
installing the packages. My general impression is that the package is
rather complex and it may be advantageous to have routines which are
more tailored to handle only the most basic operations. For instance I
would prefer not to link the udunits package but make conversions by
myself.

Concerning the f90 code itself I would propose to have more functions
and subroutines defined as contained routines within modules, instead
of being external routines with only the interfaces provided within
modules. This has the advantage that it is more simple to program,
prevents inconsistencies between external routines and their
interfaces, and does not mix up the name spaces of Fortran and C
used for linking (see below for more details).

---------------------------------------

Report of problems on specific platforms:


1) NAG f95 compiler: Inconsistent INTERFACE blocks

  In your configure script you recommend compiler option -dusty. 
  This basically prevents the compiler to perform some error
  checking. I prefer to run f95 without that flag so that error
  checking remains enabled.

  The NAG compiler checks for consistency between the
  interface blocks and the associated external programs and reported a
  number of mismatches. Most of these mismatches are related to
  missing INTENT attributes in the interface blocks. I modified the
  following source files:

  ropp_tools-0.9: arrays/arrays.f90
                  flib/flib.f90
  ropp_io-0.9:    ropp/ropp_io_read_ncdf.f90

2) IBM AIX without -qextname

  Although it is recommended to compile the udunits package (and all
  routines which call it) with the -qextname option I did not do that
  because it is not the practice at DWD. The -qextname option adds an
  underscore to all names of Fortran routines in the link step and
  thus separates the name-spaces used by Fortran and C. The following
  problems result from compiling with -qnoextname:

  The external Fortran routines ToUpper and ToLower conflict with c
routines
  toupper,tolower. Thus I have put them as contained subroutines into
  module ropp_io (there the interfaces are defined anyway). By doing
  this the names used for linking will become something like
  ropp_io_NMOD_toupper.

  I modified:
  ropp_io-0.9/ropp/ToUpper.f90      (removed)
                   ToLower.f90      (removed)
                   ropp_io.f90
                   Makefile         (ToUpper,ToLower removed)
  ropp_io-0.9/build/Makefile        (ToUpper,ToLower removed)
-------------------------------------------------------------------------------

I attach the files arrays.f90, flib.f90, ropp_io.f90 and
ropp_io_read_ncdf.f90 so that you can consider to include the changes
in the next release.

Best Regards, Andreas
-------------------------------------------------------------------------------
Andreas Rhodin
Deutscher Wetterdienst (DWD)      (German Weather Service)
Abtlg. FE12                       Phone: +49 69 8062 2722
Postfach 10 04 65                 Fax:   +49 69 8062 3721
D-63004 Offenbach                 Email: andreas.rhodin@dwd.de
Germany                           Web:   http://www.dwd.de
-------------------------------------------------------------------------------

[Huw Lewis]

Note NAG compiler errors caused by different INTENT attributes in interface blocks solved for v1.1 release. Will investigate other comments for v1.2.

[Huw Lewis]

• Use of udunits is widely used in ropp_io module to perform conversions of units and valid range on reading/writing data. Structure of ROPP has been simplified a little with v1.2 (e.g. removing unused tools libraries and reducing dependencies).

• Initial architecture from v1.0 still remains (i.e. use of external subroutines with interfaces). Significant amount of work would be required to re-engineer this, and many routines are used in several places. The current method is probably the best solution for ROPP.

• NAG compiler: many of the inconsistent interface blocks were corrected at v1.1. I have now recompiled all modules with NAG without -dusty compiler option with no problems. This compiler option has been removed from the /system/ folder of example configure scripts in ropp_test.

• Fortran routines ToUpper and ToLower have changed name to To_Upper and To_Lower to avoid potential clashes with C routines as mentioned. This would hopefully solve the reported problem. See [1566]

All specific issues fixed. Ticket closed.