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