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

[netCDF #GAJ-689004]: Corrupted netCDF when adding dimension



I tried it with the current netcdf-c master branch + 1.10.4,
and it seems work ok. So not sure what is going on.

> Thanks for the heads-up. I have not yet used 1.10.4, so I will
> investigate.
> 
> > I installed the netCDF 4.6.3, together with HDF5 1.8.21, and it works well. 
> > Thank you.
> >
> > Just for your information (this is not a stopping issue for me):
> > In addition, I tried with the HDF5 1.10.4 release (instead of 1.8.21). I 
> > generated a fresh new netCDF file with the "step1" script, and afterwards I 
> > inserted the elements using "step2". Unfortunately I get the following 
> > error when trying "ncdump" to the output netCDF file (same error as in the 
> > initial email).
> > NetCDF: Invalid dimension ID or name
> > Location: file ncdump.c; line 1740
> >
> >
> >
> >
> > -----Original Message-----
> > From: Unidata netCDF Support <address@hidden>
> > Sent: Monday 11 March 2019 21:02
> > To: Daniel Risquez Oneca <address@hidden>
> > Cc: address@hidden
> > Subject: [netCDF #GAJ-689004]: Corrupted netCDF when adding dimension
> >
> > I did a quick test with the current master and using HDF5 1.10.3.
> > It seems to work ok. I think some work was done on the handling of 
> > coordinate variables and dimensions recently, so that  may have 
> > inadvertently fixed the problem. You might try again with release netcdf 
> > 4.6.3.
> >
> >
> >
> > > Package Version: netCDF 4.6.2, HDF5 1.8.21 Operating System: Linux
> > > Hardware:
> > > Description of problem: I find a strange error when adding a dimension to 
> > > an already existing netCDF file.
> > >
> > > Using the attached "step1-generate.c" code, I generate a small netCDF 
> > > file. It contains just a coordinate variable inside the "data" group. So 
> > > far, everything is ok. This is the output from "ncdump":
> > >
> > > netcdf output {
> > > group: data {
> > > dimensions:
> > > coordinate_variable = 10 ;
> > > variables:
> > > short coordinate_variable(coordinate_variable) ;
> > > data:
> > > coordinate_variable = _, _, _, _, _, _, _, _, _, _ ; } // group data }
> > >
> > > Afterwards, I append the file and insert a new dimension and its 
> > > corresponding variable, using "step2-append.c".
> > >
> > > Both programs are apparently successful, because they do not throw any 
> > > error. However, when I try "ncdump" I get the following error:
> > >
> > > netcdf output {
> > > dimensions:
> > > coordinate_variable = 10 ;
> > > variables:
> > > NetCDF: Invalid dimension ID or name
> > > Location: file ncdump.c; line 1740
> > > short my_var
> > > [AND NO MORE LINES!]
> > >
> > > Some comments:
> > > * the "coordinate_variable" was created inside the "data" group, not at 
> > > root level.
> > > * The problem seems to be directly related to the existence of a 
> > > coordinate variable ("variable" and "dimension" having the same name).
> > > * netCDF commands ("ncdump", "nccopy") do not work.
> > > * HDF5 commands work well (for example, "h5repack").
> > > * This test presented here has been implemented in C, but the same 
> > > happens in Python.
> > >
> > > Therefore:
> > > * This issue seems to be related to netCDF and not HDF5.
> > > * This issue requires the existence of at least a coordinate variable.
> > > * When all dimensions and variables are located at root level, it works 
> > > well. This issue requires the coordinate variable to be in a group.
> > > * The behavior is erratic. When the variable ("my_var") in 
> > > "step2-append.c" is not added (because that code is commented out), then 
> > > simply "my_dim" dimension is invisible when using "ncdump".
> > >
> > > Thank you in advance.
> > >
> > >
> >
> > =Dennis Heimbigner
> > Unidata
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: GAJ-689004
> > Department: Support netCDF
> > Priority: Normal
> > Status: Open
> > ===================
> > NOTE: All email exchanges with Unidata User Support are recorded in the 
> > Unidata inquiry tracking system and then made publicly available through 
> > the web.  If you do not want to have your interactions made available in 
> > this way, you must let us know in each email you send to us.
> >
> >
> >
> > **********************************
> > The email message you have received has been written by a EUMETSAT 
> > contractor, and although sent in good faith shall neither be binding nor 
> > construed as constituting a commitment by EUMETSAT, except where provided 
> > for in a written agreement or contract or if explicitly stated in the 
> > email. Please note that any opinions presented in this email are solely 
> > those of the contractor, working independently and not as an employee of 
> > EUMETSAT, and as such does not necessarily represent and share the views of 
> > EUMETSAT.
> >
> > This message and any attachments are intended for the sole use of the 
> > addressee(s) and may contain confidential and privileged information. Any 
> > unauthorised use, disclosure, dissemination or distribution (in whole or in 
> > part) of its contents is not permitted. If you received this message in 
> > error, please notify the sender and delete it from your system.
> >
> > **********************************
> >
> 
> =Dennis Heimbigner
> Unidata
> 

=Dennis Heimbigner
  Unidata


Ticket Details
===================
Ticket ID: GAJ-689004
Department: Support netCDF
Priority: Normal
Status: Open
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.