This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
no, you have to do the work to detect homogenous groups, by opening the files independently and examining them. > My goal is to quickly and easily detect if a set of files can be made > into a homogeneous aggregation. So are you saying that, if I execute > the procedure you describe below: > > - it will fail if the files are not homogeneous - thus providing me with > my sanity check? > or > - it will force non-homogenous files into a homogeneous aggregation? > > Thanks, > Tom > > open each file seperately as a grid dataset, and make homogenous groups. > > build an ncml on the fly, and open that as the aggregation. > > > > > >> I want to be able to detect whether a submitted aggregation indeed > >> points to data sets with homogenous sets of variables. We are building > >> an automated app, not an app wherein a human knows a priori what is in a > >> proposed aggregation. > >> > >> I want to point to any semi-arbitrary set of NetCDF files as an > >> aggregation, receive an aggregated GridDataset object, and somehow query > >> that object to see if the aggregation is indeed valid. In other words - > >> I want to be able to do a "sanity check" on an aggregated GridDataset. > >> Originally I was going to loop through the grids in the aggregated > >> GridDataset and look to see if they are homogenous, but apparently that > >> won't work. > >> > >> How would you suggest I perform a sanity check on an aggregated > >> GridDataset? The API doesn't seem to support "is this valid?" checks > >> for such data sets. > >> > >> Thanks, > >> Tom > >> > >>>> John, > >>>> > >>>> I can't replicate this problem with the <scan> element, but it is easily > >>>> replicated with the <aggregation> element, using "joinExisting". Point > >>>> to a few NetCDF data sets with differing numbers/types of variables and > >>>> you should see the problem. > >>>> > >>>> > >>> Im not sure i know what you mean by "data sets with differing > >>> numbers/types of variables". A joinExisting has to have homogenous sets > >>> of variables. it picks one to be a prototype for the aggregation. If the > >>> files differ, you will get different result. > >>> > >>> is that the problem? what were you expecting to happen? perhaps you are > >>> thinking of a "union" aggregation? > >>> > >>> > >>> > >>> > >>> > >>>> Thanks, > >>>> Tom > >>>> > >>>> > >>>>> I just fixed a bug like that in FmrcSingle, but i havent seen it for > >>>>> joinExisting. Are you sure its happening for joinExisting? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Hello again! > >>>>>> > >>>>>> Thanks for your help with the IOSP issue - the more I dig into > >>>>>> Unidata's > >>>>>> NetCDF Java API, the more I like it. > >>>>>> > >>>>>> I am using an NCML file to aggregate NetCDF files into a single > >>>>>> GridDataset, and I see the following odd behavior: a call to > >>>>>> aggregatedGridDataset.getGrids() sometimes returns all the grids in the > >>>>>> aggregate, and sometimes returns only some of these grids - > >>>>>> apprarently, > >>>>>> the grids in only one of the aggregate members. This occurs when I use > >>>>>> the <netcdf> element and when I use the <scan> element: > >>>>>> > >>>>>> <aggregation dimName="time" type="joinExisting"> > >>>>>> <netcdf location="/path/to/member_1.nc"/> > >>>>>> <netcdf location="/path/to/member_2.nc"/> > >>>>>> <netcdf location="/path/to/member_3.nc"/> > >>>>>> <netcdf location="/path/to/member_4.nc"/> > >>>>>> </aggregation> > >>>>>> > >>>>>> <aggregation dimName="time" type="joinExisting"> > >>>>>> <scan location="/path/to/members/directory" suffix=".nc"/> > >>>>>> </aggregation> > >>>>>> > >>>>>> Any ideas why I am getting inconsistent results? > >>>>>> > >>>>>> Thanks, > >>>>>> Tom > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> Ticket Details > >>>>> =================== > >>>>> Ticket ID: VSP-832015 > >>>>> Department: Support netCDF Java > >>>>> Priority: Critical > >>>>> Status: Open > >>>>> > >>>>> > >>>>> > >>> Ticket Details > >>> =================== > >>> Ticket ID: VSP-832015 > >>> Department: Support netCDF Java > >>> Priority: Critical > >>> Status: Open > >>> > >>> > >> > > > > > > Ticket Details > > =================== > > Ticket ID: VSP-832015 > > Department: Support netCDF Java > > Priority: Critical > > Status: Open > > > > Ticket Details =================== Ticket ID: VSP-832015 Department: Support netCDF Java Priority: Critical Status: Open