NetCDF reader bounds check incorrect

Bug #930706 reported by Adam Candy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fluidity
Confirmed
Wishlist
Stephan Kramer

Bug Description

Fluidity will error with a 'Point ... not found ...' error when requesting data at a point on the boundary of a NetCDF file.

For example, when requesting z for x=-1.0, y=0.0 from a NetCDF file containing data z(x,y) for x,y in [-1.0,1.0].

To reproduce this behaviour, see test case 'netcdf_read_free_surface' (currently in the branch 'lp:~fluidity-core/fluidity/freesurfacefromnetcdffix' - soon to be merged to trunk). In this case the NetCDF file is created by the Python code createnetcdf.py. The mesh lies in the domain x,y in [-1.0,1.0] and the x and y bounds of the NetCDF file have had to be relaxed to [-1.2, 1.2] to avoid the above error. Using [-1.0, 1.0] will give the above out-of-bounds error.

Apply the following patch to tests/netcdf_read_free_surface/createnetcdf.py and run this test case to reproduce the error:

10,11c10,11
< x = arange(-1.2, 1.21, 0.2)
< y = arange(-1.2, 1.21, 0.2)
---
> x = arange(-1.0, 1.01, 0.2)
> y = arange(-1.0, 1.01, 0.2)

Revision history for this message
Jon Hill (jon-hill) wrote :

Stephen has agreed to arrange a meeting for interested parties to consolidate and refactor the netcdf code. There are at least three different implementations of the reader and all will show this bug.

Changed in fluidity:
assignee: nobody → Stephan Kramer (s-kramer)
Revision history for this message
Jon Hill (jon-hill) wrote :

GMT API is new in version 5. There are C and C++ bindings, plus a F77 interface to these. More details here: http://gmt.soest.hawaii.edu/5/GMT_API.pdf

Revision history for this message
Jon Hill (jon-hill) wrote :

NetCDF formats we need to support to retain current functionality:
 - GMT grd (bathymetry data)
 - ERA40 ocean forcing
 - NEMO output
 - CF 1.1 (http://cf-pcmdi.llnl.gov/conformance/requirements-and-recommendations/1.1/)

For future work we might also like to consider:
 - NCEP-NCAR reanalysis data (also requires additional routines in the ocean_forcing code)

Any others?

Revision history for this message
Stephan Kramer (s-kramer) wrote :

A number issues with the current netCDF reader(s):
1) The lon,lat grid is assumed to be equidistant (in lon,lat space). It simply take the 'actual_range' attribute of the 'longitude' and 'latitude' variables and divides this by the 'dimension' to get a dx and dy. Thus it totally ignores the actual values of the 'longitude' and 'latitude' variables. This obviously breaks for non equidistant grids (do we need these?) and also silently gives the wrong answer if the 'actual_range' attribute is not up-to-date (for instance after running ncks).
2) The variables other than 'longitude' and 'latitude' are all assumed to be functions of the form f(lat,lon), i.e. it ignores the specified 'dimensions' of the variable. So, if a function is stored as f(lon,lat) it will garble the data without warning. Question again: do we only need f(lat,lon) variables?

Jon Hill (jon-hill)
Changed in fluidity:
status: New → Confirmed
Revision history for this message
Jon Hill (jon-hill) wrote :

As discussed at today's dev meeting, this bug has turned into a remit to rewrite the NetCDF handling in Fluidity. A blueprint will be opened and added here.

Changed in fluidity:
importance: Low → Wishlist
Revision history for this message
Jon Hill (jon-hill) wrote :

Blueprint here:

https://blueprints.launchpad.net/fluidity/+spec/netcdf

This bug has been made into a wishlist and further discussion should be on the blueprint.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.