[Thread Prev][Thread Next][Index]

Re: [ferret_users] arithmetics not working on a variable (broken netCDF file?)

Hi Ryo,
I was able to download your file after all. I think that the only problem here is the value of the modulo attribute on your x axis. The modulo length is the length of the modulo repeat. For a longitude axis the modulo length is always 360 degrees, the length of the wraparound of degrees around the earrth.  So this attribute should always be either

                lont:modulo = " " ;
                lont:modulo = 360 ;

The value in your file is lont:modulo = 0.5.  If modulo is given with a blank value then the modulo length is taken to be the default value of 360.

The NOTEs that you see when you open the file are because with no bounds or edges given for your one-point axis, Ferret arbitrarily assigns a cell size of one unit, which is larger than the specified value for the modulo length of 0.5.

Ferret will not draw a shade plot of data on a 1-point by n-point region (if it does, then it's confused by the modulo length of 0.5)  If you're doing things in a batch mode, you could either issue a SET MODE IGNORE_ERROR command and just skip cases where the dimension is too small, or put in a test
LET nx = `var,RETURN=isize`
IF `nx GT 1` THEN SHADE...


Ryo Furue wrote:
Hi Steven,

Thank you for your diagnosis!  I now understand in what way my
netCDF file is "interesting".

| The netCDF file has a few "interesting" features that are confusing
| ferret, as you can see from the warning messages that it generates
| during your session:
|  *** NOTE: Ignored modulo length exceeding axis length: lont
|  *** NOTE: Ignored modulo length exceeding axis length: lonv
|  *** NOTE: Evenly spaced axis has edges definition: dept - ignored
| In particular, you are specifying modulo lengths for the axes lont and
| lonv, even though these are only of length one.

Actually I'd like to have the modulo behavior even for the x-axis of
length one.  My current model is a two-dimensional (y-z) ocean,
assuming uniformity (symmetry) in the x-direction, and
I'd like to plot the flow field for an arbitrary longitudinal
width.   The modulo index i' is defined as

   i' = mod(i-1,IMAX) + 1

and the IMAX = 1 case is naturally included in the
definition (i' = 1 always).

Another practical reason is that I don't want to special-case the
IMAX=1 situation in my code to generate netCDF files.  The netCDF format
doesn't allow for easy change in dimensionality, so the special-casing
would complicate the code.

| You are then trying to shade a 1D region. The variable tdmb has
| dimensions 1x100x40x1, so tdmb[k=1,l=1] has dimensions 1x100. When you
| enter the command
| shade/k=1/l=1 tdmb
| the modulo attribute on the axis lont appears to be confusing ferret
| into thinking that this is really a 2D region, so the shade command
| succeeds.

That's what I expected.  Because it's 2D even though IMAX = 1
(See below).

| However, when you enter the command
| shade/k=1/l=1 tdmb*10
| ferret realises that it's a 1D region, and so the shade command fails.
| I tried generating a netCDF file that's identical to yours, but
| without the modulo attribute on the axis lont. Now both shade commands
| fail, as they should:
| yes? shade/k=1/l=1 tdmb
|  **ERROR: dimensions improperly specified: must be a 2D region
|           shade/k=1/l=1 tdmb
| yes? shade/k=1/l=1 10*tdmb
|  **ERROR: dimensions improperly specified: must be a 2D region
|           shade/k=1/l=1 10*tdmb

Hmm.  I think it's more systematic to distinguish
size one from no-dimension.  In Fortran notation,

  real:: a      !! scalar (zero-dimensional)
  real:: b(1)   !! one-dimensional array of size 1
  real:: c(3)   !! one-dimensional array of size 3
  real:: d(1,3) !! two-dimensional array

Here array d is two-dimensional even though its first
dimension is of size one.

I thought Ferret allows for a command like

  shade temp

when temp is 50x100x1 (dimension(50,100,1) in Fortran notation),
not because "temp" is two-dimensional but because it supplies
"k=1" when the dimension the user fails to specify is of size

In my interpretation above, "modulo-ness" wouldn't change
the dimensionality of the variable even when IMAX = 1
because the size doesn't affect the dimensionality.

Maybe such an interpretation would be hard to implement or it
would break some backward compatibility?


[Thread Prev][Thread Next][Index]

Contact Us
Dept of Commerce / NOAA / OAR / PMEL / TMAP

Privacy Policy | Disclaimer | Accessibility Statement