Keep interface consistency with preexisting software

[marq]

This is more of a discussion starter (I hope).

So far, I have taken parts of the software (in particular the code for ncdf90 and udunits90) from other libraries of mine, most notably tools90, math90 and ncdf90 (which will have their own websites very soon (early November). The advantage is that more or less reasonably tested code could simply be used; over time I complete(d) the documentation (and still do), and that is beneficial for everyone. In addition, updates to the parent library can be included into ROPP by simply including a new version. There will be a couple of more modules coming for the 1DVar; much of what I have done over the last few days is cleaning up code in that libraries for the future inclusion in the ROPP.

However, from (my) maintanance point of view, bugfixes should really go through the main library instead of applying local patches in ROPP without feeding them back to the parent library. Another issue is that interfaces should be kept consistent with the parent library, as should the module files be. Because if ROPP is installed over an already existing ncdf90 (say), and the interface changes, programs will core dump without any reasons. If ROPP and tools90 libraries are used in the same program, a uncoordinated change in the interfaces on one side will result in braeking the code (yeah, I had that when I started to try to process Axel's PD data...:-(()

Yet another issue is that we sometimes only have subparts of the modules from the original library. That is desireable from Dave's consolidation point of view (#40). I have started experiment with a 'lite' version of modules (in ropp_tools/strings/strings-lite.f90) which evaluates to a strings.mod when compiled, but only has the interfaces for those routines actually contained in the stripped down version of the full strings module. This means that installing ROPP over an existing tools90 installation removes functionality, and that's not so nice if you have other programs relying on that. The solution is to reinstall the tool90 library on top of the ropp_tools, as one then gets the tools90 version of the software, and additional functionality from the ropp.

I've decided to give Dave his consolidation and use the above mentioned workaround for my development environment. However, I still have to rely that you won't change the interfaces to all preexisting functions and subroutines, as this would break a lot of my (and maybe other people's) stuff.

On the other hand I see a danger that some divergence will sooner or later occur if there isn't a firm commitment to keep the interfaces consistent. So I would like to ask you to think about how you want to handle this issue in the future:

a) Commit to interface consistency with the preexisting libraries and use the website of

these libraries for bug reports / fixing. In that case, I would sit down and document how to import updated versions into the ropp code base. I would also commit to the usual open source "support" for these libraries (i.e., helping to fix things if time allows, and give access to the development repository).

b) Decide to avoid the dependency on my OS libraries. That's of course fine with me, but

in that case I would like to ask you to change the routine and module names for all components.

Let me know what you think.

[Dave Offiler]

Chris' library routines should be considered 3rd party, just as netcdf is[1]; we don't go modifying interfaces to netcdf, so we shouldn't for the (subset of) tools90. Unless and until such time that Chris no longer supports the code.

The issue of support for 3rd party may well be important to EUMETSAT, so keeping the formality of requesting the code maintainer (Chris) for bug-fixes and suggested mods/additions should be clear. Lincence to use and (in the future if Chris declines to maintain the code) modify this code is already provided by Chris.

Chris - you still need to provide me with the generic list of PES for inclusion in our Beta Licence and the GRS SAF Status Report to the SG - where the SG will need to sign off the PES. Otherwise, Eum will assume ownership and IPR...

[1] The obvious difference being that we distribute & build Chris' code with ROPP.

[(none)]

Milestone 3.0 deleted

[Dave Offiler]

As at ROPP-2 (v2.0) release, Chris' code bundled with ROPP is limited to:

ropp_utils: messages library

ropp_io: netcdf & udunits interface libraries

The messages functionality will be completely re-written for ROPP-3, leaving the IO interfaces which are fairly stand-alone and will remain complete. At that point this ticket may be closed as business-as-usual.

[Huw Lewis]

Messages library is still within ROPP-3. Aim to modify messages (and close ticket) by ROPP-4.

[Huw Lewis]

Messages library has been updated with extended functionality (see #149). Note udunits dependency has also been removed at ROPP-4, further limiting use of Chris' library routines.

Ticket closed as fixed. Further consistency with PES should be continued as business-as-usual.