[Paraview] netCDF reader

[Brockmann Patrick]

Moreland, Kenneth a écrit :
> The netCDF reader in ParaView implements the COARDS convention, which 
> is a subset of the CF convention. To the best of my knowledge, both 
> conventions define the spherical coordinates in the same way. So if 
> you have a netCDF file containing the CF convention for latitude and 
> longitude, then the ParaView netCDF reader should understand that.
>
> That said, I see that the netCDF reader will only actually create 
> spherical coordinates for 3D grids. I am not sure I remember the logic 
> behind that, but I think it was that in general it is usually better 
> to visualize a map surface as a 2D projection to prevent occlusion and 
> that it is ambiguous what the height of the surface should be. That 
> said, it is easy to implement spherical coordinates to 2D grids. I 
> just checked in a change that creates a sphere at radius 1.
>
> The idea of the netCDF reader outputting a vtkPolyData is unworkable. 
> Many netCDF files contain 3D grids, and vtkPolyData is incapable of 
> representing those. It could always output a vtkUnstructuredGrid, but 
> this is a highly inefficient format for storing the structured arrays 
> stored in netCDF COARDS files. It is conceivable that the netCDF 
> reader could always output a vtkStructuredGrid. But that means that 
> non-COARDS files are forced to also output vtkStructuredGrid and they 
> loose the features for using vtkImageData. I know there are issues 
> with the VTK/ParaView pipeline when you change the output of the 
> reader when you change the dimensions. But there are also similar 
> problems when you change the extent and dimensionality anyway, so I 
> don’t know how much help such a change would make.
>
Kenneth,
Thank you for your answer.
Indeed my main reproach for that filter is that I get different 
structures (a vtkImage or a vtkRectilinear Grid or a vtkStructuredGrid)
following the netCDF grid read.
COARDS convention deals with regular grids in a sens that the cross 
product of the coordinates variables (1D) define the grid.
Define different structures because the grid has regular spacing or not 
is not what I would have computed.
I am doing some tests and I will propose something using only 
vtkStructuredGrid.

I have identified those points which causes problems with the actual 
/ParaView3/VTK/IO/vtkNetCDFCOARDSReader.cxx
- if a regular spacing coordinate variable decreases (90 to -90 for 
example), you always get a vtkRectilinear grid.
It should reach, wth the computing choice made, to the creation of 
vtkImageData. This is the case if you put
the axis in an increasing order.
You can correct this by placing a fabs set on tolerance variable
108c108
< double tolerance = fabs(0.01*this->Spacing);
---
 > double tolerance = 0.01*this->Spacing;
- Test on units should be case independant
line 133, units.find(" since ")
I have netCDF files where "since" is typed with uppercase (generated by 
ferret software from the NOAA/PMEL).

Spherical coordinates should be possible in any case (regular spacing or 
not), even with a 2D variable where
height is 0 because field is at surface.
User choices for zorigin and zscale should be taken in consideration . 
Both set to 1 by default.
In addition, a user choice zpositive to tell the direction in which the 
coordinate values are increasing
should also be proposed. With allowed values : up or down (up by default).
Perhaps also a zorder choice to treat files where zdimension has to be 
reordered to get k=1 representing
surface.

There is also the problem of connectivity and blank cells (and Z 
clipping range - in spherical coordinates you
don't want to see the globe when missing cells exist).
Plus, the fact that CF conventions covers also curvilinear grids where 
longitudes and latitudes
are described with a 2D arrays. This is why I haved used a vtkPolydata 
structure (with limitation
that the application was not really to visualize 3D field, only 2D 
fields in a 3D mapping when
projection uses spherical coordinates.

Thanks for reading.

Patrick

-- 
LSCE/IPSL, Laboratoire CEA-CNRS-UVSQ
Data Analysis and Visualization Engineer
IPSL Global Climate Modelling Group
mailto:Patrick.Brockmann @ cea.fr
--