Re: [ferret_users] when a /append causes a "** netCDF error: Variable not found"

[Ansley Manke <ansley.b.manke@xxxxxxxx>]

Hi Patrick,
When Ferret opens the file err620_append.nc from your website, the time 
axis is not detected as a regularly-spaced axis, and neither is the 
longer version of file_part2.nc.

Looking at the ncdump output of file_part2.nc with the longer length of 
840, the coordinates look like this:

> ncdump -c file_part2.nc
netcdf file_part2 {
dimensions:
   TIME_COUNTER = UNLIMITED ; // (840 currently)
variables:
   double TIME_COUNTER(TIME_COUNTER) ;
   float VAR1(TIME_COUNTER) ;

// global attributes:
       :history = "Mon Sep 21 09:32:55 2009: ncks -O -F -d 
TIME_COUNTER,1,840 err620_append.nc file_part2.nc" ;
data:

TIME_COUNTER = 1296000, 3888000, 6480000, 9072000, 11664000, 14256000,
...
   2129328000, 2131920000, 2134512000, 2137104000, 2139696000, 2142288000,
   2144880000, 2147472000, 2150064128, 2152655872, 2155248128, 2157839872,
   2160432128, 2163023872, 2165616128, 2168207872, 2170800128, 2173391872,
   2175984128 ;

You can see that for most of the range, the delta-coordinate is 2592000, 
but within the last few time steps this starts to vary.

If you change your script to force the axis to be seen as regular 
(USE/REGULART file_part2.nc), or put an attribute in the file 
TIME_COUNTER:point_spacing = "even" ;  then the script will work as you 
expect. 
Ferret should issue an error message to tell us what is the problem is. 
What is happening is that the script writes the first part of the data 
to the file, with a regularly-spaced time axis, L=1:360.  Then the 
second LIST command, with /APPEND/L=361:840, tries to write the 
irregularly-spaced axis coordinates with bounds, as it does for all 
irregular axes, but it does not find a bounds variable defined for the 
axis.  A bounds variable which would have been automatically created if 
the first part of the axis were irregular, or if we had put a /BOUNDS 
qualifier on the first LIST command.

Notice that this combination works, because the first LIST command has 
written an irregular time axis, and so the LIST/APPEND can use the 
bounds variable that has already been defined.

  ferret -script err620_append.jnl 840 1000


Another way to get the script to work is to force bounds to be written:

 ! for testing, generate a file_part1.nc with ($01) time steps from 
err620_append.nc
 sp ncks -O -F -d TIME_COUNTER,1,($01) err620_append.nc file_part1.nc
 use "file_part1.nc"
 let var2=var1
 save/BOUNDS/file="fileout.nc"/clobber var2

 !################################################
 ! for testing, generate a file_part2.nc with ($02) time steps from 
err620_append.nc
 sp ncks -O -F -d TIME_COUNTER,1,($02) err620_append.nc file_part2.nc
 use "file_part2.nc"
 let var2=var1
 save/BOUNDS/file="fileout.nc"/append/l=`($01)+1`:($02) var2

We will add a proper error message, something like:

** appending irregular time steps to an axis without bounds: cannot 
create bounds variable when appending.



Brockmann Patrick wrote:
> Russell Fiedler a écrit :
> > Hi Patrick,
> >
> > I've figured it out! You're running out of precision and ferret is 
> > getting confused because
> > TIME_COUNTER is no longer being treated as a regular axis.
> > If you do a ncdump -c on the longer file you will see that the last 
> > few entries are becoming irregular
> > ...
> >     2129328000, 2131920000, 2134512000, 2137104000, 2139696000, 
> > 2142288000,     2144880000, 2147472000, 2150064128, 2152655872, 
> > 2155248128, 2157839872,     2160432128, 2163023872, 2165616128, 
> > 2168207872, 2170800128, 2173391872,     2175984128 ;
> >
> > show axis in ferret says its an irregular axis
> >  name       axis                      # pts      
> > start                       end
> >  TIME_COUNTER T               840 i   1296000              2.176E+09
> >                                                      ^
> > whereas for the shorter axes  TIME_COUNTER1 T              721 r   
> > 1296000              1.8675E+09
> >                                                        ^
> >   
> Hi Russ,
> You are right. Nice to understand why.
> Now I am wondering why there is this problem since the time axis is 
> represented
> with a double precision.
> With 240 years of simulation I should be able to save
> a time axis with 360*24*60*60*240 seconds ?
>
> Patrick