search

visit-dav / visit

VisIt - Visualization and Data Analysis for Mesh-based Scientific Data
https://visit.llnl.gov
BSD 3-Clause "New" or "Revised" License
438 stars 116 forks source link

Can netcdf reader pull out a 3d block of a 4d array? #12100

Closed brugger1 closed 3 years ago

brugger1 commented 4 years ago

I had a user call that has netcdf files. He has a 4d array in it and would like to pull out a 3d block from it. Is there any way to do this?

markcmiller86 commented 4 years ago

Is the question about whether the netCDF API supports doing this or whether one of the flavors of the uber-netCDF plugin can do it?

If the 4th dimension is time (or in netCDF parlance the unlimited dimension), then yes, that is the natural modality of access for netCDF and our plugins likely also handle that. Otherwise, read on...

If the netCDF file is an HDF5 file (newer versions of netCDF can use HDF5 under the covers), then yes, obviously, it is possible by going direct through the HDF5 API.

brugger1 commented 4 years ago

The question is whether our generic netcdf reader handles it. I know the BOUT reader handles 4d arrays with one of the dimensions being time just as you mentioned.

markcmiller86 commented 4 years ago

The code at our around this line in avtBasicNETCDFReader.C suggest no...we handle only up to 3 spatial dimensions...

https://github.com/visit-dav/visit/blob/b56dfd2f7dda9f6428f7a0d755ea1c2f34ecedab/src/databases/NETCDF/avtBasicNETCDFReader.C#L440

aowen87 commented 4 years ago

It looks like the first dimension in this variable is a laser. He also would like the ability to plot variables of X-dimension. Is there a reason that the reader currently doesn't handle higher dimension variables (tensors, arrays, etc.)?

markcmiller86 commented 4 years ago

It looks like the first dimension in this variable is a laser.

Well, then maybe our notion of multi-block would work where each laser is one block of a multi-block object???

He also would like the ability to plot variables of X-dimension. Is there a reason that the reader currently doesn't handle higher dimension variables (tensors, arrays, etc.)?

We have to be careful where in the variable's domain (spatial or topological dimension) or range (tensor rank or sometimes also called dimension) we are talking about dimension. The original inquiry here I took to mean one about the variable's domain dimensions. However, as you are alluding to, often the extra dimension (above 3) is used to deal with the 3 components of a vector, or the 9 components of a tensor, or maybe the 256 angles of a flux. And, yes, I agree, in those cases, it would be good for the plugin to be able to load them up correctly. The challenge is in informing VisIt how to do that. Perhaps we could add database read options that would permit a user to indicate the role (domain dimension or tensor-rank) of a netCDF dimension in the file and this could then help inform the bootstrap to tease metadata out of the file. Maybe even something as simple as given a list of netCDF dimension names, indicating whether a dimension applies to variable domains or their tensor ranks.

Our basic reader is pretty basic and our solution has been to create domain- or application-specific sub-classes of that reader for cases like this.