Participating in the NetCDF Community

Russ Rew

NetCDF Annual Update


Why Participate?

  • To help extend netCDF to meet an important need
  • To fix a bug that affects you or your users
  • To help the science community
  • To participate in a successful software product

What Can We Collaborate On?

  • Bug fixes, performance improvements to the netCDF libraries and tools.
  • New features for the libraries when they fit netCDF development plans and mission.
  • Other software/standards efforts if they fit within the Unidata mission.
  • We have more work than we know what to do with. See Jira site for some ideas.

With Whom?

  • University Meteorology/Earth Science researchers and students.
  • Large science agencies like NASA, NOAA, NCEP.
  • Scientific software developers around the world.

Where Do We Collaborate?

  • NetCDF World HQ is in sunny Boulder, Colorado, at the Unidata Program Center.
  • Unidata is always present in some form at the AGU, AMS, and EGU meetings. NetCDF team members are not always present.
  • We also seem to attend various Washington D.C. Meetings about once a year.
  • For large users we sometimes do on-site workshops (NASA, NCEP).
  • Anywhere, via the internet!

How Can We Collaborate?

  • You can build beta releases and send the results to
  • You can send us code/documentation fixes.
  • You can actively contribute to the netCDF mailing list, answering questions.
  • You can develop an API for your favorite language, or a tool.
  • You can contribute tests.

How to Beta Test NetCDF

  • Beta releases (and release candidates) are announced on the netCDF mailing list.
  • Build and test, sending results to
  • Put the version you are testing in the email subject line.
  • Send an email if it worked, telling us.
  • If it didn't work, also send configure/make output, and config.log file.

Notes on Providing Code

  • Start from a svn checkout/update, or today's daily snapshot. Code changes quickly sometimes!
  • Diffs are fine.
  • Send everything to to ensure it gets tracked and not forgotten.

Notes on Providing Code

  • No platform-specific optimizations without proper autotools integration.
  • Code is closely reviewed may not be used.
  • Follow examples of tests.

Providing Tests

  • Best way to demonstrate a bug is to send in a simple test that isolates the bug.
  • Look at the tst_SOMETHING.c files in nc_test, nc_test4 for examples.
  • Test code should not accept command line parameters, and should not depend on human reading of output.
  • Return 0 for success, anything else for failure.

Ways and Means

  • NetCDF planning now takes place on jira site:
  • Code is available from subversion repository:
  • Check-ins are restricted to Unidata.
  • Send code diffs to: