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

[netCDF #PJC-712062]: nccopy cannot copy a nc3 file to a nc4 file

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.

  • Subject: [netCDF #PJC-712062]: nccopy cannot copy a nc3 file to a nc4 file
  • Date: Thu, 14 Jan 2016 14:10:37 -0700
Hi Kent,

Thanks for the additional information; we'll have to discuss how to handle
this internally, since we'll definitely want to handle this but we also
don't want to modify an end-user data set programatically.  Do you know
offhand if H5DSattach_scale sets/returns any sort of error code or throws a
signal we can catch, in addition to returning FAIL?

-Ward

On Wed, Jan 13, 2016 at 3:41 PM, Kent Yang <address@hidden>
wrote:

> New Client Reply: nccopy cannot copy a nc3 file to a nc4 file
>
> I did a little more investigation of the original HDF5 that may be helpful.
> In the original nc3 file, the attribute CLASS=IMAGE. This is a special
> convention for an HDF5 high-level image file.
> I think nccopy fails when calling H5DSattach_scale. In the function
> H5DSattach_scale, it will return FAIL if this dataset is an
> image(CLASS=IMAGE) or table(CLASS = TABLE).
> HDF5 IMAGE and TABLE cannot have dimension scales.
>
> One solution for this problem is to check if the attribute CLASS is IMAGE
> or TABLE, don't attach the scale if finding the variable is actually HDF5
> image or table.
>
> Hope it helps,
>
> Kent
> -----Original Message-----
> From: Unidata netCDF Support [mailto:address@hidden]
> Sent: Wednesday, January 13, 2016 3:10 PM
> To: Kent Yang
> Cc: address@hidden
> Subject: [netCDF #PJC-712062]: nccopy cannot copy a nc3 file to a nc4 file
>
> I have recreated the error using cygwin.
>
> A couple of things I noticed so far:
> 1. It appears to actually create the output netcdf4 file.
> 2. A diff of the metadata appears to show that the netcdf3 metadata
>    and the netcdf4 metadata are consistent except that the netcdf4
>    metadata is missing all attributes named 'CLASS' or 'NAME'.
>    Weird.
>
> =Dennis Heimbigner
>   Unidata
>
>
> Ticket Details
> ===================
> Ticket ID: PJC-712062
> Department: Support netCDF
> Priority: Normal
> Status: Closed
>
>
>
> Ticket Details
> ===================
> Ticket ID: PJC-712062
> Department: Support netCDF
> Priority: Normal
> Status: Open
> Link:
> https://andy.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=viewticket&ticketid=26542
>
>



Ticket Details
===================
Ticket ID: PJC-712062
Department: Support netCDF
Priority: Normal
Status: Open