In the upcoming 4.1.3 release at the end of this Summer, there will be a permanent change in how the fortran library is packaged.

In olden times, before shared libraries came along, the netCDF F77 API was packaged up with the C library. This meant that the same binary .a file served as a library for both C and Fortran 77. This was a somewhat unorthodox method of proceeding, but it worked well for netCDF until shared libraries came along.

 With shared libraries, the packaging of the F77 API with the C API has an odd side-effect: when compiling a C program, the linker wants to know where the fortran shared libraries are, even though there is no fortran code involved. Naturally we are not going to make our C users suffer this sort of indignity. After all, if they wanted to associate with Fortran riff-raff, they would not be C programmers!

 To fix this, we introduced the --enable-separate-fortran option in configure. When turned on (and it was turned on by default for shared library builds) the fortran 77 API is packaged in a separate library. Fortran users now have to link to -lnetcdff -lnetcdf instead of just -lnetcdf. (Note the extra "f" on the fortran library name).

 This works so very well that I am taking out all ability to build the fortran 77 and C library together. Starting in 4.1.3, a separate fortran library will always be built. The motivation for taking this feature out is to simplify the build system. There are numerous places where we have to do one thing for a combined library, and another for separate libraries. And this also doubles our test cases (although I don't actually check both build styles on all platforms anyway, as that would in impractical).

But as soon as I merge my branch into the trunk, this and some other configure options will go away, and the build system will be considerably simpler, which makes it easier to maintain and get correct on all platforms.

This week I read "Life Would be Easy If It Weren't for Other People" by Connie Podesta and Vicki Sanderson. (Thanks to Leslie in the NCAR library for getting this and any other book via interlibrary loan!)  I had heard about this book years ago - it comes highly recommended in the world of corporate project management.

The book is very good and worthwhile to read for engineers and especially their supervisors (a broad hint to Ethan!)

It outlines four styles of communication: assertive, aggressive, passive, and passive-aggressive. It reminds the reader repeatedly that the assertive form of communication is the only one that leads to long-term solutions to problems. Unfortunately, the other three are more frequently used. ;-)

We are constantly training and being trained by others as to which communication style works best. If we reward people for negative communication, they will continue to provide it. If we respond assertively, we not only have a better chance of solving the ultimate problem - we also make negative communication less effective. Most people will respond by changing to more positive communication modes.

NetCDF is not and never has been a one-person enterprise, since even before the first release of the software, more than 20 years ago. I am happy to say that within the netCDF team, positive and assertive communication is the normal mode. Without that, I don't think we would have enjoyed the product success that we have.

The real value of this book is in helping me see how my own communications can be made more effective and helpful.

 

A few weeks ago I attended the European Geoscience Union conference in Vienna. I learned a lot and talked to dozens of scientists and programmers about netCDF - it was very fun! The poster I presented can be found on our website, and gives an overview of the new features added to netCDF in the last few years (since the 2008 netcdf-4 release).

Version 2.1.22 of the UDUNITS package has just been released.

Here are the most recent entries in the CHANGE_LOG file:

• Corrected ut_compare(3) for Galilean units (e.g., "1.01 m" and "1.1 m").
• Corrected access to units database from documentation for both installations and the online webpages.
• Added shared library version numbers.

Russ is a very patient product manager. Some would fume over delay, some would rant and rave, but Russ doesn't do any of those things. 

Last December, when I told Russ it would take a few weeks to get 4.1.2 ready for release, he visited me in the coding cave and brought some supplies. As he rolled the boulder across the entrance, he called out that he had actually provided two months of supplies. I think that we can all agree that this was above and beyond the call of duty.

In fact, Russ underestimated what could be done with flour and baking powder, and those two months of supplies lasted until the beginning of March. Around that time, after the rat attack, I also ran out of candles. Fortunately the release was almost ready. After it was complete, Russ not only arranged to have the boulder rolled away, he was even waiting outside with a meal and some medical attention (for the rat bites).

See the netCDF web page for information about the new release, and to get a copy.

I hope to do releases a lot more frequently in the future. The 4.1.3 release should come in about 3 months. I love my coding cave, but I also like to see the sky at least three or four times a year. That means a branch of the code at the end of May, with hopefully the following features:

• refactored and much simpler build system (almost done on branch ed).
• netCDF disk-only files (to support gridspec and opendap).
• support for the new super-large format developed by the parallel-netcdf team.
• more hdf5 interoperability tweaks.
• start to switch documentation to doxygen.
  
• documentation fixes.
• upgraded libcf distribution.