[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDFJava #VSP-832015]: ncdf4: filling empty object with data?



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