|
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 = " " ; or 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` Ansley 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 one. 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? Regards, Ryo |