On Feb 10, 2016, at 1:50 PM, Billy Kessler <william.s.kessler@xxxxxxxx> wrote:
HI Andrew -
The answer could be Steve's earlier comment that it is a bug in the implementation rather than an expected feature.
I've attached 2 example plots. They happen to be zonal wind stress on a particular day.
The first is to simply SHADE the data (2-d map). The second applies X=@FLN. You can see that Ferret extended the plot to the west, but not to the east. That is the typical result, suggesting a bug rather than intended behavior. On other grids where a file might include a bit of Atlantic at the right edge, those latitudes will also be interpolated.
The version and grid/axis are shown below.
Billy
NOAA/PMEL TMAP
FERRET v6.94
Darwin 14.1.0 - 02/26/15
10-Feb-16 13:35
yes? sho grid taux1deghf215
GRID GMH1
name axis # pts start end
XHF LONGITUDE 166mr 124.5E 70.5W
YHF LATITUDE 39 r 28.5S 9.5N
normal Z
TMON_CCMP_ASCAT TIME 1 r 14-JUN-2012 20:15 14-JUN-2012 20:15
normal E
normal F
yes? sho axis xhf
name axis # pts start end
XHF LONGITUDE 166mr 124.5E 70.5W
Axis span (to cell edges) = 166 (modulo length = 360)On Feb 10, 2016, at 9:20 AM, Andrew Wittenberg - NOAA Federal <andrew.wittenberg@xxxxxxxx> wrote:
Billy, Martin, Steve,
As described in Sec. 4.3.7.1 of the User's Guide:
http://ferret.pmel.noaa.gov/Ferret/documentation/users-guide/Grids-Regions/REGIONS#_VPINDEXENTRY_726
The modulo attribute is *only* automatically applied *if* the axis is a longitude or climatological axis. If it's a longitude axis, the modulo length is set to 360 degrees. If it's a climatological axis, the modulo length is set to one year. Both make sense, and enable one to easily plot any modulo range of the axis (e.g. x=-180:180, or x=0:360, or x=0:720).
For subspan modulo axes (e.g. the Pacific only), Ferret inserts a "void cell" that fills the longitude gap between the end of the axis and the start of the next modulo cycle. Ferret is supposed to prevent smoothers (@sbx, @spz), fillers (@fln, @fnr), and derivatives (@ddc, @ddf) from operating across this void point, so the output should be correct -- no need for CANCEL AXIS/MODULO.
Early versions of Ferret had bugs in these features, but as far as I know (with one exception, see below), everything has worked fine since v6.941 (16 April 2015). Here's a sample session in the latest version.
First make a NetCDF file containing a sub-span modulo longitude axis:
NOAA/PMEL TMAP
FERRET v6.961 (beta)
Linux 2.6.32-573.8.1.el6.x86_64 64-bit - 12/09/15
10-Feb-16 12:13
yes? def ax/x=0:180:10/unit=degrees_e xax
yes? let a = x[gx=xax]; save/clob/file=a.nc a
LISTing to file a.nc
yes? sp ncdump a.nc
netcdf a {
dimensions:
XAX = 19 ;
variables:
double XAX(XAX) ;
XAX:units = "degrees_east" ;
XAX:point_spacing = "even" ;
XAX:axis = "X" ;
XAX:modulo = 360. ;
XAX:standard_name = "longitude" ;
double A(XAX) ;
A:missing_value = -1.e+34 ;
A:_FillValue = -1.e+34 ;
A:long_name = "X[GX=XAX]" ;
// global attributes:
:history = "FERRET V6.961 (beta) 10-Feb-16" ;
:Conventions = "CF-1.6" ;
data:
XAX = 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150,
160, 170, 180 ;
A = 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150,
160, 170, 180 ;
}
Now use the file, and try some transformations across the modulo cut:
yes? can var a; can ax xax; use a.nc
yes? list/x=0:720 a, a[x=@sbx:3], a[x=@fln], a[x=@ddf]
DATA SET: ./a.nc
LONGITUDE: 0E to 0E(720)
Column 1: A is X[GX=XAX]
Column 2: A[X=@SBX:3] is X[GX=XAX] (box smoothed by 3 pts on X)
Column 3: A[X=@FLN:1] is X[GX=XAX] (linear-filled by 1 pts on X)
Column 4: A[X=@DDF] is X[GX=XAX] (forward derivative on X)
A A A A
0E / 1: 0.0 .... 0.0 8.993E-06
10E / 2: 10.0 10.0 10.0 8.993E-06
20E / 3: 20.0 20.0 20.0 8.993E-06
30E / 4: 30.0 30.0 30.0 8.993E-06
40E / 5: 40.0 40.0 40.0 8.993E-06
50E / 6: 50.0 50.0 50.0 8.993E-06
60E / 7: 60.0 60.0 60.0 8.993E-06
70E / 8: 70.0 70.0 70.0 8.993E-06
80E / 9: 80.0 80.0 80.0 8.993E-06
90E / 10: 90.0 90.0 90.0 8.993E-06
100E / 11: 100.0 100.0 100.0 8.993E-06
110E / 12: 110.0 110.0 110.0 8.993E-06
120E / 13: 120.0 120.0 120.0 8.993E-06
130E / 14: 130.0 130.0 130.0 8.993E-06
140E / 15: 140.0 140.0 140.0 8.993E-06
150E / 16: 150.0 150.0 150.0 8.993E-06
160E / 17: 160.0 160.0 160.0 8.993E-06
170E / 18: 170.0 170.0 170.0 8.993E-06
180E / 19: 180.0 .... 180.0 ....
90W / 20: .... .... .... ....
0E(360) / 21: 0.0 .... 0.0 8.993E-06
10E / 22: 10.0 10.0 10.0 8.993E-06
20E / 23: 20.0 20.0 20.0 8.993E-06
30E / 24: 30.0 30.0 30.0 8.993E-06
40E / 25: 40.0 40.0 40.0 8.993E-06
50E / 26: 50.0 50.0 50.0 8.993E-06
60E / 27: 60.0 60.0 60.0 8.993E-06
70E / 28: 70.0 70.0 70.0 8.993E-06
80E / 29: 80.0 80.0 80.0 8.993E-06
90E / 30: 90.0 90.0 90.0 8.993E-06
100E / 31: 100.0 100.0 100.0 8.993E-06
110E / 32: 110.0 110.0 110.0 8.993E-06
120E / 33: 120.0 120.0 120.0 8.993E-06
130E / 34: 130.0 130.0 130.0 8.993E-06
140E / 35: 140.0 140.0 140.0 8.993E-06
150E / 36: 150.0 150.0 150.0 8.993E-06
160E / 37: 160.0 160.0 160.0 8.993E-06
170E / 38: 170.0 170.0 170.0 8.993E-06
180E / 39: 180.0 .... 180.0 ....
90W / 40: .... .... .... ....
0E(720) / 41: 0.0 .... 0.0 8.993E-06
Looks good. Now remove the modulo and longitude attributes, and try again:
yes? sp ncatted -O -h -a modulo,XAX,d,, -a standard_name,XAX,d,, -a units,XAX,o,c,"meters" a.nc
yes? sp ncdump a.nc
netcdf a {
dimensions:
XAX = 19 ;
variables:
double XAX(XAX) ;
XAX:units = "meters" ;
XAX:point_spacing = "even" ;
XAX:axis = "X" ;
double A(XAX) ;
A:missing_value = -1.e+34 ;
A:_FillValue = -1.e+34 ;
A:long_name = "X[GX=XAX]" ;
// global attributes:
:history = "FERRET V6.961 (beta) 10-Feb-16" ;
:Conventions = "CF-1.6" ;
data:
XAX = 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150,
160, 170, 180 ;
A = 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150,
160, 170, 180 ;
}
yes? can dat/all; use a.nc
yes? list/x=0:720 a, a[x=@sbx:3], a[x=@fln], a[x=@ddf]
DATA SET: ./a.nc
X (meters): 0 to 185
Column 1: A is X[GX=XAX]
Column 2: A[X=@SBX:3] is X[GX=XAX] (box smoothed by 3 pts on X)
Column 3: A[X=@FLN:1] is X[GX=XAX] (linear-filled by 1 pts on X)
Column 4: A[X=@DDF] is X[GX=XAX] (forward derivative on X)
A A A A
0 / 1: 0.0 .... 0.0 1.000
10 / 2: 10.0 10.0 10.0 1.000
20 / 3: 20.0 20.0 20.0 1.000
30 / 4: 30.0 30.0 30.0 1.000
40 / 5: 40.0 40.0 40.0 1.000
50 / 6: 50.0 50.0 50.0 1.000
60 / 7: 60.0 60.0 60.0 1.000
70 / 8: 70.0 70.0 70.0 1.000
80 / 9: 80.0 80.0 80.0 1.000
90 / 10: 90.0 90.0 90.0 1.000
100 / 11: 100.0 100.0 100.0 1.000
110 / 12: 110.0 110.0 110.0 1.000
120 / 13: 120.0 120.0 120.0 1.000
130 / 14: 130.0 130.0 130.0 1.000
140 / 15: 140.0 140.0 140.0 1.000
150 / 16: 150.0 150.0 150.0 1.000
160 / 17: 160.0 160.0 160.0 1.000
170 / 18: 170.0 170.0 170.0 1.000
180 / 19: 180.0 .... 180.0 ....
As desired, no subspan modulo behavior. So things look good.
Note that while trying this, I *did* find one additional bug in the handling of centered differences (@ddc) at the inserted void point. I'll report this separately to the developers.
Andrew
On Wed, Feb 10, 2016 at 6:06 AM, Martin Schmidt <martin.schmidt@xxxxxxxxxxxxxxxxx> wrote:
Dear all,
I would also support the idea to change the default behaviour for subspan axis - for the following reason:
For unexperienced users it seems that ferret "knows" a lot of things, like a little miracle. We know, the secret behind this is, ferret uses all information in the input files as best as possible, but cannot add missing information. The CF-standard defines the meaning of the attributes. It is the strength of ferret, to keep data, axis and metadata together. There is no need to control the relation between them all the time, unlike in matlab for example. This avoids a lot of programming and prevents users from making errors.
But changing the axis- and meta-information silently is a little bit against this "basic ferret philosophy". To see what I mean, assume,
you want to use the output of a regional model. There is a variable eta_t in the data set.
yes? use "http://phy-50:8080/thredds/dodsC/genus/genus_run_88_5day_ocean.nc"
yes? say `eta_t,return=xaxis`
!-> MESSAGE/CONTINUE XT_OCEAN
XT_OCEAN
yes? show axis XT_OCEAN
name axis # pts start end
XT_OCEAN LONGITUDE 273mi 10.075W(-10.075) 18.048E(18.048)
Axis span (to cell edges) = 28.24585 (modulo length = 360)
Ferret tells me the variable eta_t has a modula axis. But it has not. With ncdump I get:
double xt_ocean(xt_ocean) ;
xt_ocean:long_name = "tcell longitude" ;
xt_ocean:units = "degrees_E" ;
xt_ocean:cartesian_axis = "X" ;
xt_ocean:_ChunkSize = 273 ;
The original axis definition may be read correctly, but it is changed later to modulo by ferret. Writing some data to a file they are branded with the modulo-axis.
In most cases this is not a big deal, but ferret changes the information delivered from the netcdf-file, so it changes something silently, which my have been defined by the creator of the dataset with some intension. It is not possible to check with ferret, if axis in a data set are modulo or not. They are allways modulo.
Another argument is that the pair of operations "use" and " save" is not pass-through like but changes information inbetween.
Anyway, I am using ferret a lot and could be happy with any default. But, in the case if I could have a free wish ... axis should be used exactly as defined either
from the command line or from file information. Specifying the modulo attribute means "modulo" otherwise "not modulo".
Best,
Martin
Am 10.02.2016 um 06:17 schrieb William S. Kessler:
Count me as another user who thinks the subspan modulo behavior should not be the default.
I recall your explanation of this feature (28 Oct 2011):
The importance of the subspan modulo axes is to take the first of two steps that will make it possible for users largely to ignore differences in encodings of longitude and climatological time -- e.g. the blending of data in plots and analyses where the data come from data sets that are encoded variously as -180:180, 0:360, etc. Thus, for example, in V5.5 you can refer to my_subspan_var[g=another_var] and get a meaningful answer as long as the grids occupy the same region on the globe, regardless of longitude encoding. (The second step, for V5.6, will address the longitude encoding of scattered data.)
I can see how that might be useful in particular situations, but the cost is the mistaken plots and analyses by other users - working with grids covering subregions of the globe - who forget to declare the axis non-modulo, and unwittingly smooth or fill in x (or take a derivative, etc). Then Ferret will wrap the operation across the edges of the region inappropriately. As someone who frequently works with Pacific fields, I can't tell you how many times I've slapped my forehead and gotten a different result after remembering to CAN AXIS/MODULO. But those who are less-acquainted with this might make the mistake and not realize that their plot is wrong.
My sense of the balance is that this feature should be available, but not the default, because I'll bet most Ferret users don't realize that this will happen. They haven't fully read the documentation and assume - very reasonably - that the default for a subregion is non-modulo.And even for those who do know this, like me, it's a very easy feature to forget in the heat of calculation.
I think the default should be non-modulo for axes where x is given in degrees east, unless the axis is fully global, since the user who wants this feature can always turn it on (SET AXIS/MODULO), right?
Billy K
On Feb 9, 2016, at 5:16 PM, Steve Hankin <steven.c.hankin@xxxxxxxx> wrote:
On 2/9/2016 4:47 PM, Ryo Furue wrote:
Hi Steve,
Thanks for your detailed explanation.
An axis may be less than global (e.g. axis "x30") and still be understood to
have modulo 360 behavior. This is inferred automatically from its units of
degrees_east. To reliably regard a variable defined on an X axis of more
than 360 degrees, Ferret would have to check that the overlapping points at
each end all had identical values.
Or you COULD just issue a warning and disregard the values on one of
the overlapping "layers". I'm not saying you SHOULD.
Ferret has no internal logic to do this.
Yes, I guessed that that is the reason why Ferret currently rejects
such an overlapping axis.
There are cases where people deliberately create variables on longitude ranges of (say) 720 degrees (double worlds). All other things being equal it seems best not to second guess what people are doing.
P.S. The attribute "modulo" is from older Ferret versions.
So, what's the latest alternative? Is it a Ferret-specific attribute?
Or is it part of a well-recognized convention like CF?
The "modulo" attribute was a Ferret creation -- not CF. Somewhere along the way, Ferret was enhanced to support the notion of a "subspan modulo axis" -- modulo behavior, even though the axis isn't globe-encircling. The axis X30 in the previous message was an example. With the advent of subspan modulo axes, all longitude axes 360 degrees or less became implicitly "modulo". So the older modulo attribute is essentially irrelevant. (But no harm from having it in a file AFAIK.)
- Steve
The dataset I was given actually includes the "modulo" attribute. I'm
not sure if the creators of the dataset use Ferret.
Basically, I'd like to know if I should ask the creators to fix it.
They are a data center and so they do care about these things.
Ryo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William S. Kessler
NOAA / Pacific Marine Environmental Laboratory
7600 Sand Point Way NE
Seattle WA 98115 USA
william.s.kessler@xxxxxxxx
Tel: +1 206-526-6221
Fax: +1 206-526-6744
Web: http://faculty.washington.edu/kessler/
William S. Kessler
NOAA / Pacific Marine Environmental Laboratory
7600 Sand Point Way NE
Seattle WA 98115 USA
william.s.kessler@xxxxxxxx
Tel: +1 206-526-6221
Fax: +1 206-526-6744
Web: http://faculty.washington.edu/kessler/